The biggest thing I can think of is that X11 is more flexible when it comes to specifying custom resolutions; which some people use to output 240p on CRT TVs for emulation. AFAIK, there is currently no real equivalent for xrandr on any Wayland compositor.
I’ve also noticed that Grsync’s password prompt is broken on Wayland. Thankfully, it has a feature that lets you preview the command it’s about to run, so that you can copy and paste it into a terminal.
Being a KDE user on EndeavourOS, I use Wayland everyday. I switched over a few years ago for Waydroid, but now X11 isn’t even an option for me with the current release of KDE.
In general, it’s things that Wayland chose not to do so as to have a better security model.
For instance multi window apps can’t tell the compositor where to put their windows such as snapping a window to another or following a window. Apps can’t read other windows. It’s a good thing for security but it breaks some older tools and workflows.
There’s others like multiple mouse cursors, registering global hotkeys, overscan correction etc but many of these things are being addressed and new standards are being drafted, it just takes time.
I moved to Wayland very early on and, honestly, I’ve not had any problems but I don’t have a complicated or special setup.
They can have positions lf existing windows saved and restored (still rolling out), and I think can ask for some details of initial placement outside of that too.
Of course still very limited and not handling the specific cases you mentioned.
Setting up hotkeys is possible, just in a very different way. You have to have the desktop environment forward it, and for now specifics differ from de to de. Generally they can all bind actions though. A safe minimum-viable way should be to add shortcuttable actions to the desktop file I think, though the qt shortcut stuff should also generally work I think.
kwin at least has had that for a while
Personally for me I used to have a script invoked by tilting the sceoll wheel that’d send a shortcut (e.g. ctrl+page-up/down) to the window under the cursor without focussing it, letting me change tabs of unfocussed windows.
I think I did that by quickly changing input focus, sending it, then changing it back, with xdotool etc…
On wayland I’ve tried implementing that via kwin scripting a few times, but found it so hard to debug and to work with in comparison I never managed to recreate that simple tool.
Having universal posix-like tools to affect the window manager and user input from console is definitely something I miss occasionally.
Largely this is just a lack of wayland tools I am sure. And I must admit it’s been a while since I last tried.
No global hotkeys is a dealbreaker for me, though.
Once you get used to using custom global hotkeys as part of your workflow, you can never go back.
It’s not about creating global hotkeys, it’s about registering them from a running program. There is nothing preventing you from creating a compositor-level keybinding, but an app cannot do that unless it figures out what compositor you are running and then handles the configuration for each and every compositor in existence.
Ah, okay then. Might be worth a try.
I wouldn’t worry about supporting every compositor in existence. Ideally, the Wayland spec would be unified, but it’s not.
I feel like if someone created a compositor with an extension for that feature, it’d eventually become popular enough that people would start implementing that extension in other compositors.
I wouldn’t want that. I’m fairly content with the fact that no random apps can grab my keystrokes unless that specific app is focused. From what I heard, for most people the only global keybind they want is muting their microphone. You can implement that yourself with absolutely no trouble, it will usually be the first example in the global keybinds configuration docs for pretty much any compositor. People who don’t want to deal with writing configs can use KDE where you have a GUI to configure the same thing.
It would be nice if end users had more choice in the matter. It’d be cool if someone made a Wayland compositor that allowed some of these features as an opt-in thing.
Users do have choice, X11 still exists, there’s lots of distros to choose from, but Wayland is the culmination of 40 years of learnings from the X11 project.
Linux hosts with desktop managers/window managers were loved by security testers and threat actors for how darn easy it was to get spyware running - logging all keystrokes, recording the whole screen, etc. X11 gave all apps the keys to the kingdom regardless of security policy.
Wayland is vastly more secure. Sure, there’s work to be done to build out a few edge cases - they’re known and have been in discussion for years at this point - it just takes time.
X11 had 40 years, Wayland had only had 18. With most mainstream distros switching display server, we should have the remaining sticking points ironed out in the next couple of years.
wayland dwms can and do absolutely implement that. For example kwin has a setting to let programs access keyboard input in the X11 way for the old method of global shortcuts. And to disable the framebuffer for fullscreen games.
If you wanted, you could probably write a wayland compositor that has all the X11 apis that old management tools use. Wayland is just an api at the end of the day.