Recently I took shipment of a Dell Latitude E6430 (supposedly "certified" by Canonical). Sadly, out of the box the multitouch-capable Alps Dualpoint mouse is detected as a generic PS/2 device (bug filed here[1]). After a bit of poking around I figured out the signature ({0x73, 0x03, 0x0a}) and command_mode_resp (0x1d) of the device.
Based on the other recent Dell models listed in alps_model_data, I tried configuring the device as a protocol v3 device. While in appearance the driver succeeded in configuring the device, it was clear that it was still operating in bare PS/2 mode (only bare PS/2 reports were received and 0x04 register was read to be 0x00 --- assuming the register read command is correct). This is supported by Seth's alps-reg-dump tool[2], which declares that the device is "Not a v3 ALPS touchpad". Trying to configure the device with protocol v4 resulted in the driver to fail during configuration (failing to enter absolute mode). Given this evidence, it seems fairly clear that this device differs appreciably from any device currently supported by alps.c. I've tried to collect PS/2 traces from a Windows 7 installation running under a patched Qemu[3]. Unfortunately, while Windows running on bare hardware configures the device perfectly, an installation from the same media seems to treat the device as a bare PS/2 device when running under virtualization. The PS/2 trace produced clearly shows the driver probing the device as an Intellimouse and failing that falls back to generic PS/2 reports. Can anyone think of what might have changed between the bare metal and the virtualized environment? I would love to take a stab at reversing this protocol variant, but the inability to get a trace from a virtualized working configuration is a real blocker. I suppose I could try writing a Windows filter driver but the virtualization approach seems orders of magnitude more convenient. Any ideas would be greatly appreciated. As a final note, I have read various places that ALPS had intended on releasing a closed source driver for some of their devices. Has anything happened on this front? Perhaps it would be easier to get a trace from a closed-source driver running on Linux than a closed-source driver running on Windows. Thanks again. Cheers, - Ben [1] https://bugzilla.kernel.org/show_bug.cgi?id=45201 [2] http://kernel.ubuntu.com/git?p=sforshee/alps-reg-dump.git;a=summary [3] http://swapspace.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html