Comment 336 for bug 606238

Kevin -

Responses inline

On 02/18/2013 05:07 PM, Kevin Cernekee wrote:
> 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.
Good to know; I wondered how the roll-up works.
> 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.
Great! I dump a lot of email lists, including linux-input, on my server
and only periodically check them. I just saw your three-part
submission. The code looks good. I'll post a new comment on the 606238
bug thread about my understanding of your progress - just to avoid
> "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.
Good to know but I'm unclear how to proceed. Back when, I put in a
sysfs debug interface that a user could run to capture the physical
coordinates of the edges in order to tune the X edge properties. I
could take your patches, add the debug and release a new dkms.
> "Update ./Documentation/input/alps.txt with details on the new variants."
> That's a great idea, and it's something I've been neglecting.
I'll update alps.txt tonight and submit to linux-input
> 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.
I agree there are a lot of similarities but some differences as well.
For example, V3 uses byte 4 for x/y coordinates and byte 3 for buttons;
V4 uses byte 3 for x/y coordinates and byte 4 for buttons. This could
take a little bit of time to refactor. I'm backed up on several other
projects so I need to move on.
> [1];a=shortlog;h=refs/heads/next
> [2]