Hi, this update caused quite serious issue on one of my computers.
System details:
Plasma 6.3.3,
X11
Nvidia + Intel GPU (prime, proprietary drivers)
Dual screen setup (laptops internal + DisplayPort; DP is wired to nvidia)
The issue
Issue occurs only if external display is connected and if it’s configured as a main screen (the checkbox in KDE display configuration).
Shortly after login (or after connecting the external display), the whole plasma framework becomes unresponsive. Whole plasma (including KDE-related apps, like dolphin) remain frozen until the external display is disconnected.
Solution
Temporal(!) solution is to switch display configuration and set internal screen as default one.
Well, seeing as Wayland is the new preferred choice for Plasma and the X11 port/functionality is only being maintained by volunteers, I’d recommend at least starting to think about it.
Because, to put it bluntly, the switch is inevitable.
Precisely the reason I finally bit the bullet at the end of last year.
I’d say that for the vast majority of users, the switch should be pretty much seamless. My own difficulties only came from the fact that I used a lot of (relatively obscure) X11 tricks such as mouse button remapping and have a lot of scripts which automate my workflow by moving the mouse pointer around the screen and clicking on buttons using things like xdotool, wmctrl, etc. I had to do a lot of research and subsequent work to get the equivalents working in Wayland, but it’s all settled down now.
Sure I’m thinking of it. What holds me back is that I was sure the Wayland is not ready yet for everyday usage. Seeing my coworkers, who use Wayland, suffering from issues with video and audio on calls (especially screen-sharing feature) simply put me back.
But if you say that Wayland is preferred now, then maybe I’ll give it a try this weekend. Thank you.
Wayland is generally ready for prime time, in my less than humble opinion. As previously mentioned, it’s the combination of Nvidia and Wayland that seems troublesome for some users.
I notice you’re using Nvidia graphics; and with multiple monitors;
Chances are that those friends you mentioned may also be using Nvidia. While the suggestion to use Wayland is indeed a fair one, Nvidia can often be the underlying reason for having a poor experience; especially the older chipsets.
Wayland on NVIDIA seems to have drastically improved in the last few months. My last try was around Oct. 2024, and back then, it was pretty much unusable/unstable.
Now, after issues with X11 more or less forced the transition, I’m actually quite impressed - Wayland runs pretty smoothly, aside from a handful of applications that seem to have trouble adjusting (e.g. Kodi just crashes, VirtualBox exhibits some weird warping/wobbling when displaying VMs).
[AMD Ryzen + NVIDIA RTX 2060 Super; KDE using Wayland]
It’s a mixed bag. I see reports of newer Nvidia graphics running just fine with Wayland (most, in any case) but many of the older graphics (which Nvidia is no longer focused on) are still causing grief for some.
There will come a time when bandaids are not enough.
That’s a shame. NVIDIA does not get nearly enough hate for their horrific Linux drivers. It always only kind of works, but in most cases just until the next major update, the next kernel revision, etc.
I’ve just about had it myself, this is my last NVIDIA card for sure. Their refusal to properly integrate the drivers into the kernel sources really hurts users on a daily basis.
@beermad, I would love to hear what equivalents you found to xdotool, wmctrl, etc. It also took me long times to perfect my commands in those apps … nice to hear it is possible
kdotool is one of the main replacements. For most operations on a window, you have to first identify its ID. A couple of useful methods: kdotool getactivewindow
returns the ID of whichever window is currently active. Or kdotool search [options] pattern
returns the IDs of windows matching various things such as the window title, its class, role, etc. kdotool windowactivate $ID
Brings that window up and focuses it. kdotool windowminimize $ID
minimises the window. kdotool windowclose $ID
closes a window (equivalent of wmctrl -c). kdotool windowsize $id width height
resizes a window.
ydotool provides some replacements for xdotool, though it’s somewhat more of a faff. For example, to simulate clicking a particular key, you first need to look up its code in /usr/include/linux/input-event-codes.h then simulate key-down with ydotool $keycode:1
But you have to remember to simulate releasing the key with: ydotool $keycode:0
otherwise things can get nasty.
ydotool can also move your mouse pointer. But unfortunately it’s nothing like as straightforward as it is with xdotool. To start with, you have to identify your mouse’s device number. I managed to find a snippet to do this:
# Stolen from https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
while IFS=: read dev desc ;do
case $desc in
*[Mm]ouse* ) mousedev=$dev;break;;
esac
done < <(evemu-describe <<<'' 2>&1)
I’m not confident that this won’t change from session to session, so I have a startup script which identifies it at login and leaves a file that can be sourced by a script to get the variable: echo "export MOUSEDEV=$mousedev" > $XDG_RUNTIME_DIR/mouse.device
It then gets even nastier, because using ydotool to set an absolute position only works for position 0,0. So you have to move the mouse there then do a relative move. And worse still, it won’t move accurately with mouse acceleration enabled. So my mousemove script has to read the current PointerAcceleration and PointerAccelerationProfile from the KDE configuration file, zero them using qdubs, move the pointer to 0,0, move it to the position I want with a relative move, then use qdbus to reset my mouse acceleration parameters.
# Workaround for moving mouse to correct position in Wayland
# Save and reset mouse acceleration
accel=`grep ^PointerAcceleration= ~/.config/kcminputrc | cut -d"=" -f2`
profile=`grep ^PointerAccelerationProfile= ~/.config/kcminputrc | cut -d"=" -f2`
qdbus org.kde.KWin /org/kde/KWin/InputDevice/event2 org.kde.KWin.InputDevice.pointerAcceleration 0
qdbus org.kde.KWin /org/kde/KWin/InputDevice/event2 org.kde.KWin.InputDevice.pointerAccelerationProfileAdaptive false
# This is ■■■■■■■ because ydotool doesn't ■■■■■■■ work right.
# I have to move it to the top corner first, then do
# a relative move
ydotool mousemove -a 0 0
# and relative move doesn't work, so we have to use this mess
# Stolen from https://unix.stackexchange.com/questions/422698/how-to-set-absolute-mouse-cursor-position-in-wayland-without-using-mouse
. $XDG_RUNTIME_DIR/mouse.device
evemu-event $MOUSEDEV --type EV_REL --code REL_X --value $1 2>&1 | tee-a /tmp/log
evemu-event $MOUSEDEV --type EV_REL --code REL_Y --value $2 --sync 2>&1|tee -a /tmp/log
qdbus org.kde.KWin /org/kde/KWin/InputDevice/event2 org.kde.KWin.InputDevice.pointerAcceleration $accel
if [ $profile -eq 2 ]
then
qdbus org.kde.KWin /org/kde/KWin/InputDevice/event2 org.kde.KWin.InputDevice.pointerAccelerationProfileAdaptive true
fi
I can’t help you there unfortunately. It’s not a function I’ve used. Have a look around the manpages and help screens for the tools I’ve mentioned - you may find something there.
Yes, thanks for sharing all that - glad to know there are alternatives. I guess xdotool has been around so long and the bumps have been smoothed out.
I also use autokey quite a bit … not sure if that woks with Wayland …
