Just HOW many buttons did that mouse claim to have??!?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Just HOW many buttons did that mouse claim to have??!?

David Wolfskill
The laptop I've been using for the last few years has served me
well, but its warranty has run out, and I cycle in SF Bay area
traffic as part of my normal commute, so I thought it would be best
to get a newer machine (that's under warranty).

I wrote up a description of the older machine (a Dell Precision
M4800); one may read it at
<https://wiki.freebsd.org/Laptops/Dell_Precision_M4800?highlight=(\bCategoryLaptop\b)>.

The machine I recently acquired is a Dell Precision 7520; in many
respects, it is quite similar.

One rather stark difference in behavior, though, is that -- under FreeBSD
-- the built-in mouse/trackpad/trackpoint of the 7520 appears to be
completely non-functional.  (If I plug in a USB mouse, that works Just
Fine.)

Oh -- the below is all done under head/amd64 @r331083.

I had written (to mobile@) about this, and received a couple of hints;
in pursuing those, I found some things that seem curious to me.

After re-reading psm(4), I was "inspired" to augment my kernel
configuration file with:

| # For debugging  the mouse/trackpad/touchpad on the Dell Precision 7520
| options         PSM_DEBUG=2

After some poking around, I also sprinkled a few additional VLOG()
invocations in src/sys/dev/atkbdc/psm.c, and stuck a "-v" in
/boot.config.

Here's an excerpt from a verbose dmesg.boot from the M4800:

psm0: unable to allocate IRQ
random: harvesting attach, 8 bytes (4 bits) from atkbdc0
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm: status 00 02 64
psm: status 00 00 64
psm: status 00 03 64
psm: status 00 03 64
psm: data 08 00 00
psm: status 00 00 14
psm: status 00 00 14
psm: status 73 03 0a
psm: status 00 02 64
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 53
psm0: [GIANT-LOCKED]
psm0: model GlidePoint, device ID 0-00, 2 buttons
psm0: config:00004000, flags:00000008, packet size:3
psm0: syncmask:c0, syncbits:00

And here is a similar excerpt (but without the additional debug level
or VLOG() invocations)  from the 7520:

psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm: status 00 64 02
psm: status 00 64 00
psm: status 00 64 03
psm: status 00 64 03
psm: data 00 00 00
psm: status 00 14 00
psm: status 00 14 00
psm: status 00 64 02
psm: status 00 02 64
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 52
psm0: [GIANT-LOCKED]
psm0: model Generic PS/2 mouse, device ID 0-00, 100 buttons
psm0: config:00000000, flags:00000008, packet size:3
psm0: syncmask:c0, syncbits:00


Now, there's a lot of similarity... but psm(4) claims that the M4800 has
"2 buttons" (which is at least incomplete, as it actually has 2 sets of
3 buttons each, but that's not critical -- after all, it works).

But the 7520 claims to have "100 buttons" -- and that seems... a bit
ambitious: it actually also has 2 sets of 3 buttons each.

Now, I realize that 0x64 == 100, so I suspected that the apparent
change in the ordering of some the status values might be relevant.

So here's what I see for the 7520 with additional debugging:

psm0: unable to allocate IRQ
random: harvesting attach, 8 bytes (4 bits) from atkbdc0
psmcpnp0: <PS/2 mouse port> irq 12 on acpi0
psm0: current command byte:0065
kbdc: TEST_AUX_PORT status:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
kbdc: RESET_AUX return code:00fa
kbdc: RESET_AUX status:00aa
kbdc: RESET_AUX ID:0000
psm: ENABLE_DEV return code:00fa
psm: DISABLE_DEV return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 64 02
psm: SEND_DEV_ID return code:00fa
psm: device ID: 0000
In get_mouse_buttons()
psm: SET_RESOLUTION (0) 00fa
get_mouse_buttons(): set_mouse_resolution() OK
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 64 00
psm: SET_RESOLUTION (3) 00fa
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 64 03
psm: SET_RESOLUTION (3) 00fa
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 64 03

[There's more later, but this is the point where get_mouse_buttons() has
made a determination....]

So... for the M4800, get_mouse_buttons() had received the status array
[00 03 64], and returned element [1], which has a value of 0x03.  But
for the 7520, the reeceived status array is [00 64 03], and it
(dutifully?) returns element 1, which is 0x64 -- or "100" in base 10.

I can't help but think that either the hardware/firmware/ACPI/... is
confused, and returning bytes in a sequence that wasn't expected, or
that psm(4) is missing something to tell it that it should be
interpreting things differently (e.g., returning element 2 for this
hardware).

More from the verbose dmesg.boot:

psm: SET_SCALING11 return code:00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (3) 00fa
psm: SET_RESOLUTION (2) 00fa
psm: SET_RESOLUTION (1) 00fa
psm: SET_RESOLUTION (3) 00fa
psm: SET_RESOLUTION (1) 00fa
psm: SET_RESOLUTION (2) 00fa
psm: SET_RESOLUTION (3) 00fa
psm: SEND_AUX_DEV_DATA return code:00fa
psm: data 00 00 00
psm: SET_SAMPLING_RATE (200) 00fa
psm: SET_SAMPLING_RATE (100) 00fa
...[there's lots more where that came from]...
psm: device ID: 0000
synaptics: BEGIN init
psm: SET_SCALING11 return code:00fa
psm: SET_RESOLUTION (0) 00fa
...
psm: status 00 14 00
elantech: BEGIN init
psm: SET_SCALING11 return code:00fa
psm: SET_SCALING11 return code:00fa
...
psm: device ID: 0000
GlidePoint: BEGIN init
psm: SET_SAMPLING_RATE (100) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_SCALING21 return code:00fa
psm: SET_SCALING21 return code:00fa
psm: SET_SCALING21 return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 10 64 00
psm0: found GlidePoint
psm: SET_RESOLUTION (100) 00fa
psm: SET_SAMPLING_RATE (2) 00fa
psm: SET_SCALING11 return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 02 64
psm0: <PS/2 Mouse> irq 12 on atkbdc0
ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 52
....


So: Among other things, it appears that the number of buttons is
determined in psm(4) before it (thinks it) knows what specific type
of hardware this is.  So I'm not seeing how I could teach psm(3)
to make allowance for this (oddball?) hardware.

And... Dell also offers the machine with some flavor of Ubuntu(?)
pre-installed.  So I suspect that some folks have figured out how to
make this beastie work.  (I bought mine reburbished; it didn't come with
Ubuntu installed... and I wouldn't know how to get information like the
above from that environment anyway.)

(A correspondent over in mobile@ suggested snipping out the code that
matches GlidePoint, allowing psm(4) to treat the device as a generic
ps/2 mouse.  I tried that, but saw no change in the behavior -- and
looking over the psm(4) man page for flags I could set didn't turn up
anything that was obvious to me.)

Hints?

Thanks!

Peace,
david
--
David H. Wolfskill [hidden email]
Trump administration: victimizing the defrauded and supporting the fraudsters

See http://www.catwhisker.org/~david/publickey.gpg for my public key.

signature.asc (631 bytes) Download Attachment