xf86-input-libinput 1.3 Brings Custom Pointer Acceleration Profile Support

[phoronix]

Phoronix: xf86-input-libinput 1.3 Brings Custom Pointer Acceleration Profile Support

Peter Hutterer, Red Hat's leading Linux input expert, today released xf86-input-libinput 1.3 as the newest version of this X.Org Server driver for making use of libinput in an X.Org Server world...

https://www.phoronix.com/news/xf86-input-libinput-1.3

[eagleoneraptor]

Out of context, but libinput is a perfect case that if organized well, you don't have to reimplement stuff in each Wayland compositor. Because of libinput each Wayland compositor has a consistent input behaviour without reinventing the wheel, even consistent in X.

[ehansin]

Out of context, but libinput is a perfect case that if organized well, you don't have to reimplement stuff in each Wayland compositor. Because of libinput each Wayland compositor has a consistent input behaviour without reinventing the wheel, even consistent in X.

I have been thinking, and I know a fair amount of this already exists, but the most shared libraries that exist that can be used across desktops / window managers, the more standardized things can become while still allowing parts of each to be unique. Might be low-level plumbing for things like sound or printing or whatever. And when someone comes up with some better plumbing for whatever functionality, that can then be swapped out.

[eagleoneraptor]

I have been thinking, and I know a fair amount of this already exists, but the most shared libraries that exist that can be used across desktops / window managers, the more standardized things can become while still allowing parts of each to be unique. Might be low-level plumbing for things like sound or printing or whatever. And when someone comes up with some better plumbing for whatever functionality, that can then be swapped out.

I would love to know more about the internals but at first sight you can know for sure that there are things that are totally agnostic to each environment and are managed similarly, and they are for sure useful for all of them: the implementation of each Wayland protocol, the multi monitor support (with differents refresh rates and the like), HDR, how you deal with each graphic pipeline down the line, how you deal with special vendor cases. But I'm not sure how many things of a compositor can be taken out in the form of a library of if everything is so tied together that the only way to do it is with a full featured framework (like wlroots), where each DE only implements the "shell".

[ehansin]

I would love to know more about the internals but at first sight you can know for sure that there are things that are totally agnostic to each environment and are managed similarly, and they are for sure useful for all of them: the implementation of each Wayland protocol, the multi monitor support (with differents refresh rates and the like), HDR, how you deal with each graphic pipeline down the line, how you deal with special vendor cases. But I'm not sure how many things of a compositor can be taken out in the form of a library of if everything is so tied together that the only way to do it is with a full featured framework (like wlroots), where each DE only implements the "shell".

I wasn't just thinking Wayland stuff, but all parts that make up a desktop. Like core libraries for printing where maybe the DE has their own admin tool on top to this/these. Same with sound, etc. I am sure a lot of this is already happening, but more of it maybe

[eagleoneraptor]

I wasn't just thinking Wayland stuff, but all parts that make up a desktop. Like core libraries for printing where maybe the DE has their own admin tool on top to this/these. Same with sound, etc. I am sure a lot of this is already happening, but more of it maybe

Ah, I see, sure, a lot of things that are being reused and using exactly the same stack (desktop portals, DBus, Pipewire, cups, etc), at least for the GNOME and KDE case since they tend to define the standards, some of those cases the only differing part is the GUI and that's fine, the vision pf UI/UX should be different, innovative and flexible.

[alexvoda]

Ah, I see, sure, a lot of things that are being reused and using exactly the same stack (desktop portals, DBus, Pipewire, cups, etc), at least for the GNOME and KDE case since they tend to define the standards, some of those cases the only differing part is the GUI and that's fine, the vision pf UI/UX should be different, innovative and flexible.

I believe FreeDesktop was created precisely in order to enable this kind of collaboration. It is unfortunate that some parties are less interested in participating.

[eagleoneraptor]

I believe FreeDesktop was created precisely in order to enable this kind of collaboration. It is unfortunate that some parties are less interested in participating.

What parties?

[Quackdoc]

Custom acceleration profiles are something i've been missing for a long time. I use them religiously for gaming, particularly FPS games. a nicely tunned mouse acceleration profile is IMO way better then no acceleration for gaming

[rogerx]

Custom acceleration profiles are something i've been missing for a long time. I use them religiously for gaming, particularly FPS games. a nicely tunned mouse acceleration profile is IMO way better then no acceleration for gaming

Well, I think mouse acceleration varies from task to task, such as anything 3D graphics (eg. CAD, games, ...) to 2D graphics such as Gimp and Internet browsers.

As for me, I simply use the Logitech G502 additional mouse buttons for increasing/decreasing acceleration.