Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm afraid not. Some configuration via libinput is possible, but they have been nerfing a lot of features like that. In the future I intend to close some of this gap at the compositor level, but that's not prioritized right now.


One of the most annoying input-related things that happened to my desktop (Arch) in the last year is when evdev got replaced with libinput by default as the X11 input module. Easy enough to revert, but quite frustrating trying to figure out why mouse acceleration suddenly feels acutely horrible.

All the tweakable options were different (and fewer) in xinput, and I was not able to recreate an acceleration curve that felt comfortable.

I realize it's an old refrain, but its quite frustrating having old, featureful software replaced with new, more limited/broken versions.


I fully agree. However, it can go the other way, too: my ThinkPad trackpad (with virtual buttons for the trackpoint) FINALLY started working properly with libinput, with zero configuration, after weeks of tweaking evdev options without success. YMMV...

It did break two-finger-drag though :(

On the general topic of removing functionality: I get where they're coming from. I had a look at the old synaptics evdev code, and it really complicated with tons of long-forgotten special cases and obscure settings. I see why they're actively getting rid of those, the libinput code is much nicer to look at (and, presumably, maintain). I just wish they weren't that aggressive about it...


It's just as likely that the removal of all those forgotten special cases is exactly what's ruining the experience for those complaining about the switch.

Throw away the old ugly code, bring back the old ugly bugs...


Yeah, the thing about "really complicated with tons of long-forgotten special cases and obscure settings" is that people were using those settings, and those special cases were fixing bugs and allowing odd uses. Your rewrite is simple and elegant... until you fix all the bugs and make it feature-complete, by which point you will accumulate your own pile of ugly hacks. Then the next generation comes along and says, "Why all the hacks? We should rewrite this. We will surely not have such odd-looking code!" Rinse, repeat.


Yeah, but there are also often a lot of things that just genuinely don't make sense anymore. Xterm is packed with support for an insane number of old tty devices that no one needs. There are plenty of terminal emulators that successfully skip all that and no one ever complains.

I don't know of a magic formula for being able to tell the difference, so it's hard thing to talk about in the abstract.


> devices that no one needs

Maybe it's this? Nobody would care if you rolled out X11.1 that was perfectly compatible with everything in use and dropping stuff that nobody will miss. We care because Wayland killed features that we are actively using.


That's a pity. I'll check if KWin has any way to configure libinput beyond very limited KDE system settings.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: