Re: New Alps protocol in the wild?

[dturvene <dturvene@dahetral.com>]

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
>