[ 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@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
