ACPI and the psmouse alps driver
While I'm thinking of it, in the my last alps driver dkms, I put in an ACPI interface to uniquely detect the touchpad type. After spending a good couple of days figuring out the ACPI spec and this mysterious _HID (hardware id) and _CID (compatibility id) as it relates to how ALPS identifies its touchpads, I can confirm Linus' quote ACPI is a complete design disaster in every way. But we're kind of stuck with it. Some ALPS touchpads have different _HID values. Some have the same _HID but different behavior. As far as I can tell ACPI has varying degrees of usefulness based on the h/w manufacturer. The ALPS MS Windows drivers appear to use ACPI to figure out if the touchpad is, in fact, from ALPS and then a complicated series of proprietary retrievals to figure out the behavior. -- 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
Question about psmouse alps driver patches
I submitted normalized patches to Canonical Ubuntu in October for the alps psmouse touchpad. The thread is long and confusing at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238 Since then, I have maintained a psmouse dlkm that provides alps support for a number of new systems, primarily from Dell. Recently, I have been asked by several people to submit the patches to linux-input to merge into the upstream kernel. I am looking for advice on how to proceed. The big problems are: 1) The alps touchpads seem to be mutating relatively quickly with several unrecognized signatures appearing over the last few months after I built my patches. 2) A number of people have submitted a patch for a particular alps touchpad signature, which will need to be reconciled and rolled-up into a single driver. See the Jan 20 3-part submission by cerne...@gmail.com. His patches look good, and clean up the code a good bit, but target a touchpad signature also reverse-engineered by bgarami.f...@gmail.com. I integrated the bgarami fixes into my patches but the patches from cerne...@gmail.com are radically different. 3) I built the patches against the 3.2 kernel. My understanding is they do not even compile against the kernel head - something like 3.5.x. I feel bad submitting the patches I have. They are big and rough because several of us reverse-engineered the ALPS interfaces but did not try to figure them out. It will take a lot of merge+test work to reconcile the patch submissions for the various alps target platforms. What do you suggest I do (e.g. submit a patch for only the new protocol I can test?) -- 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
Re: New Alps protocol in the wild?
On 09/08/2012 08:51 AM, dturvene wrote: On 08/17/2012 01:04 PM, Ben Gamari wrote: dturvene dturv...@dahetral.com writes: Ben - I tried your fix on a Dell Inspiron 15R N5110 (I15R). It did not work. Things I noticed: 1) Consistent with prior observations, the touchpad E7 signature for it is: 0x73 0x03 0x50, different than yours on the E6230. Alright. Good to know. 2) Your alps_hw_init_v5 sequence does not work for my I15R. I noticed that the sequence enters/exits command mode a couple times. Why not enter once, do the init and then exit? Frankly, I didn't put much (honestly, any) time into figuring out the meaning behind command sequence. I grabbed a dump from the VM and implemented exactly what the Windows driver did. At that point I was under the impression I was dealing with an entirely new protocol so it didn't make much sense to put time into reasoning out the command structure. Given the v3 report format is used I should revisit this. I'll hopefully have a chance to do this this weekend. Given you seem to recognize the command structure, you could probably do this even faster than me. Take a stab at it if you feel so inclined. Pull requests accepted. 3) When in command mode, the I15R accurately sets and retrieves registers (e.g. 0x0008 returns 0x00 0x08 0x02). When not in command mode, all register reads return -1. Oddly, the check in alps_enter_command_mode is 0x73 0x01 rather than 0x88 0x07. So I think either I'm doing something wrong or I'm dealing with YAAP (Yet Another ALPS Protocol). Hopefully not. My question: how did you get the protocol trace? I think you said previously that the drive does some direct register I/O. I couldn't see anything beyond PS/2 commands running under Virtual Box. I used Seth Foreshee's method[1] under Qemu. Note that the Alps driver for the E6230 (and, given the behavior you see, likely your machine as well) checks for the presence of an entry in the ACPI DSDT (if not present, the driver falls back onto generic PS/2 behavior). Consequently, you may need to do some editing of the Qemu DSDT as pointed out earlier in this thread by James (Message-Id: 20120814103553.GF23370@arianrhod.panaceas.james.local) I'm not terribly familiar with ACPI, I'll defer to him to explain precisely how he determined the relevant sections. Cheers, - Ben [1] http://swapspace.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html Hi Ben, etc. - I just got back to looking at the Alps driver on a Dell IR15 N5110. I was using Virtualbox but switched to Qemu (1.1.1) based on your progress, patched the ps2.c and acpi-dsdt.dsl (making sure to build the hex file included in acpi.c .) I'm running vista as the guest OS, which normally loads a generic ps/2 driver. The Alps touchpad works and ps2 events are being logged. When I try to install the Alps driver, it fails because (I guess) qemu has a preconfigured notion of what hardware is running. I'm trying to figure out how to configure qemu to detect the real ALPS touchpad. I welcome from the community and you any ideas for qemu to detect the alps touchpad. Dave I finally got this working. Briefly, it's a new protocol to init the device and the 6-byte packets coming from it are a new format. I didn't spend much time trying to understand the init sequence, just stuck the qemu packet dump into a new (V6) init function. But it works; probably needs to be tightened up a little. I don't understand the thought process behind the different protocols. It seems like the NRE to keep writing test and production drivers would be unsustainable. I created a psmouse DLKM with a README at [1]. If there's anybody else with an N5110 who wants to try it out please post your comments. [1]: http://www.dahetral.com/public-download -- 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
Re: New Alps protocol in the wild?
On 08/17/2012 01:04 PM, Ben Gamari wrote: dturvene dturv...@dahetral.com writes: Ben - I tried your fix on a Dell Inspiron 15R N5110 (I15R). It did not work. Things I noticed: 1) Consistent with prior observations, the touchpad E7 signature for it is: 0x73 0x03 0x50, different than yours on the E6230. Alright. Good to know. 2) Your alps_hw_init_v5 sequence does not work for my I15R. I noticed that the sequence enters/exits command mode a couple times. Why not enter once, do the init and then exit? Frankly, I didn't put much (honestly, any) time into figuring out the meaning behind command sequence. I grabbed a dump from the VM and implemented exactly what the Windows driver did. At that point I was under the impression I was dealing with an entirely new protocol so it didn't make much sense to put time into reasoning out the command structure. Given the v3 report format is used I should revisit this. I'll hopefully have a chance to do this this weekend. Given you seem to recognize the command structure, you could probably do this even faster than me. Take a stab at it if you feel so inclined. Pull requests accepted. 3) When in command mode, the I15R accurately sets and retrieves registers (e.g. 0x0008 returns 0x00 0x08 0x02). When not in command mode, all register reads return -1. Oddly, the check in alps_enter_command_mode is 0x73 0x01 rather than 0x88 0x07. So I think either I'm doing something wrong or I'm dealing with YAAP (Yet Another ALPS Protocol). Hopefully not. My question: how did you get the protocol trace? I think you said previously that the drive does some direct register I/O. I couldn't see anything beyond PS/2 commands running under Virtual Box. I used Seth Foreshee's method[1] under Qemu. Note that the Alps driver for the E6230 (and, given the behavior you see, likely your machine as well) checks for the presence of an entry in the ACPI DSDT (if not present, the driver falls back onto generic PS/2 behavior). Consequently, you may need to do some editing of the Qemu DSDT as pointed out earlier in this thread by James (Message-Id: 20120814103553.GF23370@arianrhod.panaceas.james.local) I'm not terribly familiar with ACPI, I'll defer to him to explain precisely how he determined the relevant sections. Cheers, - Ben [1] http://swapspace.forshee.me/2011/11/touchpad-protocol-reverse-engineering.html Hi Ben, etc. - I just got back to looking at the Alps driver on a Dell IR15 N5110. I was using Virtualbox but switched to Qemu (1.1.1) based on your progress, patched the ps2.c and acpi-dsdt.dsl (making sure to build the hex file included in acpi.c .) I'm running vista as the guest OS, which normally loads a generic ps/2 driver. The Alps touchpad works and ps2 events are being logged. When I try to install the Alps driver, it fails because (I guess) qemu has a preconfigured notion of what hardware is running. I'm trying to figure out how to configure qemu to detect the real ALPS touchpad. I welcome from the community and you any ideas for qemu to detect the alps touchpad. Dave -- 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
Re: New Alps protocol in the wild?
On 08/16/2012 01:04 AM, Ben Gamari wrote: Ben Gamari bgamari.f...@gmail.com writes: snip Hopefully I'll find some more time in the next few days to figure out the last few bits (primarily how multitouch events work). I wouldn't be sad if someone finished the task for me, however. Success! As it turns out, the process was actually not so bad. While I wasted much of the night trying to reverse the protocol, I realized that what I had come up with was nearly identical to the version 3 documentation. Trying the version 3 protocol with the device, I found that it was nearly immediately functional. It seems that while the initialization procedure has changed, the position report format is identical to previous generations. My tree[1] currently has a hacked brute-force initialization implementation, although it would probably be nice to figure out what this sequence actually means. Otherwise, it seems support for this device is a solved problem. Feel free to give my tree a try. I'd be interested to know whether it works for you. Cheers, - Ben [1] https://github.com/bgamari/linux/tree/alps Ben - I tried your fix on a Dell Inspiron 15R N5110 (I15R). It did not work. Things I noticed: 1) Consistent with prior observations, the touchpad E7 signature for it is: 0x73 0x03 0x50, different than yours on the E6230. 2) Your alps_hw_init_v5 sequence does not work for my I15R. I noticed that the sequence enters/exits command mode a couple times. Why not enter once, do the init and then exit? 3) When in command mode, the I15R accurately sets and retrieves registers (e.g. 0x0008 returns 0x00 0x08 0x02). When not in command mode, all register reads return -1. Oddly, the check in alps_enter_command_mode is 0x73 0x01 rather than 0x88 0x07. So I think either I'm doing something wrong or I'm dealing with YAAP (Yet Another ALPS Protocol). My question: how did you get the protocol trace? I think you said previously that the drive does some direct register I/O. I couldn't see anything beyond PS/2 commands running under Virtual Box. Dave -- 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
