tty on resume and mouse 4/5

patrikr

I've been using netbsd on my thinkpad x230 as a daily driver for a bit, and it's been a pretty good experience. The biggest papercuts I've experienced so far have been that I have to switch TTY after resume and that mouse 4/5 act like scroll up/down respectively while I'd prefer to have them be backward/forward navigation.
The TTY switching is annoying, seeing as I seem to have to wait until the keyboard accepts input (which in rare occasions it does not and instead the fan spins up and I'm left with an unresponsive computer I have to hard reset) and then do ctrl-alt-f4 then ctrl-alt-f5 to get back to X. Is there any way to set which tty to switch to after resume?

rvp

patrikr Is there any way to set which tty to switch to after resume?

This is a long-stading NetBSD bug. Can you try adding this to /etc/powerd/scripts/sleep_button as a work-around?

test -S /tmp/.X11-unix/X0 && /usr/sbin/wsconscfg -s 5

Add it to the released) case first; then if it doesn't work, add it after the fi in the pressed) case.

patrikr [...] and that mouse 4/5 act like scroll up/down respectively while I'd prefer to have them be backward/forward navigation.

These actions (gestures, for example) are program-specific (ie. nothing to do with the OS, as long as the OS generates the appropriate mouse-button events).

See, for example, browser.gesture.* in Firefox's about:config.

patrikr

rvp This is a long-stading NetBSD bug. Can you try adding this to /etc/powerd/scripts/sleep_button as a work-around?
test -S /tmp/.X11-unix/X0 && /usr/sbin/wsconscfg -s 5
Add it to the released) case first; then if it doesn't work, add it after the fi' in thepressed)` case.

I ended up putting it in the lid_switch script under released) but it does work like I expect it to, thanks!

rvp These actions (gestures, for example) are program-specific (ie. nothing to do with the OS, as long as the OS generates the appropriate mouse-button events).

See, for example, browser.gesture.* in Firefox's about:config.

I'm not sure this is the case. I have one mouse device (Mouse0) when running xinput list, regardless of if I'm using my Logitech MX Ergo with the usb receiver or the built-in trackpoint.
Remapping the buttons with xinput set-button-map 'Mouse0' 1 2 3 8 9 means that the physical mouse 4/5 buttons (which should be sending mouse 8/9 in software) on my trackball work like I expect them to (forward/backward navigation), but now my scroll wheel also does forward/backward navigation instead of scrolling.
This feels like something up with wsmouse not detecting how many actual physical buttons I have and therefore treating the side buttons the same as scroll wheel up/down button presses.

rvp

patrikr I have one mouse device (Mouse0) when running xinput list, regardless of if I'm using my Logitech MX Ergo with the usb receiver or the built-in trackpoint.

Yes, by default, the Xorg server opens /dev/wsmouse only, which smooshes all pointer devices together; but, you can split these out into individual devices, then apply xinput only to those you want.