[Raring][PULL] Cypress PS/2 Trackpad driver
Seth Forshee
seth.forshee at canonical.com
Thu Jan 17 20:38:53 UTC 2013
On Thu, Jan 17, 2013 at 11:04:22AM -0800, Kamal Mostafa wrote:
> The Cypress PS/2 Trackpad driver (which we're already shipping in
> Precise and Quantal, but not Raring) has been committed to the Input
> subsystem maintainer's master branch[0] pending merge into mainline
> Linux 3.9.
>
> Please consider this pull for Raring
> http://kernel.ubuntu.com/git?p=kamal/ubuntu-raring.git;a=shortlog;h=refs/heads/cypress-for-raring
> ... which includes the Cypress driver cherry-picked from the Input
> subsystem maintainer's repo, plus my "simulated multitouch" Cypress
> driver enhancement (denied by upstream, but required for Unity
> multitouch functionality; is included in our P and Q version).
I'm not really so keen on this simulated multitouch patch.
First, I think you overstate the case for the simulated multitouch
functionality. Without that patch the driver still has semi-mt support,
which should be adequate to support most two-finger gestures: drag,
pinch, spread, and two-finger clicks at minimum. It looks like there's
enough information coming out of the driver to support 3, 4, and 5
finger clicks as well. My understanding is that our userspace doesn't
handle those events the same as with full mt devices, but I don't see
that as being a driver problem.
As for gestures involving 3+ fingers, the code just generates fake touch
points offset horizontally from the first one. That means every gesture
looks like a drag.
In fact, with knowing the number of contacts and the bounding box I'd
think that userspace should even be able to support a 3+ finger drag
gesture. Probably better than the simulated multitouch even, because if
the bounding box isn't staying approximately the same size the gesture
likely isn't a drag.
What's wrong with limiting it to semi-mt, in line with the actual
capabilities of the hardware?
One more comment, regarding the implementation. The patch lacks
protection for report_data->contact_cnt > CTYP_MAX_MT_SLOTS whereas the
rest of the driver seems to protect against it. I'm assuming that
because you've increased that max number of slots from 2 to 5 there's no
longer a concern of having more contacts than slots? Because if that
happens you're going to overrun report_data->contacts.
Seth
More information about the kernel-team
mailing list