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.
Since when should the compositor/window-manager handle keyboard layouts? At the very least, there should be a configurable library that can be used.
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.
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...
Throw away the old ugly code, bring back the old ugly bugs...
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...).
I found a RFC on a mailing list: [RFC] Interface for injection of input events (https://lists.freedesktop.org/archives/wayland-devel/2017-Ma...) where the xdotools maintainer chimed in with some thoughts. But it seems to have died quick.
I then scoured the Wayland freedesktop bugs (https://bugs.freedesktop.org/describecomponents.cgi?product=...) and one of the closest things I could find to a discussion of related issues was an open bug "Add an API for taking screenshots and recording screencasts" (https://bugs.freedesktop.org/show_bug.cgi?id=98894) which has to deal with similar security challenges.
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.
Also see https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_... where people are saying that Wayland is further fracturing the Linux desktop world.
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.
Oh yes there is, it's called polkit and it's quite nifty !
openbox - window management
xinput - trackball/input configuration, disable touchpad
xbindkeys
setxkbmap - control/cap-lock manipulation
redshift
Xresources/xrdb - urxvt & general X settings
xdotool - script-able window movement
xclip/sselp - script-able copy-n-paste
zenity - scripting gui things
xset - dpms, screen blank, keyboard auto-repeat, mouse movement rate
conky - system info
dunst - notifications
unclutter - no pointer
xsslock/xtrlock - screenlock
xrandr - display config
urxvt - terminal/shell access
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?
Though currently TW3 suffers from low performance regression in general, so it won't be very conclusive.
Also, I suspect some of it can be compositor specific.
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