Date: Sun, 18 Mar 2018 17:26:20 -0700 From: David Wolfskill <david@catwhisker.org> To: hackers@freebsd.org Subject: Just HOW many buttons did that mouse claim to have??!? Message-ID: <20180319002620.GC1233@albert.catwhisker.org>
next in thread | raw e-mail | index | archive | help
--kVXhAStRUZ/+rrGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D(\bCateg= oryLaptop\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=3D2 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 =3D=3D 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 =2E..[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 =2E.. psm: status 00 14 00 elantech: BEGIN init psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa =2E.. 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 =2E... 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 --=20 David H. Wolfskill david@catwhisker.org Trump administration: victimizing the defrauded and supporting the fraudste= rs See http://www.catwhisker.org/~david/publickey.gpg for my public key. --kVXhAStRUZ/+rrGn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlqvA6xfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7heewAf/Ss2YqzEjftmCaRR9il4RKZgtsdiUgNsfO/ZjleBlltrYGVLI+iZcdJJN B1DKbq7KcV/gsKtTZpyUsuRF1TBG0EGFcvCV6pqpsb8TL4mE9Il+NwrM7kX/UTKT wddE7WEFQcjHIDFomrXx6TSigusldsZyNa5mL1QUreuPXk74g3NdBjt5aIr/Gxbc Pqjd5rJjjdIwr1IwwkkFEdlpU4uO0JWpKhemsMBEnUD0cp554BEnHCBbb38TO8SK oS3QSzh/L7mxJXE1f8RExU1b6tpYhDIDna2dB5uMMtLz9ZSw8HNJ29MwVS70/xCj cuJqbgLC+X6TTLFnHnZWbsvyxH+M5Q== =Jniz -----END PGP SIGNATURE----- --kVXhAStRUZ/+rrGn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180319002620.GC1233>