Weston-Forked Libinput Is Moving Forward With Input

[phoronix]

Phoronix: Weston-Forked Libinput Is Moving Forward With Input

X.Org input expert Peter Hutterer is moving forward with his work on libinput, a fork of the Weston input handling code into its own library so that it's independent of the compositor...

http://www.phoronix.com/vr.php?view=MTU4NTI

[gens]

yay
this was one big thing i know is/was missing with wayland

[uid313]

They should have named it libwayland-input instead...

[giucam]

They should have named it libwayland-input instead...

Why? It has nothing to do with wayland.

[Ericg]

They should have named it libwayland-input instead...

If I remember correctly Wayland deals directly with Evdev and udev events (please correct me if Im wrong), there's no "XInput" or similar layer above it. So yes, this library probably has a Wayland-leaning focus, It should also work as a generic "Im low level but dont want to deal with evdev / udev myself personally for input"

[daniels]

it's a library to sit in between your display server (weston, xorg, mutter-wayland, etc) and your hardware. it's not tied to any particular window system, and also has zero impact on clients.

[Ericg]

it's a library to sit in between your display server (weston, xorg, mutter-wayland, etc) and your hardware. it's not tied to any particular window system, and also has zero impact on clients.

Thank you Daniel

[liam]

If I remember correctly Wayland deals directly with Evdev and udev events (please correct me if Im wrong), there's no "XInput" or similar layer above it. So yes, this library probably has a Wayland-leaning focus, It should also work as a generic "Im low level but dont want to deal with evdev / udev myself personally for input"

Libinput, which seems like it should be integrated with the common compositor library that was created recently, registers with udev and is event based thus I'd imagine it's using evdev directly.
Just read Daniel's post and I see why they didn't integrate the code.

[Ericg]

Libinput, which seems like it should be integrated with the common compositor library that was created recently, registers with udev and is event based thus I'd imagine it's using evdev directly.
Just read Daniel's post and I see why they didn't integrate the code.

just to clarify: it -was- integrated but it was now ripped out and made separate after it was field tested in Weston and they are comfortable with it