daily CVS update output
Updating src tree: P src/bin/sh/histedit.c P src/lib/libedit/chared.c P src/lib/libedit/histedit.h P src/lib/libedit/readline.c P src/lib/libedit/readline/readline.h P src/sys/kern/subr_pcu.c P src/sys/kern/subr_psref.c P src/sys/kern/subr_thmap.c P src/sys/kern/vfs_vnode.c P src/usr.bin/make/meta.c Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.3 P sys/dev/ata/ata_recovery.c P sys/dev/ata/ata_subr.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44719040 Feb 9 03:11 ls-lRA.gz
Re: Disappearing mouse buttons
On Tue, Feb 08, 2022 at 03:06:43PM +0100, Tom Ivar Helbekkmo wrote: > I've been looking at changes in sys/dev/usb, sys/dev/hid, and > sys/dev/wscons, but I can't find anything that looks relevant. > > If anyone has any hints for me, that would be appreciated! > > -tih I think you're looking in the wrong area - the most likely culprit is a change I made to Xorg where the default driver for pointing devices will be "ws" instead of "mouse" (this is primaily useful for touchscreens and touchpads, and mirrors a similar change for OpenBSD). Sorry if it's indeed my fault
Re: Disappearing mouse buttons
Michael writes: > Does it still work as expected with an older -current? Yup. It still works the way it used to when I plug it into my Pinebook, that still runs a -current from early September, and likewise with my Linux laptop. The dmesg output from the Pinebook is identical: it says "5 buttons and Z dir" there, too, but there, the four actual buttons generate (according to xev) buttons 1, 2, 3, and 8, and the scroll wheel 4 and 5. So the difference between the September -current and a fresh one is that the fourth button now generates button 4 events instead of 8. No change after it's been observed to work as expected on Linux and on slightly older NetBSD; it's still button 4 when plugged back into the workstation with amd64-current on it. (And the change, there, occurred exactly when I upgraded it from that September 9th version, with nothing else changed.) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
Re: Disappearing mouse buttons
I've noticed some possibly-related strange behavior with my USB mouse... ... [ 1.020834] xhci0 at pci0 dev 20 function 0: vendor 8086 product 8d31 (rev. 0x05) [ 1.020834] xhci0: 64-bit DMA [ 1.020834] xhci0: interrupting at msi0 vec 0 [ 1.020834] xhci0: xHCI version 1.0 [ 1.020834] usb0 at xhci0: USB revision 3.0 ... [ 1.020834] usb1 at xhci0: USB revision 2.0 [ 1.864441] uhub1 at usb1: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 2.00/1.00, addr 0 ... [ 4.031817] uhidev2 at uhub1 port 14 configuration 1 interface 0 [ 4.031817] uhidev2: PixArt (0x17ef) Lenovo USB Optical Mouse (0x600e), rev 2.00/1.00, addr 6, iclass 3/1 [ 4.041817] ums0 at uhidev2: 3 buttons and Z dir [ 4.041817] wsmouse0 at ums0 mux 0 ... Sometimes (without any discernible pattern), moving the scroll wheel "down" does nothing. Under normal conditions, it does what you'd expect, scrolling the page, AND there are detectable "detents" in the wheel movement (ie, little bumps). However, when it decides to misbehave, there are no more detents and no more scrolling. Yet it still works in the scroll-up rotation (including the detents). It usually resets in a few seconds, and then all is will until the next occurrence. This is on amd64 9.99.93 with sources dated 2022-01-08 03:00:28 UTC. (The kernel does have some custom stuff, but no customizations that should have any relation to USB.) It sorta feels like something is disabling (or turning off) the down-scroll function of the wheel, without breaking anything else. I don't remember this happening on earlier kernels, but I'm getting old so the memory might be operating in sieve-mode. :-) ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Disappearing mouse buttons
Hello, On Tue, 08 Feb 2022 15:06:43 +0100 Tom Ivar Helbekkmo wrote: > I'm looking for something that I can't find... The "Kensington Expert > Mouse" trackball on my amd64-current workstation has four buttons and a > scroll wheel, and these used to generate all different button presses - > so at least six distinct buttons. This was still working with a > -current from back at the start of September. > > After a fresh update, however, it now reports thus: > > uhidev1 at uhub4 port 1 configuration 1 interface 0 > uhidev1: vendor 047d (0x047d) Kensington Expert Mouse (0x1020), rev > 2.00/1.06, addr 4, iclass 3/1 > ums0 at uhidev1: 5 buttons and Z dir > wsmouse0 at ums0 mux 0 > > With this, I suddenly have the fourth button mapped as a duplicate of > one of the scroll wheel directions. The wsmouse mapping is "1 2 3 4 5", > and the fourth button generates button 4; the scroll wheel 4 and 5. The > fourth button, then, is just single steps of one scroll direction, while > it used to give me the "back" function normally associated with one of > the thumb buttons on most modern mice. > > I've been looking at changes in sys/dev/usb, sys/dev/hid, and > sys/dev/wscons, but I can't find anything that looks relevant. > > If anyone has any hints for me, that would be appreciated! Does it still work as expected with an older -current? It may be a long shot, but the ADB variants of these trackballs are programmable, on the hardware side, on which button sends what event. That's more or less why the ktm driver exists. No idea if the USB ones are, but who knows. Might be worth checking what the windows driver does. It might have remapped some buttons and maybe the settings are sticky. have fun Michael
Disappearing mouse buttons
I'm looking for something that I can't find... The "Kensington Expert Mouse" trackball on my amd64-current workstation has four buttons and a scroll wheel, and these used to generate all different button presses - so at least six distinct buttons. This was still working with a -current from back at the start of September. After a fresh update, however, it now reports thus: uhidev1 at uhub4 port 1 configuration 1 interface 0 uhidev1: vendor 047d (0x047d) Kensington Expert Mouse (0x1020), rev 2.00/1.06, addr 4, iclass 3/1 ums0 at uhidev1: 5 buttons and Z dir wsmouse0 at ums0 mux 0 With this, I suddenly have the fourth button mapped as a duplicate of one of the scroll wheel directions. The wsmouse mapping is "1 2 3 4 5", and the fourth button generates button 4; the scroll wheel 4 and 5. The fourth button, then, is just single steps of one scroll direction, while it used to give me the "back" function normally associated with one of the thumb buttons on most modern mice. I've been looking at changes in sys/dev/usb, sys/dev/hid, and sys/dev/wscons, but I can't find anything that looks relevant. If anyone has any hints for me, that would be appreciated! -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
