Comment 351 for bug 606238


Response to comments 348, 349, 350:

The easiest, and I mean *easiest*, way is to hack alps.c for the raw input from the touchpad and then "xinput setprop" to tune the X11 cooked input.

For brand-new alps touchpads that don't adhere to any of the known protocols, this is not sufficient and one needs to reverse engineer the Windows driver behavior. Seth Forshee showed us the way and then Ben Garami figured out the the new extensions. I seriously doubt this will be the case for you.

Use Virtualbox or Qemu to create a guest OS. I used Vista. Seth showed how to patch the I/O layer to dump the bytes going between the guest driver and the hardware. The catch is that the new alps drivers check the BIOS ACPI DSDT tables to make sure it's an ALPS hardware module; if not it drops into 3-byte PS2 mode. Therefore the virtual ACPI DSDT table must be updated to use the Hardware ID (HID) for the alps hardware model (taken from the real ACPI DSDT table.) If this sounds a little complicated, it is. Make sure you install the Alps driver into the guest OS!

In the from the 1.3 DLKM, there are some helper routines to get the real DSDT and patch the qemu acpi-dsdt.dsl table for the correct HID.

There is another way to reverse engineer an ALPS touchpad, discovered by Kevin Cernekee but it's not totally reliable. It worked for him, and cleaned up the E6430 code a good deal. Email Kevin directly for how to do it.