WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x  (Read 6917 times)

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
[64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« on: March 08, 2018, 04:38:10 PM »
Can you please update to libinput 1.10.x and add xf86-input-libinput to the repo?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #1 on: March 09, 2018, 12:01:31 AM »
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?

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #2 on: March 09, 2018, 03:21:39 AM »
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?

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #3 on: March 09, 2018, 04:15:15 AM »
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.

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #4 on: March 09, 2018, 03:53:04 PM »
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:

Quote
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.

 ;)

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #5 on: March 11, 2018, 03:12:56 PM »
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:

« Last Edit: March 11, 2018, 03:17:24 PM by pq5190362 »

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #6 on: March 11, 2018, 03:55:53 PM »
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

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #7 on: March 11, 2018, 04:21:57 PM »
Another presentation that explains why libinput is the future:

https://youtu.be/vxhdba4RS8s

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #8 on: March 12, 2018, 02:16:51 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #9 on: March 12, 2018, 01:17:17 PM »
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.
« Last Edit: March 12, 2018, 01:19:18 PM by pq5190362 »

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #10 on: March 12, 2018, 10:37:10 PM »
So, as mentioned previously, could you compile and test xf86-input-libinput locally and report back?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #11 on: March 13, 2018, 04:26:27 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #12 on: March 20, 2018, 04:57:58 AM »
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

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14516
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #13 on: March 20, 2018, 05:58:52 AM »
So, as mentioned previously, could you compile and test xf86-input-libinput locally and report back?

Offline pq5190362

  • Sr. Member
  • ****
  • Posts: 286
Re: [64-bit] libinput 1.10.x + xf86-input-libinput 0.26.x
« Reply #14 on: July 30, 2018, 03:35:14 AM »
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.