Thursday, January 29, 2015

Lenovos X1 Carbon 3rd touchpad woes

[Update 19/03/15]: TLDR: kernel patches queued for 4.0 do not require any userspace changes.

Lenovo released a new set of laptops for 2015 with a new (old) feature: the trackpoint device has the physical buttons back. Last year's experiment apparently didn't work out so well.

What do we do in Linux with the last generation's touchpads? The kernel marks them with INPUT_PROP_TOPBUTTONPAD based on the PNPID [1]. In the X.Org synaptics driver and libinput we take that property and emulate top software buttons based on it. That took us a while to get sorted and feed into the myriad of Linux distributions out there but at some point last year the delicate balance of nature was restored and the touchpad-related rage dropped to the usual background noise.

Slow-forward to 2015 and Lenovo introduces the new series. In the absence of unnecessary creativity they are called the X1 Carbon 3rd, T450, T550, X250, W550, L450, etc. Lenovo did away with the un(der)-appreciated top software buttons and re-introduced physical buttons for the trackpoint. Now, that's bound to make everyone happy again. However, as we learned from Agent Smith, happiness is not the default state of humans so Lenovo made sure the harvest is safe.

What we expected to happen was that the trackpoint device has BTN_LEFT, BTN_MIDDLE, BTN_RIGHT and the touchpad has BTN_LEFT and is marked with INPUT_PROP_BUTTONPAD (i.e. it is a Clickpad). That is the case on the x220 generation and the T440 generation. Though the latter doesn't actually have trackpoint buttons and we emulated them in software.

On the X1 Carbon 3rd, the trackpoint has BTN_LEFT, BTN_MIDDLE, BTN_RIGHT but they never send events. The touchpad has BTN_LEFT and BTN_0, BTN_1 and BTN_2 [2]. Clicking the left button on the trackpoint generates BTN_0 on the touchpad device, clicking the right button generates BTN_1 on the touchpad device. So in short, Lenovo has decided to wire the newly re-introduced trackpoint buttons to the touchpad, not the trackpoint. [3] The middle button is currently dead, which is a kernel bug. Meanwhile we think of it as security feature - never accidentally paste your password into your IRC session again!

What does this mean for us? Neither synaptics nor evdev nor libinput currently support this so we've been busy apidae and writing patches like crazy. [Update 19/03/15]: The patches queued in Dmitry's for-linus branch re-route the trackstick buttons in the kernel through the trackstick device. To userspace, the trackstick thus looks the same as in the past and no userspace patches are needed. I've reverted the synaptics patch already, the libinput patch will follow. The patch goes into the kernel and udev.... The two patches needed go into the kernel and udev, and libinput. No, the three patches needed go into the kernel, udev and libinput, and synaptics. The four patches, no, wait. Amongst the projects needing patches are the kernel, udev, libinput and synaptics. I'll try again:

With those put together, things pretty much work as they're supposed to. libinput handles middle button scrolling as well this way but synaptics won't, much for the same reason it didn't work in the previous generation: synaptics can't talk to evdev and vice versa. And given that synaptics is on life support or in pallative care, depending how you look at it, I recommend not holding your breath for a fix. Otherwise you may join it quickly.

Note that all the patches are fresh off the presses and there may be a few bits changing before they are done. If you absolutely can't live without the trackpoint's buttons you can work around it by disabling the synaptics kernel driver until the patches have trickled down to your distribution.

The tracking bug for all this is Bug 88609. Feel free to CC yourself on it. Bring popcorn.

Final note: I haven't seen logs from the T450, T550, ... devices yet yet so this is so far only confirmed on the X1 Carbon so far. Given the hardware is essentially identical I expect it to be true for the rest of the series though.

[1] We also apply quirks for the 2013 generation because the firmware was buggy - a problem Synaptics Inc. has since fixed (but currently gives us slight headaches).
[2] It is also marked with INPUT_PROP_TOPBUTTONPAD which is a bug. It uses a new PNPID but one that was in the range we previously believed was for pads without trackpoint buttons. That's an an easy thing to fix.
[3] The reason for that seems to be HW design: this way they can keep the same case/keyboard and just swap the touchpad bits.
[4] synaptics is old enough to support dedicated scroll buttons. Buttons that used to send BTN_0 and BTN_1 and are thus interpreted as scroll up/down event.


Unknown said...

As someone who's considering to get a 2015 X1, thank you for your hard work! (Not sure I would have noticed though, as I only use the touchpad and KDE's multitouch-to-mousebuttons emulation).

Josh Triplett said...

With the return of physical buttons, is it possible with such a system to disable movement on the touchpad, but still use the touchpad exclusively for scrolling? Is that a supportable configuration, and if so, what's the right way to achieve it?

Peter Hutterer said...

Josh: since synaptics 1.7.7 the physical buttons always work, regardless of the state of the touchpad. So you can disable the touchpad and still use the buttons.

The specific option you want though isn't supported, sorry. Interestingly enough synaptics has an option to disable scrolling but not movement, but not the other way round.

Josh Triplett said...

If I wanted to add such support (to either synaptics or something libinput-based), what would be the Right Way to go about doing so, to fit in with the overall architecture and have the best chance of acceptance?

Two possible use cases, either of which I'd be satisfied with: either disable movement but keep scrolling gestures, or disable movement and change the scrolling gestures to work even when only using one finger.

Peter Hutterer said...

Josh: open a bug or better to start discussing it on wayland-devel (libinput) or xorg-devel (synaptics).

Having said that, don't get your hopes up at them moment. Special use-cases like these are costly to maintain and there's usually a way around it. But that's what the discussion should show.

I wouldn't bother with synaptics tbh...

duschendestroyer said...

I can confirm that the same problem exists with the X250. I just hope that these patches make their way into arch linux quickly.

Tomasz Nazar said...

If you need any logs from t450s on Debian Jessie, I can provide. Just tell what you want..

Christophe-Marie said...

I have a T450. These 3 buttons are there. I did not do any configuration yet, and I can tell you what they do by default:

- left: scroll up
- middle: nothing
- right: scroll down

I can't get to have xev to detect the middle button, so I guess it is the kernel bug you are talking about.

Is there any patch coming up in the next version of the kernel? I am running 3.19.3-3, but I expect archlinux to ship 4.0 soonish.

I would like to remap these buttons such that they become a left click, a middle click, and a right click, do you think it will be possible?

Christophe-Marie said...

Disregard my question about 4.0, I read the linked Bug and got my answer.