| Message ID | 20120814103553.GF23370@arianrhod.panaceas.james.local (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
James <linux-input@madingley.org> writes: > I just got a Dell E6230 with the same E7 report: 73 03 0a > As noted above using the qemu serio logging doesn't work. > The driver only enables multitouch if it sees the right > name for the device in the DSDT. > > The following patch (against the seabios in qemu-0.14.1) > enables the windows 7 driver (7.1211.101.114 from > http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats/Product/latitude-e6230?DriverId=CKNFN&FileId=2988050063&urlProductCode=False > ) to bind successfully and alows one to get data from the serio > logging patch > > Are there any standard tools for reverse engineering the > protocol - I saw mention of an alps-reg-dump but was > unable to find it? > alps-reg-dump can be found here[1]. Depending upon how different the protocol is it may or may not be useful, however. Cheers, - Ben [1] http://kernel.ubuntu.com/git?p=sforshee/alps-reg-dump.git;a=summary -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Aug 14, 2012 at 12:01:29PM -0400, Ben Gamari wrote: > James <linux-input@madingley.org> writes: > > > I just got a Dell E6230 with the same E7 report: 73 03 0a > > As noted above using the qemu serio logging doesn't work. > > The driver only enables multitouch if it sees the right > > name for the device in the DSDT. > > > > The following patch (against the seabios in qemu-0.14.1) > > enables the windows 7 driver (7.1211.101.114 from > > http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats/Product/latitude-e6230?DriverId=CKNFN&FileId=2988050063&urlProductCode=False > > ) to bind successfully and alows one to get data from the serio > > logging patch > > > > Are there any standard tools for reverse engineering the > > protocol - I saw mention of an alps-reg-dump but was > > unable to find it? > > > alps-reg-dump can be found here[1]. Depending upon how different the > protocol is it may or may not be useful, however. Just a warning that I haven't updated that in quite some time, and I'm not even sure exactly how far I was in reverse engineering the protocol when I stopped updating it. So it may or may not be useful to you. Seth -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
After doing some fiddling around myself, I've put together a few tools
and I think I now have the beginnings of an understanding of the report
frame structure. I've attached some notes below. The data packets
appear to be 6 bytes long, consistent with earlier versions of the
protocol. The first and fifth bytes of the touchpad packet are still
quite mysterious. While they likely have something to do with
multitouch, they both fluctuate even with single touch events. Touchpad
packets can be distinguished from stick packets by examining the byte 5,
which is 0x3f (out of the range of the pressure field) in touchstick
packets.
I've also attached two tools I've developed. ps2-parse.py annotates PS/2
traces produced by the VM with common command names (simply pipe a trace
in to stdin, out comes the annotate trace on stdout). Alps.py is a first
attempt at communicating with the hardware. It currently has the ability
to put playback a trace (say, the attached serio-init.log) and start
dumping frames to stdout. It also has an incomplete version of the
initialization sequence (enter_absolute_mode).
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.
Cheers,
- Ben
Touchpad Packet format:
byte 0: ??? starts with 0x9f, 0x8f, changes
0x10: ??
0x20: ??
0x8f: Always set
Only 0x10 and 0x20 are set with single-touch events. 0x40 seems to be set with multitouch events
byte 1: X position? (- is left, + is right)
byte 2: Y position? (- is up, + is down)
byte 3: button state:
0x1: left touchpad
0x2: right touchpad
0x4: middle touchpad?
0x8: Always set?
0x10: left touchstick
0x20: right touchstick
0x40: middle touchstick
0x80: ???
byte 4: ???
byte 5: Pressure (0x00 - 0x3e)
0x3f: Reporting stick?
Touchstick Packet format:
byte 0: 0x10: Y Sign
0x20: X Sign
0x4f: Always set
byte 1: X pressure (0 - 0x7f)
byte 2: Y pressure (0 - 0x7f)
byte 3: always 0x48
byte 4: Z pressure (0 - 0x7c)
byte 5: always 0x3f
Ben Gamari <bgamari.foss@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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/16/2012 01:04 AM, Ben Gamari wrote: > Ben Gamari <bgamari.foss@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dturvene <dturvene@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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/17/2012 01:04 PM, Ben Gamari wrote: > dturvene <dturvene@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dturvene <dturvene@dahetral.com> writes: > On 08/17/2012 01:04 PM, Ben Gamari wrote: snip > 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. > If the D6430 is any indication, it seems the driver likely only checks the DSDT. Are you certain you modified this correctly to reflect your machine? You'll need to carefully compare the DSDT of your machine and that of Qemu. Given that James was the one to initially crack this one, he might have some more concrete advice. Cheers, - Ben -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/08/2012 08:51 AM, dturvene wrote: > On 08/17/2012 01:04 PM, Ben Gamari wrote: >> dturvene <dturvene@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/29/2012 05:55 AM, Ignacio Casal Quinteiro wrote: > Hey hey, > > any news about this? > > Regards. > There's been a good bit of progress on this, and testing is ongoing. For current status see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606238 I have something to work on this week but will push the diffs/documentation upstream as soon as I can. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- ./qemu-0.14.1/roms/seabios/src/acpi-dsdt.dsl 2011-05-06 20:02:01.000000000 +0100 +++ ./qemu-0.14.1.jmm/roms/seabios/src/acpi-dsdt.dsl 2012-08-14 11:09:22.000000000 +0100 @@ -253,7 +253,7 @@ } /* Keyboard seems to be important for WinXP install */ - Device (KBD) + Device (PS2K) { Name (_HID, EisaId ("PNP0303")) Method (_STA, 0, NotSerialized) @@ -261,10 +261,8 @@ Return (0x0f) } - Method (_CRS, 0, NotSerialized) + Name (_CRS, ResourceTemplate () { - Name (TMP, ResourceTemplate () - { IO (Decode16, 0x0060, // Address Range Minimum 0x0060, // Address Range Maximum @@ -277,30 +275,52 @@ 0x01, // Address Alignment 0x01, // Address Length ) + IRQ (Edge, ActiveHigh, Exclusive, ) + {1} + + }) + + + + + Name (_PRS, ResourceTemplate () + { + StartDependentFn (0x00, 0x00) + { + FixedIO ( + 0x0060, // Address + 0x01, // Length + ) + FixedIO ( + 0x0064, // Address + 0x01, // Length + ) IRQNoFlags () {1} - }) - Return (TMP) } - } + EndDependentFn () + }) + } /* PS/2 mouse */ - Device (MOU) + Device (PS2M) { - Name (_HID, EisaId ("PNP0F13")) - Method (_STA, 0, NotSerialized) - { - Return (0x0f) - } - - Method (_CRS, 0, NotSerialized) + Name (_CID, EisaId ("PNP0F13")) + Name (_HID, EisaId ("DLL0532")) + Name (_CRS, ResourceTemplate () + { + IRQ (Edge, ActiveHigh, Exclusive, ) + {12} + }) + Name (_PRS, ResourceTemplate () + { + StartDependentFn (0x00, 0x00) { - Name (TMP, ResourceTemplate () - { - IRQNoFlags () {12} - }) - Return (TMP) + IRQNoFlags () + {12} } + EndDependentFn () + }) } /* PS/2 floppy controller */