Re: Disappearing mouse buttons

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

nia%netbsd.org@localhost writes:

> 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).

That was, indeed, it!  Thank you so much for identifying it for me!  :)

Does this mean that our /dev/wsmouse isn't working properly?  Having a
device that exhibits this behaviour, should I be taking a closer look at
sys/dev/wscons/wsmouse.c?  Or possibly lower down in the stack, like
sys/dev/usb/ums.c, or even sys/dev/hid/hidms.c, as it reports "5 buttons
and Z dir", where I assume it should be claiming (at least) 8 buttons,
seeing as my problem button is button 8 when it's working...?

I notice that in sys/dev/hid/hidms.c, we count the buttons thus:

	for (i = 1; i <= MAX_BUTTONS; i++)
		if (!hid_locate(desc, size, HID_USAGE2(HUP_BUTTON, i),
		    id, hid_input, &ms->hidms_loc_btn[i - 1], 0))
			break;
[...]
	ms->nbuttons = i - 1;

Now, if my device is claiming buttons 1, 2, 3, 4, 5, and 8, it would
seem that this code would end up ignoring button 8, just like I see in
the dmesg output (and in X, when it uses the wsmouse/ums/hid stack).
Assuming that the "mouse" driver in X talks more directly to the device
about its configuration, a slight modification to the above to find the
highest numbered button present, instead of the last one contiguously
numbered from 1, would be interesting.  I'll try it, and see.

-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