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 confusion. > > > "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] 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 >