Ubuntu
linux package

Bug #606238
Comment #334

Comment 334 for bug 606238

Revision history for this message

Kevin Cernekee (cernekee) wrote on 2013-02-18: Re: synaptic touchpad not recognized on dell latitude e6510 and others

#334

Just so we're on the same page - the "input-next" tree [1] (input.git, branch "next") is Dmitry's staging area for proposed input subsystem changes to send to Linus for the next merge window - currently targeting Linux 3.9. My patches 01-13 are in there now. This includes the code refactoring + Rushmore support, but no Dolphin support.

This past weekend I submitted three more patches [2] to be applied on top of input-next:

1) Remove unused argument to alps_enter_command_mode() - trivial cleanup

2) Dolphin V1 support, credited to Dave/florin. This is believed to be in working order, and ready to merge.

3) Dolphin V2 support, consisting of my new init + detection sequence. This was marked as WIP because the pressure readings at the edge of the touchpad are still "off." I am hoping somebody with access to this hardware can help figure out why. Maybe switching to the V2-native report format (and writing a new decoder for it) would help, since that is what the ALPS drivers seem to prefer.

"It doesn't make sense to me for ALPS to create different touchpad layout using the same signature; more likely is the laptop exposes an area of the touchpad based on the available real estate."

It appears that the driver can query the Dolphin V2 touchpads for their specs, and adjust the operating parameters accordingly.

Unfortunately I don't know much about how this works, or what range of values we can expect to see in the wild.

As for Rushmore, I can confirm that the touchpad dimensions and trackstick/buttons differ between Dell E6230/E6430, even though the IDs are the same. I haven't actually taken the laptops apart to see how they contrast physically. Doing so might shed light on how ALPS manages product variants.

"Update ./Documentation/input/alps.txt with details on the new variants."

That's a great idea, and it's something I've been neglecting.

One other thing that might be worthwhile is to see how much (if any) of the refactored V3 code can be used for the V4 touchpads. There are many similarities between the two protocols.

[1] http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=shortlog;h=refs/heads/next
[2] http://www.spinics.net/lists/linux-input/msg24857.html

Just so we're on the same page - the "input-next" tree [1] (input.git, branch "next") is Dmitry's staging area for proposed input subsystem changes to send to Linus for the next merge window - currently targeting Linux 3.9.  My patches 01-13 are in there now.  This includes the code refactoring + Rushmore support, but no Dolphin support.

This past weekend I submitted three more patches [2] to be applied on top of input-next:

1) Remove unused argument to alps_enter_command_mode() - trivial cleanup

2) Dolphin V1 support, credited to Dave/florin.  This is believed to be in working order, and ready to merge.

3) Dolphin V2 support, consisting of my new init + detection sequence.  This was marked as WIP because the pressure readings at the edge of the touchpad are still "off."  I am hoping somebody with access to this hardware can help figure out why.  Maybe switching to the V2-native report format (and writing a new decoder for it) would help, since that is what the ALPS drivers seem to prefer.