Tuesday, March 25, 2014

CyPS/2 Cypress Trackpad and firmware-based button emulation

For a longer story of this issue, please read Adam Williamson's post. The below is the gist of it, mostly for archival purposes.

The Dell XPS13 (not the current Haswell generation, the ones before) ships with a touchpad that identifies as "CyPS/2 Cypress Trackpad". This touchpad is, by the looks of it, a ClickPad and identifies itself as such by announcing the INPUT_PROP_BUTTONPAD evdev property. In the X.Org synaptics driver we enable a couple of features for those touchpads, the most visible of which is the software-emulated button areas. If you have your finger on the bottom left and click, it's a left click, on the bottom right it's a right click. The size and location of these areas are configurable in the driver but also trigger a couple of other behaviours, such as extra filters to avoid erroneous pointer movements.

The Cypress touchpad is different: it does the button emulation in firmware. A normal clickpad will give you a finger position and a BTN_LEFT event on click. The Cypress touchpads will simply send a BTN_LEFT or BTN_RIGHT event depending where the finger is located, but no finger position. Only once you move beyond some threshold will the touchpad send a finger position. This caused a number of issues when using the touchpad.

Fixing this is relatively simple: we merely need to tell the Cypress that it isn't a clickpad and hope that doesn't cause it some existential crisis. The proper way to do this is this kernel patch here by Hans de Goede. Until that is in your kernel, you can override it with a xorg.conf snippet:

Section "InputClass"+Section "InputClass"
        Identifier "Disable clickpad for CyPS/2 Cypress Trackpad"
        MatchProduct "CyPS/2 Cypress Trackpad"
        MatchDriver "synaptics"
        Option "ClickPad" "off"
EndSection
This snippet is safe to ship as a distribution-wide quirk.

3 comments:

Flay said...

How easy do you think it is, or is it even possible to implement absolute position on these pads then route the input to a specific process?

Ever since I've tried absolutely amazing OSX touchpad handwriting, I've been looking around. Seems the state quo is pretty bad, and it's a good time to start a hobby project.

Peter Hutterer said...

relatively simple from inside the touchpad driver and we had that feature a while ago. Got thrown out for lack of users and because the driver is unwieldy and hard to maintain. And there was no reasonable use-case for it at the time.

The handwriting thing would actually be really swish but it relies on much more than just the touchpad driver - you'll need all the other stack in place too

Flay said...

I think we already have pretty good handwriting software, it's just a matter of making the input go there. I'll see what I can do. Thanks for the insight Peter.