Is there something like xinput for Wayland? I tried switching to Wayland session in recent KDE Plasma 5.12.0, but lost the setting that emulated middle click with left + right clicks, that I was setting with xinput.
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.
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.
People keep saying this was "decided" for security, but usually with no sources cited. I wasn't able to find a firm decision and discussion/roadmap. Instead it seems more like it was viewed as "handling this in a secure way is hard, let's skip trying to figure it out". Which is pretty sad, since as far as I can tell users didn't really get much in the way of tangible benefits from Wayland aside from security (altho the KWin maintainer points to Wayland being easier to test automatically https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-fe...).
Ultimately I, along with other automation-minded folks, will be sticking with x11 until this is figured out. macOS also has a decent automation story, with tools like Hammerspoon, Automator, and so on.
I've got a fair bit of other notes on the topic which I can share with anyone interested - for example I saw "Some way to inject automated libinput events?" (https://bugs.freedesktop.org/show_bug.cgi?id=99800) where the person was actually trying to tune a gamepad.
Wow. Thanks for the detailed reply. I'll add that to my notes. I'm curious to see how this plays out with wlroots and how people will build on it to bring the something like variety of window manager X has to Wayland.
Using Xwayland for a significant number of things makes me curious about how much overhead it adds. The only article I found was from 2014 and it showed it adding significant overhead. Anyone know of any newer data?
> "trackball/input configuration" is too vague to make any promises about but input configuration is possible
This is my current config setup. As you can see I make multiple changes. I remap the buttons, set the pointer acceleration, set mousewheel emulation, etc.
mouse_id="Kensington Kensington Slimblade Trackball"
if xinput --query-state "$mouse_id" > /dev/null 2>&1 ; then
# We need to map names to prop numbers for the settings below
props=`xinput --list-props "$mouse_id"`
getid () {
echo "$props" | grep -i "$1" | grep -o "([0-9]\+)" | grep -o "[0-9]\+"
}
# below numbers come from 'xinput --list-props [mouse_id]'
# these property ids seem to be persistent between reboots
xinput --set-prop "$mouse_id" "$(getid profile)" 2
# NOTE need to look up these properties by name to get ids for settings
## mouse speed (change 'constant decel' first to change speed)
# fast movement acceleration velocity scaling
xinput --set-prop "$mouse_id" "$(getid accel\ velocity)" 1024
# slow movement decelleration scaling
xinput --set-prop "$mouse_id" "$(getid constant\ decel)" 6
xinput --set-prop "$mouse_id" "$(getid adaptive\ decel)" 10 # no effect?
## remap buttons (swap 2 and 8)
xinput --set-button-map "$mouse_id" 1 8 3 4 5 6 7 2
# orig: 2 8 new: 8 2
# 1 3 1 3
## mouse wheel emulation
xinput --set-prop "$mouse_id" $(getid emulation\ axes) 6 7 4 5
xinput --set-prop "$mouse_id" \
$(getid wheel\ emulation\ button) 8 # pre-remapping
xinput --set-prop "$mouse_id" $(getid "wheel emulation (") 1
xinput --set-prop "$mouse_id" $(getid emulation\ inertia) 15 #lower=faster
fi
The problem is there is no common desktop permissions framework on Linux.
On macOS a lot of these privileges (being able to inject and monitor input) are behind accessibility APIs and require the users express permission & password.
