Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

[Posted September 24, 2014 by corbet]

Here's a post from Peter Hutterer on why the X.Org input stack is a mess and the new "libinput" stack is needed. "It looks like a big happy family at first, but then you see that synaptics won't talk to evdev because of the tapping incident a couple of years back, mouse and keyboard have no idea what forks and knives are for, wacom is the hippy GPL cousin that doesn't even live in the same state and no-one quite knows why elographics keeps getting invited. The X server tries to keep the peace by just generally getting in the way of everyone so no-one can argue for too long. You step back, shrug apologetically and say 'well, that's just how these things are, right?'"

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 24, 2014 14:55 UTC (Wed) by javispedro (guest, #83660) [Link] (4 responses)

Some Win8 devices nowadays (namely, the Surface Pros) have a single USB device that generates the HID reports for both the touchpad, keyboard, Wacom, and physical volume/power buttons. This configuration causes the Xorg input infrastructure to show its age.

You can map this "single" device node to the evdev driver, but then you lose most of the Wacom functionality, since the evdev driver will not create the stylus+eraser devices X11 software such as Gimp expects.

Or you can map the device to the xorg Wacom driver, but then you lose the keyboard and buttons functionality, since the Wacom driver doesn't know what to do with them.

In addition, the touchpad hardware can work in either "touchscreen" mode or "mouse emulation" mode. The hardware's "touchscreen mode" is useless because to use right click emulation and other niceties you want to use the -synaptics driver, which will then ignore both Wacom and keyboard events.

On the other hand, I'm sure libinput will be only 1% as customizable as the older suite of Xorg drivers was...

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 24, 2014 22:00 UTC (Wed) by whot (subscriber, #50317) [Link] (3 responses)

X was designed when there were only two kinds of devices, pointers and keyboards (we are talking about the 80s here after all). Much of the X protocol relies on that and it reflects on the implementation.

Wayland has a notion of "capabilities" rather than device types. libinput took that concept, so instead of a keyboard device libinput gives you a device that has the capability to send keys. And/or pointer events, touch events, etc. Which means that a lot of the problems from mixed devices don't even show up, and the others we can work around internally and present them in a well-defined manner to the caller.

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 26, 2014 14:05 UTC (Fri) by bentiss (guest, #89102) [Link] (2 responses)

And for the "Some Win8 devices nowadays (namely, the Surface Pros) have a single USB device that generates the HID reports for both the touchpad, keyboard, Wacom, and physical volume/power buttons.", the kernel has to split the various input sources in several input devices.

And actually, since the kernel v3.10, the pen and touchscreen are already split natively in hid-multitouch. Not to mention that the surface pros have separate HID devices for the touchpad and the buttons (volume/power) goes through a direct ACPI buttons interface which produces its own evdev device.

So libinput does only simple mapping and relies on the kernel to split input devices correctly.

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 30, 2014 17:34 UTC (Tue) by javispedro (guest, #83660) [Link] (1 responses)

It's not that simple to "split" devices, unless you're talking about a trivial split into "relative", "absolute", "button", etc. devices but that looks only useful only to workaround these Xorg driver limitations. The kernel has support for this but then you get even more absurd phenomena such as the eraser button going through the keyboard Xorg device. In fact it seems only one device in the kernel uses this "feature".

But you are completely wrong re the Surface Pro. The pen and touchscreen devices are already split in the hardware (the touchscreen is a separate device from the "conglomerate" USB device); the kernel's "split" feature is useless because of the above reasons. And the volume buttons do not come from ACPI, but via this "conglomerate" device (obviously the power button does come via ACPI too).

It seems from your comment that libinput is not going to improve the situation at all. :( Sounds weird, because I don't understand why devices need to be split at all.

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 30, 2014 18:03 UTC (Tue) by bentiss (guest, #89102) [Link]

I think you misread what I meant when I talked about splitting devices. My bad, I should have been clearer.

In the kernel, we have much more information than the userspace has. And yes, we can create one input device for each physical device (mouse, keyboard, touchpad, pen, touchscreen, etc...).

In the case of the Surface Pro 1 and 2, the panel has two chips connected through one hub, as you said, and yes, the plumbing of the kernel already creates one input device for the touch part, and one for the pen. There were never any intention to explode a device in meaningless events, like reporting the button of the pen through the keyboard or through its own input device. So in the Surface 1 and 2 cases, we do not touch anything in the kernel.

However, the Surface (Pro) 3 has a N-trig chip/sensor which does both touch and pen in one usb/hid device. Then, in this case, we split out the touch from the pen by creating two input devices so that the user space can treat the touch as a touch and the pen as a pen.

Believe it or not, the plan for libinput is to rely on what we learned from the past to provide a better input library that can be used by future compositors. And Peter saw a lot of crazyness to know how to avoid them.

BTW, by re-reading your first comment, I think your device simply lacks a good support in the kernel. If the OEM are crazy enough to send the keyboards and the pen events in the same HID device, this has to be split in the kernel so that the upper layers are not messed up with it.

No configurability

Posted Sep 25, 2014 6:37 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (7 responses)

Replacing middle button on Thinkpads with wheel emulation for the trackstick... breaks my workflow.
Such hardcoding is not reasonable - middle button is middle button.

No configurability

Posted Sep 25, 2014 23:19 UTC (Thu) by whot (subscriber, #50317) [Link] (6 responses)

and it still works as middle button so let's just stop the panic. wheel emulation doesn't kick in until after a timeout. and if you have a use-case that requires middle button hold-to-click or dragging, I'm all ears, just send me an email, or even better to wayland-devel.

No configurability

Posted Sep 26, 2014 1:30 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>middle button hold-to-click or dragging
I've been using it for window dragging.

So please, make the touchpad configuration available. It's not reasonable to hide it. Even such fascist OSes as Mac OS X allow to configure touchpad.

No configurability

Posted Sep 27, 2014 5:07 UTC (Sat) by flussence (guest, #85566) [Link]

>I've been using it for window dragging.

That, and I've been using it for the in-page scroll feature browsers have had for the past, oh, 15 years or so...

No configurability

Posted Sep 26, 2014 2:58 UTC (Fri) by zblaxell (subscriber, #26385) [Link] (3 responses)

Off the top of my head: Gimp image panning. It's not quite the same as scrolling from a touchpad or mouse wheel--I tend to use a mix of both when I'm editing photos.

But that's nothing. I remap my Macbook's touchpad to behave like a standard PC laptop, using some of the useless bottom-row keyboard keys as buttons, disabling multi-finger gestures to prevent accidental scrolling when something brushes across the twelve-square-inch area, and using the bottom and right half inches of the device for scrolling on two axes. I remap my netbook's tiny touchpad area to behave like a Mac touchpad because multi-finger gestures for scrolling make sense on a device that is smaller than my thumb, while bottom- and side- scroll areas do not. Both of these can be expressed as Synaptics configurations on any suitably capable hardware (with a little bit of X keyboard to get the middle and right buttons on the Mac) and there have been several quite usable and effective configuration tools for these devices when FDO isn't intentionally breaking them.

Neither touchpad is usable in its default configuration. The Mac can't reliably position clicks with middle or right buttons using the touchpad, and dragging is impossible. Both devices send large scroll events at random when they detect a stray finger brushing against them in the wrong place or time. To understand what this is like, connect a second keyboard to your computer and have someone press PageUp and PageDown rapidly and randomly, but only at the most inconvenient times for you.

libinput is a non-starter until it can configure a Synaptics device. They are everywhere, and hardware vendors make terrible choices when they configure them. There's no excuse for not being able to configure such a common device properly.

No configurability

Posted Sep 26, 2014 4:19 UTC (Fri) by whot (subscriber, #50317) [Link] (2 responses)

just to doublecheck: you're using the middle button under the trackstick (which iirc only exists on lenovos) to pan images in GIMP? because that's what we're talking about here, so I need to make sure.

No configurability

Posted Sep 26, 2014 4:47 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

Yes, that's a common use-case. I'm using it (when working on my Lenovo laptop) to move windows by clicking at any point on them.

No configurability

Posted Sep 26, 2014 15:21 UTC (Fri) by zblaxell (subscriber, #26385) [Link]

Absolutely. The dedicated hardware middle button is why I bought Lenovo.

Even left+right middle-click emulation isn't good enough for some work. I configured the non-Lenovos using their keyboards to emulate the missing button(s). I even bind a key to left-click with the keyboard on the Mac because clicking on the trackpad causes a small jog in the pointer position.

I also threw in a few other cases where inadequate configurability ruins the end-user hardware experience. Most of these are Synaptics devices, which seemed worth talking about because the OP really seems to have a hate on for those.

Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

Posted Sep 28, 2014 8:13 UTC (Sun) by tomgj (guest, #50537) [Link]

So, all this talk of the middle mouse button..

I take it it still works for traditional X pasting?