[64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x

[pq5190362]

Can you please update to libinput 1.10.x and add xf86-input-libinput to the repo?

[Juanito]

libinput (and libwacom) posted

There is a potential issue in that libinput uses the udev hwdb, which is not present in the tinycore version of udev.

Could you compile and test xf86-input-libinput locally?

[pq5190362]

Thanks a lot.

There is a potential issue in that libinput uses the udev hwdb, which is not present in the tinycore version of udev.

I remember you said:

weston will run in a window under X without Xwayland and the weston terminal accepts keyboard and mouse input so perhaps the hwdb is not so vital after all.

So it should work without udev hwdb?

Why is it not included in the Tiny Core Linux version of udev by the way?

[Juanito]

I was wondering whether xf86-input-libinput would work without the udev hwdb, not libinput.

Tinycore uses udev-174, which does not contain hwdb functionality - not long after udev-174, udev became part of systemd and needs to be extracted from their packages.

So far, 99% of tinycore extensions work without the hwdb and those that look for it are usually part of gnome.

[pq5190362]

I was wondering whether xf86-input-libinput would work without the udev hwdb, not libinput.

Why wouldn't it? Here's the official description of xf86-input-libinput:

https://github.com/freedesktop/xorg-xf86-input-libinput
This is an X driver based on libinput. It is a thin wrapper around libinput, so while it does provide all features that libinput supports it does little beyond.
https://www.freedesktop.org/wiki/Software/libinput/
The X.Org libinput driver is a thin wrapper around libinput and allows for libinput to be used for input devices in X.

 

[pq5190362]

Now we know why udev hwdb is needed (see below).

So, can you please add udev hwdb to Tiny Core Linux and post xf86-input-libinput to the repo?

The presentation below clearly shows that libinput is the way forward for the Linux input stack and is actually already the default for almost all major distributions.

Full talk:
https://youtu.be/uIEoFKhzxI8

PDF slides:
https://archive.fosdem.org/2015/schedule/event/libinput/attachments/slides/591/export/events/attachments/libinput/slides/591/libinput_xorg.pdf

Slide that explains what udev hwdb is used for:

[pq5190362]

And another presentation with even more reasons on why udev hwdb is used and why it is a hard dependency:

Full talk:
https://youtu.be/yHVyyJMo2lw

PDF slides:
https://www.x.org/wiki/Events/XDC2015/Program/hutterer_libinput.html

[pq5190362]

Another presentation that explains why libinput is the future:

https://youtu.be/vxhdba4RS8s

[curaga]

It does not particularly matter to us what is the default of others. We choose what is best for Core. Udev hwdb, in version 234, was about 6 mb. That is a cost hardly worth slightly more tunable touchpad settings, when most users do not even use the full capabilities of the synaptics driver.

Further, there is the matter that you previously admitted to wasting our time with the Wayland-related requests. It does not make me consider your requests for other things highly either, I'm leaning to think you would not use libinput, but are rather demanding it for similar reasons. If you want to "push technology", by all means do so with your own time and resources.

[pq5190362]

It was not so much about udev hwdb being a must. It was just about presenting the reasons it's being used for by libinput.

Also, libinput is not just about "slightly more tunable touchpad settings". It's basically the successor of evdev/synaptics/wacom and so on. As per the presentations mentioned above, those older drivers are basically unmaintainable, because they have such a messy code, which is why they are no longer being actively developed. libinput is the successor, i.e. it gets all the improvements, fixes and features, whereas the older ones do not. The presentations also mention real-world advantages that libinput has over the older drivers (such as for example being able to have a context between various classes of input devices, which is not possible with the older drivers, since they are separated from each other).

But you might be right that udev hwdb is not so essential after all, if all it really does is providing a database for devices which allow libinput to automatically adjust it's settings for specific devices.

When the same can be achieved by manually adjusting the libinput settings (via xinput), then it might be worth to go without udev hwdb and save those 6 megabytes.

That being said: It would be nice if you could add xf86-input-libinput to the repo (without udev hwdb) for the reasons mentioned above.

[Juanito]

So, as mentioned previously, could you compile and test xf86-input-libinput locally and report back?

[curaga]

Yes, I should have mentioned multiseat and multiple mice with different dpi, etc. Those are definite advantages, but not situations Core is commonly used in.

[pq5190362]

xf86-input-libinput 0.27.x has been released now, see:

https://www.phoronix.com/scan.php?page=news_item&px=xf86-input-libinput-0.27

[Juanito]

So, as mentioned previously, could you compile and test xf86-input-libinput locally and report back?

[pq5190362]

I was wondering whether xf86-input-libinput would work without the udev hwdb

https://www.phoronix.com/scan.php?page=news_item&px=Libinput-1.12-RC1

[...] libinput 1.12 is replacing its udev hwdb hardware database handling in favor of its own quirks system. This new quirk handling system is based on INI files and should be easier to maintain for problematic hardware.