New Alps protocol in the wild?

New Alps protocol in the wild?

[Ben Gamari]

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

Re: New Alps protocol in the wild?

[Seth Forshee]

On Fri, Jul 27, 2012 at 12:18:51PM -0400, Ben Gamari wrote:
> 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.

That's likely. It's known that there's at least one ALPS protocol
version that isn't supported.

> 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'm thinking that when I was looking at the initialization from Windows
drivers it would first initialize it like a normal PS/2 mouse then later
the ALPS initialization would show up, almost like the default driver
ran through it's initialization first before the ALPS driver did. Did
you look further down in the logs to see if anything similar to the ALPS
initialization is happening later?

Otherwise I don't have any ideas off the top of my head. This approach
generally worked fine with the machines/drivers I worked with.

> 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.

I've heard that such a driver exists, but I don't know where you can get
it. I _think_ some factory preinstalled Linux systems might ship with
it, so it's possible that it's something ALPS provides to its customers
but doesn't make publicly available.

Cheers,
Seth

Re: New Alps protocol in the wild?

[Ben Gamari]

Seth Forshee <seth.forshee@canonical.com> writes:

> On Fri, Jul 27, 2012 at 12:18:51PM -0400, Ben Gamari wrote:
>> 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.
>
> That's likely. It's known that there's at least one ALPS protocol
> version that isn't supported.
>
I suspected that was the case.

>> 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'm thinking that when I was looking at the initialization from Windows
> drivers it would first initialize it like a normal PS/2 mouse then later
> the ALPS initialization would show up, almost like the default driver
> ran through it's initialization first before the ALPS driver did. Did
> you look further down in the logs to see if anything similar to the ALPS
> initialization is happening later?
>
Sadly no. The driver comes with a configuration tool which when launched
appears to trigger a reconfiguration.

> Otherwise I don't have any ideas off the top of my head. This approach
> generally worked fine with the machines/drivers I worked with.
>
Hmmm, that is truly unfortunate. I guess given this I'll just have to
try piecing together a filter driver and collect the initialization
process on bare metal. Hopefully at that point I'll be able to do the
reversing of the data format over serio.

>> 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.
>
> I've heard that such a driver exists, but I don't know where you can get
> it. I _think_ some factory preinstalled Linux systems might ship with
> it, so it's possible that it's something ALPS provides to its customers
> but doesn't make publicly available.
>
Naturally. I never would have suspected that such a despicable company
could be found in making something as innocuous as touchpads. Sheesh.

Given the difficulty of the reverse engineering process and the
proliferation of incompatible hardware variants, it seems a major
customer really needs to step up and demand some sanity from these
people. My understanding is that Dell currently does not have access to
Alps specifications but given the volume they move it seems they are in
a fairly unique position to exert pressure. Being a Dell partner, has
Canonical taken any steps to start this dialogue?

On that note, Canonical's certification certificate for the E6430 is
currently incorrect. The desktop program guidelines clearly state that
vertical scroll is on the grey list yet, as far as I can tell, the
certificate makes no mention of the lacking support of the input
hardware of this model.

Cheers,

- Ben

Re: New Alps protocol in the wild?

[dturvene]

Coming late the discussion, responses inline - Dave

On 07/27/2012 01:17 PM, Ben Gamari wrote:
> Seth Forshee <seth.forshee@canonical.com> writes:
>
>> On Fri, Jul 27, 2012 at 12:18:51PM -0400, Ben Gamari wrote:
>>> 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.
>> That's likely. It's known that there's at least one ALPS protocol
>> version that isn't supported.
>>
> I suspected that was the case.
I have a Dell I15R N5110 running Ubuntu 12.04 with the same signature 
and behavior.

Vbox with sforshee patch running Vista shows only ps/2 packets.  I 
hypothesized that the Vista driver didn't recognize the device either, 
but handled keyboard/touchpad event separation better.

I wrote a small serio_raw program to test the device.  Alps command mode 
works, but the GETINFO response when entering command mode is: 0x73, 
0x01, 0x0d, which fails the 0x88, 0x07 check in the alps.c code.  Once 
in command mode, the v3 logic (PSMOUSE_CMD_RESET_WRAP) works and I get 
the register number and value back from PSMOUSE_CMD_GETINFO.  v4 logic 
returns garbage.

>>> 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'm thinking that when I was looking at the initialization from Windows
>> drivers it would first initialize it like a normal PS/2 mouse then later
>> the ALPS initialization would show up, almost like the default driver
>> ran through it's initialization first before the ALPS driver did. Did
>> you look further down in the logs to see if anything similar to the ALPS
>> initialization is happening later?
>>
> Sadly no. The driver comes with a configuration tool which when launched
> appears to trigger a reconfiguration.
>
>> Otherwise I don't have any ideas off the top of my head. This approach
>> generally worked fine with the machines/drivers I worked with.
>>
> Hmmm, that is truly unfortunate. I guess given this I'll just have to
> try piecing together a filter driver and collect the initialization
> process on bare metal. Hopefully at that point I'll be able to do the
> reversing of the data format over serio.
Yeah, unfortunate.  I may just use a usb mouse if it comes to that...
>
>>> 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.
>> I've heard that such a driver exists, but I don't know where you can get
>> it. I _think_ some factory preinstalled Linux systems might ship with
>> it, so it's possible that it's something ALPS provides to its customers
>> but doesn't make publicly available.
>>
> Naturally. I never would have suspected that such a despicable company
> could be found in making something as innocuous as touchpads. Sheesh.
>
> Given the difficulty of the reverse engineering process and the
> proliferation of incompatible hardware variants, it seems a major
> customer really needs to step up and demand some sanity from these
> people. My understanding is that Dell currently does not have access to
> Alps specifications but given the volume they move it seems they are in
> a fairly unique position to exert pressure. Being a Dell partner, has
> Canonical taken any steps to start this dialogue?
>
> On that note, Canonical's certification certificate for the E6430 is
> currently incorrect. The desktop program guidelines clearly state that
> vertical scroll is on the grey list yet, as far as I can tell, the
> certificate makes no mention of the lacking support of the input
> hardware of this model.

My I15R was certified also, and currently incorrect.  I posted a query 
to Dell about Alps support but haven't heard anything back.  I suspect 
Alps and Dell are wary of offending Microsoft.

>
> 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
>

Re: New Alps protocol in the wild?

[Jiri Kosina]

[ Dmitry should be CCed on this ... adding him ]

On Fri, 27 Jul 2012, dturvene wrote:

> Coming late the discussion, responses inline - Dave
> 
> On 07/27/2012 01:17 PM, Ben Gamari wrote:
> > Seth Forshee <seth.forshee@canonical.com> writes:
> > 
> > > On Fri, Jul 27, 2012 at 12:18:51PM -0400, Ben Gamari wrote:
> > > > 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.
> > > That's likely. It's known that there's at least one ALPS protocol
> > > version that isn't supported.
> > > 
> > I suspected that was the case.
> I have a Dell I15R N5110 running Ubuntu 12.04 with the same signature and
> behavior.
> 
> Vbox with sforshee patch running Vista shows only ps/2 packets.  I
> hypothesized that the Vista driver didn't recognize the device either, but
> handled keyboard/touchpad event separation better.
> 
> I wrote a small serio_raw program to test the device.  Alps command mode
> works, but the GETINFO response when entering command mode is: 0x73, 0x01,
> 0x0d, which fails the 0x88, 0x07 check in the alps.c code.  Once in command
> mode, the v3 logic (PSMOUSE_CMD_RESET_WRAP) works and I get the register
> number and value back from PSMOUSE_CMD_GETINFO.  v4 logic returns garbage.
> 
> > > > 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'm thinking that when I was looking at the initialization from Windows
> > > drivers it would first initialize it like a normal PS/2 mouse then later
> > > the ALPS initialization would show up, almost like the default driver
> > > ran through it's initialization first before the ALPS driver did. Did
> > > you look further down in the logs to see if anything similar to the ALPS
> > > initialization is happening later?
> > > 
> > Sadly no. The driver comes with a configuration tool which when launched
> > appears to trigger a reconfiguration.
> > 
> > > Otherwise I don't have any ideas off the top of my head. This approach
> > > generally worked fine with the machines/drivers I worked with.
> > > 
> > Hmmm, that is truly unfortunate. I guess given this I'll just have to
> > try piecing together a filter driver and collect the initialization
> > process on bare metal. Hopefully at that point I'll be able to do the
> > reversing of the data format over serio.
> Yeah, unfortunate.  I may just use a usb mouse if it comes to that...
> > 
> > > > 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.
> > > I've heard that such a driver exists, but I don't know where you can get
> > > it. I _think_ some factory preinstalled Linux systems might ship with
> > > it, so it's possible that it's something ALPS provides to its customers
> > > but doesn't make publicly available.
> > > 
> > Naturally. I never would have suspected that such a despicable company
> > could be found in making something as innocuous as touchpads. Sheesh.
> > 
> > Given the difficulty of the reverse engineering process and the
> > proliferation of incompatible hardware variants, it seems a major
> > customer really needs to step up and demand some sanity from these
> > people. My understanding is that Dell currently does not have access to
> > Alps specifications but given the volume they move it seems they are in
> > a fairly unique position to exert pressure. Being a Dell partner, has
> > Canonical taken any steps to start this dialogue?
> > 
> > On that note, Canonical's certification certificate for the E6430 is
> > currently incorrect. The desktop program guidelines clearly state that
> > vertical scroll is on the grey list yet, as far as I can tell, the
> > certificate makes no mention of the lacking support of the input
> > hardware of this model.
> 
> My I15R was certified also, and currently incorrect.  I posted a query to Dell
> about Alps support but haven't heard anything back.  I suspect Alps and Dell
> are wary of offending Microsoft.
> 
> > 
> > Cheers,
> > 
> > - Ben

-- 
Jiri Kosina
SUSE Labs

Re: New Alps protocol in the wild?

[Ben Gamari]

Just to keep everyone in the loop, I've tried both VirtualBox and Qemu
now and the Alps driver appears to work under neither. After some
reflection, I finally resolved to brave the jungle that is Windows
driver development and now have the beginnings of a PS/2 filter
driver[1]. It's quite hacked together and is likely a textbook example
of how not to write a Windows driver, but it's nearly working. That
being said, if anyone has experience with NT kernel development, feel
free to assist in any way you can.

That being said, I'd recommend you don't install it at the moment; it
currently BSODs from use of DebugPrint in an ISR. Before breaking it,
however, I was able to get incoming data from the trackpad. The breaking
changes were an attempt to gather outgoing commands to the device so I'm
(hopefully) not far from having traces.

Cheers,

- Ben


[1] https://github.com/bgamari/ps2log

Re: New Alps protocol in the wild?

[Ben Gamari]

Ben Gamari <bgamari.foss@gmail.com> writes:

> Just to keep everyone in the loop, I've tried both VirtualBox and Qemu
> now and the Alps driver appears to work under neither. After some
> reflection, I finally resolved to brave the jungle that is Windows
> driver development and now have the beginnings of a PS/2 filter
> driver[1]. It's quite hacked together and is likely a textbook example
> of how not to write a Windows driver, but it's nearly working. That
> being said, if anyone has experience with NT kernel development, feel
> free to assist in any way you can.
>
> That being said, I'd recommend you don't install it at the moment; it
> currently BSODs from use of DebugPrint in an ISR. Before breaking it,
> however, I was able to get incoming data from the trackpad. The breaking
> changes were an attempt to gather outgoing commands to the device so I'm
> (hopefully) not far from having traces.
>
Sadly, this avenue of investigation is apparently a dead-end. After
seeing nothing outbound to the mouse and hacking around enough to
convince myself that filter driver is catching all traffic passed
through the i8042prt driver, I finally decided to disassemble
apfiltr.sys. Perhaps not unexpectedly, it seems they do some direct port
I/O without going through the driver stack. Whether this is incompetance
or malice we will never know, but it seems that the "clean" filter
driver approach will not work here.

Thankfully, it seems that an I/O port sniffer driver[1] has been written
which might save me. Sadly, this isn't supported on 64-bit machines as
Microsoft's compiler inexplicably lacks support for inline assembler on
amd64. I've found a 32-bit copy of Vista lying around so we'll see how
this works.

Of course, if anyone has any idea what might be breaking the
virtualization approach, I'd love to hear. Moreover, if anyone knows
someone (at Dell or elsewhere) who might be able to get a hold of an ear
at Alps, this would be greatly appreciated.

Cheers,

- Ben


[1] http://www.codeproject.com/Articles/96142/I-O-port-sniffer

Re: New Alps protocol in the wild?

[Dmitry Torokhov]

On Tue, Jul 31, 2012 at 01:19:24AM -0400, Ben Gamari wrote:
> Ben Gamari <bgamari.foss@gmail.com> writes:
> 
> > Just to keep everyone in the loop, I've tried both VirtualBox and Qemu
> > now and the Alps driver appears to work under neither. After some
> > reflection, I finally resolved to brave the jungle that is Windows
> > driver development and now have the beginnings of a PS/2 filter
> > driver[1]. It's quite hacked together and is likely a textbook example
> > of how not to write a Windows driver, but it's nearly working. That
> > being said, if anyone has experience with NT kernel development, feel
> > free to assist in any way you can.
> >
> > That being said, I'd recommend you don't install it at the moment; it
> > currently BSODs from use of DebugPrint in an ISR. Before breaking it,
> > however, I was able to get incoming data from the trackpad. The breaking
> > changes were an attempt to gather outgoing commands to the device so I'm
> > (hopefully) not far from having traces.
> >
> Sadly, this avenue of investigation is apparently a dead-end. After
> seeing nothing outbound to the mouse and hacking around enough to
> convince myself that filter driver is catching all traffic passed
> through the i8042prt driver, I finally decided to disassemble
> apfiltr.sys. Perhaps not unexpectedly, it seems they do some direct port
> I/O without going through the driver stack. Whether this is incompetance
> or malice we will never know, but it seems that the "clean" filter
> driver approach will not work here.
> 
> Thankfully, it seems that an I/O port sniffer driver[1] has been written
> which might save me. Sadly, this isn't supported on 64-bit machines as
> Microsoft's compiler inexplicably lacks support for inline assembler on
> amd64. I've found a 32-bit copy of Vista lying around so we'll see how
> this works.
> 
> Of course, if anyone has any idea what might be breaking the
> virtualization approach, I'd love to hear.

Given how unwilling they are to share details of their protocol I would
not be surprised if they tried to detect virtual environment on purpose.

Thanks.

-- 
Dmitry

Re: New Alps protocol in the wild?

[Ben Gamari]

Ben Gamari <bgamari.foss@gmail.com> writes:

> Sadly, this avenue of investigation is apparently a dead-end. After
> seeing nothing outbound to the mouse and hacking around enough to
> convince myself that filter driver is catching all traffic passed
> through the i8042prt driver, I finally decided to disassemble
> apfiltr.sys. Perhaps not unexpectedly, it seems they do some direct port
> I/O without going through the driver stack. Whether this is incompetance
> or malice we will never know, but it seems that the "clean" filter
> driver approach will not work here.
>
> Thankfully, it seems that an I/O port sniffer driver[1] has been written
> which might save me. Sadly, this isn't supported on 64-bit machines as
> Microsoft's compiler inexplicably lacks support for inline assembler on
> amd64. I've found a 32-bit copy of Vista lying around so we'll see how
> this works.
>
Unfortunately, it seems that this approach too may be a dead end. The
iosniffer driver appears to cause an immediate reboot (triple fault?) on
installing its hooks. Given the low-level nature of the crash, the
thought of tracking it down makes me shudder. If anyone else wants to
try installing the driver, it would be nice to have a second opinion. I
guess it's back to the virtualization approach.

Cheers,

- Ben

Re: New Alps protocol in the wild?

[Ben Gamari]

Dmitry Torokhov <dmitry.torokhov@gmail.com> writes:

> Given how unwilling they are to share details of their protocol I would
> not be surprised if they tried to detect virtual environment on purpose.
>
Sadly, you very well could be right.

That being said, I don't know what they could be checking for. I'm
passing "-cpu host" to qemu which should eliminate the CPUID
hint. Otherwise, the only obvious hint I can find is the hard drive
which mentions Qemu in its vendor string. Taking a quick look at the
apfiltr.sys I can't find any strings that might imply it's looking at
device/vendor strings. Perhaps they could be using ACPI tables (although
I see no ACPI-ish strings in the driver)? I guess SMBIOS and DMI are
also targets although I know little about their implementation.

Anyways, I suppose at this point it is probably time to bring this
discussion over to the qemu list to discuss future directions for
virtualization. Unfortunately, it becomes very difficult to maintain
motivation on problems like this when Alps will likely render whatever
reverse engineering knowledge gained now obsolete in the next iteration
of hardware. It seems clear that the only sustainable way to get
open-source support for these and future Alps devices is with some
cooperation from Alps and/or a major customer. It seems that Dell is in
an ideal position to help here.

Cheers,

- Ben

Re: New Alps protocol in the wild?

[James]

[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

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?

thanks,

James.

[-- Attachment #2: make-6230-touchpad-bind-in-win7.patch --]
[-- Type: text/plain, Size: 2884 bytes --]

--- ./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 */

Re: New Alps protocol in the wild?

[Ben Gamari]

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

Re: New Alps protocol in the wild?

[Seth Forshee]

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

Re: New Alps protocol in the wild?

[Ben Gamari]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

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


  

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: alps.py --]
[-- Type: text/x-python, Size: 3064 bytes --]

#!/usr/bin/python3.2

import sys
from glob import glob
from time import sleep
import logging

logging.basicConfig(level=logging.DEBUG)

def find_serio_device():
        for f in glob('/sys/bus/serio/devices/serio*'):
                a = open('%s/description'%f).read()
                if 'i8042 AUX' in a:
                        return f

#dev = find_serio_device()
#logging.info("Found device %s" % dev)
#open('%s/drvctl'%dev, 'w').write('serio_raw')
#sleep(1)

serio_dev = sys.argv[1]
#serio_dev = glob('/dev/serio*')[0]
f = open(serio_dev, 'wb+')

def playback(cmds):
        for dir,data in cmds:
                if dir == 'S':
                        logging.debug('Sent %02x' % data)
                        f.write(bytes([data]))
                elif dir == 'R':
                        a = f.read(1)
                        logging.debug('Recieved %02x' % a[0])
                        if data != a[0]:
                                logging.warn('reply mismatch: expected %02x, saw %02x' % (data, a[0]))
                else:
                        raise RuntimeError("uh oh")

def recv_ack():
        a = b''
        logging.debug('Waiting for ACK')
        while len(a) == 0:
                a = f.read(1)
        print(len(a))
        if a != b'\xfa':
                raise RuntimeError("oops: %s" % str(a))

def reset():
        f.write(b'\xff')
        recv_ack()
        a = f.read(2)
        return a

def get_device_id():
        f.write(b'\xf2')
        recv_ack()
        a = f.read(1)
        return a

def set_resolution(arg):
        f.write(b'\xe8')
        recv_ack()
        f.write(arg)
        recv_ack()

def set_sample_rate(arg):
        f.write(b'\xf3')
        recv_ack()
        f.write(arg)
        recv_ack()

def set_1_1_scaling():
        f.write(b'\xe6')
        recv_ack()

def status_rq():
        f.write(b'\xe9')
        recv_ack()
        a = f.read(3)
        return a

def enable_data_reporting():
        f.write(b'\xf4')
        recv_ack()

def disable_data_reporting():
        f.write(b'\xf5')
        recv_ack()

def enter_absolute_mode():
        reset()
        reset()
        get_device_id()
        set_resolution(b'\x00')
        set_1_1_scaling()
        set_1_1_scaling()
        set_1_1_scaling()
        status_rq()
        set_resolution(b'\x03')
        set_sample_rate(b'\xc8')
        set_sample_rate(b'\x64')
        set_sample_rate(b'\x50')
        get_device_id()
        set_sample_rate(b'\xc8')
        set_sample_rate(b'\xc8')
        set_sample_rate(b'\x50')
        set_resolution(b'\x03')
        enable_data_reporting()

def format_bytes(bytes):
        return map(lambda b: '%02x' % b, bytes)


cmds = []
for l in open('serio-init.log'):
        (dir,data) = (l[0], int(l[1:4], 16))
        cmds.append((dir,data))

disable_data_reporting()
reset()
reset()
playback(cmds)

#enter_absolute_mode()
try:
        while True:
                a = f.read(6)
                print('  '.join(format_bytes(a)))
except KeyboardInterrupt:
        pass

#open('%s/drvctl'%dev, 'w').write('psmouse')


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: ps2-parse.py --]
[-- Type: text/x-python, Size: 2226 bytes --]

#!/usr/bin/python

import sys

def get_line():
        l = sys.stdin.readline()
        return (l[0], int(l[1:], 16))

def get_ack():
        (dir,data) = get_line()
        if dir!='R' and data!=0xfa:
                print('! Unknown reply: %02x'%data)

while True:
        notes = ''
        (dir,data) = get_line()
        if dir == 'S':
                get_ack()
                if data == 0xff:
                        notes = 'reset'
                elif data == 0xfe:
                        notes = 'resend'
                elif data == 0xf6:
                        notes = 'set defaults'
                elif data == 0xf5:
                        notes = 'disable reporting'
                elif data == 0xf4:
                        notes = 'enable reporting'
                elif data == 0xf3:
                        dir,data = get_line()
                        notes = 'set_sample_rate: %02x' % data
                        get_ack()
                elif data == 0xf2:
                        _,d = get_line()
                        notes = 'get device id: %02x' % d
                elif data == 0xf0:
                        notes = 'set remote mode'
                elif data == 0xee:
                        notes = 'set wrap mode'
                elif data == 0xec:
                        notes = 'reset wrap mode'
                elif data == 0xeb:
                        notes = 'read data'
                elif data == 0xea:
                        notes = 'set stream mode'
                elif data == 0xe9:
                        _,d1 = get_line()
                        _,d2 = get_line()
                        _,d3 = get_line()
                        notes = 'status request: %02x  resolution=%02x  rate=%02x' % (d1, d2, d3)
                elif data == 0xe8:
                        _,d = get_line()
                        notes = 'set resolution: %02x' % d
                        get_ack()
                elif data == 0xe7:
                        notes = 'set scaling 2:1'
                elif data == 0xe6:
                        notes = 'set scaling 1:1'
                else:
                        notes = 'unknown command'


        print('%s %02x     %s' % (dir, data, notes))


[-- Attachment #4: serio-init.log --]
[-- Type: application/octet-stream, Size: 2830 bytes --]

S ff
R fa
R aa
R 00
S ff
R fa
R aa
R 00
S f2
R fa
R 00
S e8
R fa
S 00
R fa
S e6
R fa
S e6
R fa
S e6
R fa
S e9
R fa
R 00
R 00
R 64
S e8
R fa
S 03
R fa
S f3
R fa
S c8
R fa
S f3
R fa
S 64
R fa
S f3
R fa
S 50
R fa
S f2
R fa
R 00
S f3
R fa
S c8
R fa
S f3
R fa
S c8
R fa
S f3
R fa
S 50
R fa
S f2
R fa
R 00
S f3
R fa
S 64
R fa
S e8
R fa
S 03
R fa
S f4
R fa
S f5
R fa
S ff
R fa
R aa
R 00
S e7
R fa
S e7
R fa
S e7
R fa
S e9
R fa
R 73
R 03
R 0a
S ea
R fa
S ec
R fa
S ec
R fa
S ec
R fa
S e9
R fa
R 88
R 08
R 1d
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S e9
R fa
R c2
R c8
R 80
S f3
R fa
S 64
R fa
S f6
R fa
S ea
R fa
S e7
R fa
S e7
R fa
S e7
R fa
S e9
R fa
R 42
R 02
R 3c
S e6
R fa
S e6
R fa
S e6
R fa
S f3
R fa
S c8
R fa
S f3
R fa
S 14
R fa
S ea
R fa
S ec
R fa
S ec
R fa
S ec
R fa
S e9
R fa
R 88
R 08
R 1d
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S f3
R fa
S 64
R fa
S e7
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 14
R fa
S e9
R fa
R c2
R c4
R 00
S f0
R fa
S e7
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 02
R fa
S f3
R fa
S c8
R fa
S e9
R fa
R c2
R d9
R 00
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S e8
R fa
S 00
R fa
S f0
R fa
S f0
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S e9
R fa
R c2
R c8
R 82
S f3
R fa
S 64
R fa
S e7
R fa
S ea
R fa
S f3
R fa
S 64
R fa
S f4
R fa
S f5
R fa
S ff
R fa
R aa
S f5
S ff
R fa
R fa
R aa
R 00
S e7
R fa
S e7
R fa
S e7
R fa
S e9
R fa
R 73
R 03
R 0a
S ea
R fa
S ec
R fa
S ec
R fa
S ec
R fa
S e9
R fa
R 88
R 08
R 1d
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S e9
R fa
R c2
R c8
R 80
S f3
R fa
S 64
R fa
S f6
R fa
S ea
R fa
S e7
R fa
S e7
R fa
S e7
R fa
S e9
R fa
R 42
R 02
R 3c
S e6
R fa
S e6
R fa
S e6
R fa
S f3
R fa
S c8
R fa
S f3
R fa
S 14
R fa
S ea
R fa
S ec
R fa
S ec
R fa
S ec
R fa
S e9
R fa
R 88
R 08
R 1d
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S f3
R fa
S 64
R fa
S e7
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 14
R fa
S e9
R fa
R c2
R c4
R 00
S f0
R fa
S e7
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 02
R fa
S f3
R fa
S c8
R fa
S e9
R fa
R c2
R d9
R 00
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S e8
R fa
S 00
R fa
S f0
R fa
S f0
R fa
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 64
R fa
S e9
R fa
R c2
R c8
R 82
S f3
R fa
S 64
R fa
S e7
R fa
S ea
R fa
S f3
R fa
S 64
R fa
S f4
R fa
S f5
R fa
S f2
R fa
R 00
S ea
R fa
S ec
R fa
S ec
R fa
S ec
R fa
S e9
R fa
R 88
R 08
R 1d
S ec
R fa
S e8
R fa
S 01
R fa
S e7
R fa
S e8
R fa
S 01
R fa
S f3
R fa
S 28
R fa
S e9
R fa
R c2
R c5
R 69
S f3
R fa
S 3c
R fa
S f3
R fa
S c8
R fa
S ea
R fa
S f4
R fa

Re: New Alps protocol in the wild?

[Ben Gamari]

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

Re: New Alps protocol in the wild?

[dturvene]

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

Re: New Alps protocol in the wild?

[Ben Gamari]

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

Re: New Alps protocol in the wild?

[dturvene]

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

Re: New Alps protocol in the wild?

[Ben Gamari]

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

Re: New Alps protocol in the wild?

[dturvene]

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

Re: New Alps protocol in the wild?

[dturvene]

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