Hacker News Reader

A while back I looked into Wayland and what was missing that I would need to replicate my current setup. Here's the list I came up with...

    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

Most of these had no Wayland equivalents that I could find. I have no plans on switching anytime soon.

Much of this doesn't have a 1:1 equivalent tool, but is workable anyway. This comment got really long so I moved it into a gist: https://gist.github.com/SirCmpwn/594040cb476f93c503715d4635b...

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?

I don't think it should add a lot of overhead. Performance wise it shouldn't be any worse than regular X.

The article I mentioned in case you were curious.

https://www.phoronix.com/vr.php?view=20956

Thanks. I should run some Witcher 3 in Wine benchmarks with XWayland.

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.

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

> The problem is there is no common desktop permissions framework on Linux.

Oh yes there is, it's called polkit and it's quite nifty !

Yeah, combining security and automation is something that Wayland developers should solve in a serious way. It seems it's far from ready.