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)
In reply to: Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers by whot
Parent article: Hutterer: libinput - a common input stack for Wayland compositors and X.Org drivers

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.