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.
You must log in or register to comment.
Can Wayland do
ssh -X?There seems to be https://wiki.gentoo.org/wiki/Waypipe which I’ve never used (unlike ssh -X which I once needed for a university course).
My personal bugbear is that there is no compositor-agnostic way to tell what workspace a window is located on. This means that taskbars cannot implement an “only show windows on the current workspace” setting, which frustrates me to no end. (Taskbars like the LXQt and XFCE panels still have the setting, but it does nothing.) There is not even any proposed protocol to support this, and acceptance and implementation would take years even if there were.
Integrated desktops like KDE probably roll their own custom implementation, but out in Labwc land I’m shit out of luck. (1 2 3 4)
Reading those issues… WTF? How many alternative implementation of basic functionalities are there? I think I remember reading back in the day that this will be the issue with Wayland, every DE will have to implement way more than with X. Now I understand what they were talking about.
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.
For instance multi window apps can’t tell the compositor where to put their windows
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.registering global hotkeys
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.
overscan correction
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.
Talon Voice and other accessibility tools like cursorless. I am destroying my hands because I can’t do handless input on Wayland.
Support for stylus / pen writing on screen.
Just looking at these comments, and the fact that wayland still isn’t as good as x11 after all these years (10, 15?) And all this budget shows that wayland is architectually wrong and will never be actually good.
Any software engineer will understand this. If your project is still in basically beta after more than a decade and that much budget, and it’s only selling point is that “but it’s slightly better than the decades old legacy system”, that project has been architectually wrong, and also definitely has awful management, and you call it failed.
Have you ever considered a career in set theory?
down voted for telling the truth. I use Wayland on my laptop and it works fine, but x11 is honestly still the defacto window system
I have to use x11 on my desktop (yes Nvidia) and it’s a nightmare. I try it every now and then though
Automated window positioning through tools like wmctrl and xdotool. There are replacements on Wayland but they’re either missing features or are tied to a specific window manager.
I use Xfce, and I like writing bash scripts that can work anywhere.
that can work anywhere
prob more people using KDE now than X11 ;)
Universal stuff for those (under wayland) compositor-specific functionalities kinda became impossible when wayland became standard.
In some cases there’s tools that support kwin, mutter, and wlroots, which is now as close to universal as you can probably get for things without standardized wayland api.
- Run Birdtray
- Not obnoxiously throw up W whenever it can’t find an icon for a program during alt tabbing
- Not need extra extra handholding to run games properly without diagonal tears
Birdtray gave up on me when I last upgraded the system, so I switched to Betterbird. Even though it feels like buggier Thunderbird, they at least have somewhat fuctional tray icon.
I blame Mozilla for not supporting Linux for so long.
I blame Mozilla for not supporting Linux for so long.
what do you mean by this?
Legit the generic W icon is fucking terrible
does it need to be replaced by the WU TANG?
Worse than the generic X11 one though?
systray-x works very well as an alternative on Wayland!
For me it’s Steam Remote Play. I can’t say Wayland is unable to do it, but it’s always been so problematic I switch back to x11.
Highly recommend Moonlight/Sunshine as an alternative. It’s a bit janky sometimes but in general vastly more reliable than anything else I’ve tried especially on Linux or into Linux.
I’ve tried them in the past, but my client device was a Chromecast w/ Google TV, which I suspect contributed to my performance issues. I’m currently using an Onn 4k pro connected via Ethernet. Might be time to give Moonlight/Sunshine another go.
I never cosidered if that was a problem i had last year when demoing remoteplay onto an apple tv.
Does gamescope run on Wayland? I’d have thought it would be great for this
Yes, gamescope is specifically built for Wayland.
I had never thought to check if Wayland was the issue there.
So, just discovering the joys of virtual monitors available in the kernel now. NAS now has and gives me sunshine. Bazzite lets you put your own monitors’ (ujust setup-sunshine - Configure Virtual Monitor) edid into initramfs so sunshine (and KDE remote access if you want laggy but cut and paste enabled) work without a monitor connection (or dongle), very cool. Just thought I should spread the news and this is vaguely associated.
Not really relevant to the X11 question, except that it provides a (superior) workaround for some issues…
To the actual question, xtool for automating UI stuff hasn’t been completely replicated, but given it’s an insecure horrible solution I’m OK. Also running a program through a remote connection on a beefier machine was useful at times, is there an equivalent other than remote access?
Is there an equivalent other than remote access?
Yes, there is
waypipe. Very close analog tossh -X, arguably better. Even lets me access my local clipboard inwl-copy/wl-pastecommands on the remote.
It’s not part of ssh though, so needs to be installed on server and client.I found waypipe to be way more responsive than X11, and just … better somehow. More integrated into the other programs.
When using it, take care that pam is enabled in sshd. Else it won’t initialize the proper xdg environment which wayland stuff doesn’t like.
Thanks, great that that’s there.
input-remapper-gtkis a decidedly non-obvious way of rebinding mouse buttons.Of course,
xmodmapis also a decidedly non-obvious way …Run the old login credentials stealers
There are a few things that don’t work very well, mostly to do with multi window apps and how some older apps need to run through XWayland (which 99% of the time it works brilliantly! There are a couple weird issues, but most of those are easily fixable through some command argument before opening an app)
I an also running EndeavourOS (which is awesome!) with Niri + Noctalia (which also uses Wayland), and I have no issues :D
Eyy, fellow EndeavorOS enjoyer! It’s been super solid since I installed it in like April of last year.
AFAIK, there is currently no real equivalent for xrandr on any Wayland compositor.
Normally, you override the EDID rather than specifying modelines manually. Sway also has some limited custom resolution support, but it’s just resolution and refresh rate, and not precise timings. Apparently the DRM backend supports modelines
but that’s not really Wayland by my understanding, more like Steam’s gamescope mode.. Actually, the DRM backend is the default backend, so it should work. The other backends are used when sway is run inside another compositor.I’ve also noticed that Grsync’s password prompt is broken on Wayland.
Forcing XWayland may help here. Otherwise, I assume the application is run as root which generally causes some issues with Wayland but potentially can be made to work.
