I can find Wayland equivalents for my compositor for all of these tools:
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
https://github.com/swaywm/sway/wiki/i3-Migration-Guide#commo...
ydotool is listed there as an equivalent of xdotool, but ydotool has only a tiny fraction of the features of xdotool.
And it's unlikely that it'll get much better any time soon, as its README says:
"Since Jun, 2019, I have little time to maintain this project"
wtype is listed as another equivalent to xdotool, but it has even less features than ydotool.
If the rest of the X equivalents on that list are as feature poor as these, I don't hold out much hope for Wayland in the near future.
You're here complaining that a maintainer isn't around to add features in a thread that's literally a major maintainer of X server telling you he's not going to work to maintain the project anymore.
---
Here's my take on your position - I absolutely agree that if you have processes and tooling in place that you currently depend on, and can't replace, you should stick with X.
That said - As a way to manage input and output on my system (MY system, with my preferences and my requirements) I've found Wayland to be a delightfully better experience than X.
So to come back at your list of requirements, mine looks like
- Multimonitor support, including mixed scaling ratios
- Touchpad input with gestures, approximately in line with the experience on OSX
- A sane "default" that does not constantly require that I manually edit settings or xconf files on EVERY system I touch
- No screen tearing or flickering. Seriously - NO!
---
The difference between the two lists, is that I believe Wayland can eventually replace the tools you need. I no longer have any faith that X will be able to solve my requirements. Wayland does.
I... think you already understand why this is a disingenuous argument, but I'll explain anyway:
The difference is, for most folks, X works, right now, today, while its maintainership is in question. For example, of the four items you listed, none of them particularly matter to me.
ydotool, as an example, doesn't work and it's not maintained.
Does that make sense?
> I believe Wayland can eventually replace the tools you need
Alright, well, ten years from now we should revisit this conversation!
Unfortunately, at this point, the Wayland ecosystem is looking a bit like Zeno's Paradox...
It also takes a hell of a lot more configuration to reach that state.
It's also not maintained.
So no disrespect, but it really sounds like your argument has boiled down to "I won't acknowledge issues unless they personally impact me and my daily workflow".
Now - I'm fine with that when you're making an argument for the machine you should use personally (hell, I agree with you, if X works and you like, rock on). But that's a pretty disingenuous take to make while discussing the merits of the platform with other folks.
None of those issues actually make X unusable. And I say that while writing this on an X1 Carbon running Debian testing using X in a multi-monitor setup (and yes, this is a totally plug-and-play setup with zero monkeying around in config files... a fact that, frankly, amazes me, having grown up hacking X modelines).
Wayland, by contrast, is literally unusable (as in, it lacks fundamental features that make it something people can't use) in many circumstances due to either compositor bugs, features that don't work by design, or features that don't work due to a lack of solutions or a lack of adoption of those solutions.
And I know this because I've tried to use it. I really like the possibilities it opens up.
But it's so far from mature, at this point, that it simply cannot act as an X replacement for most people.
Frankly, I'm a little shocked distros are making Wayland their default display server ecosystem, as it's an objective step backward for desktop Linux and I expect will scare a lot of neophytes away who wonder why the hell basic features like screensharing still don't yet work in their favourite application.
> Frankly, I'm a little shocked distros are making Wayland their default display server ecosystem
They're making it the default because it work better for most people.
You may not be most people, but I can at least concede that X is probably still the right choice for you.
You seem to be unable to have a good faith conversation about the merits of Wayland.
Actually, we haven't talked about the merits, yet!
Unfortunately, when I was playing around with Wayland, I struggled a bit to find the benefits that would make it so irresistible that I'd put up with the downsides.
Tear-free? Eh, I have that with X thanks to Intel's drivers. Though I absolutely understand that's not a universal experience.
Different display DPIs? Anything that falls back to Xwayland (which unfortunately is still a lot of applications) look like blurry garbage for obvious reasons, which means it's actually unusable in a lot of circumstances. And that's assuming solid application-level support (I seem to recall Firefox had mixed DPI regressions that were recently resolved, but that's only a vague recollection).
TBH, I was really really rooting for this feature as it could be really nice, and I was deeply disappointed when it didn't work out.
Touchpad gestures? Okay, legit these are really nice! Three-finger workspace switching in Gnome is pretty slick. OTOH, the lack of that feature isn't a dealbreaker, either.
General touchpad improvements? Funny thing is, libinput is being backported into Xorg, which means that you can get a lot of those benefits without switching. For example, I'm using Firefox with libinput2 and it's a fantastic improvement!
Honestly, I'd love a killer feature that'd push me to Wayland and cause me to put up with all the functional regressions. But I simply haven't found one... :(
So, at this point, I'm waiting for the regressions to be resolved. Hopefully we'll get global hotkeys, broadly supported screencasting, better application-level support for things like mixed DPI, and lots of bug fixes so I can finally make the switch!
I can say that 4 years ago I was firmly in the "it isn't ready" camp.
2 years ago, touchpad support was my "killer feature" (I'm left handed and have issues with RSI in my right wrist).
Global hotkeys work pretty much everywhere I've tried in the last year or so (including being able to configure global hotkeys in an electron app I have to maintain for work, which was a nice plus). I also actually tend to like that they're centralized and apps aren't able to just stomp all over the configured hotkeys.
Screencasting is still a pain point, but I actually appreciate the security model that makes it painful, and pipewire is functional enough that I can pretty easily share a screen on anything that can run in a browser (Zoom, Discord, Hangouts - Slack is still a pain).
I don't have issues with XWayland being blurry - although I do have issues with Xwayland windows having the same scaling restrictions as X (If you move a window from a scaled screen to a non-scaled screen, it won't re-adjust). Fortunately, most of my daily apps are now Wayland native, including my editor, my terminal, and my browser (Chromium build with ozone enabled).
---
Now, all that said, if you've tried recently and it's still not there, I absolutely get it. But I think it'll move faster than you expect. 4 years ago I certainly wouldn't have believed you if you'd told me I'd like Wayland enough to bother writing out this whole comment chain :D
To be clear you mean that can in your config file or settings menu bind a hotkey to run a particular action if and only if that action can be specified by a particular command line operation.
This is indeed my preferred way to specify such things I like that it is centrally managed and if the application developer lets you interact with the program that way it is quite powerful.
Is this possible on gnome wayland or just under sway?
There is another form of global hotkey configuration wherein the app lets you specify a global command for an operation that may be internally specified and may not be provided via a cli interface and this functionality will never work by design.
[1] https://help.gnome.org/users/gnome-help/stable/keyboard-shor...
Unfortunately I tried it... I'd estimate two months ago (I switched back to Debian testing from Ubuntu a couple of months back and decided to give Wayland a shot now that it's the default).
My touchpads work very well with X, out of the box (any Ubuntu I used.) HP ZBook 15 from 2014 and a HP nc8430 from 2006.
> Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
I can't comment on this. The few times I added another display it wasn't larger than the usual 1920x1080 px.
The difference is that a huge number of essential features both exist and actually work in X, but not in Wayland.
That particular X developer might have abandoned X, but X itself is still here, still works, and still does what I need. Can't say the same about Wayland, yet...
The X development community has decided, almost unanimously, that Wayland is the way forward. More powerful and knowledgeable forces than you have cast this die for you. It is now upon you to either adjust, or step up and contribute where Wayland is lacking.
When about do you think firefox will no longer build for X?
Python 3 was ready in 2008 but 2 will be supported by RHEL until at least 2024 16 years later. I will be surprised if in 2030 I can't simply pick distro with X and fire up firefox. Its kind of silly to expect users who are disinterested in using foo to pitch in to make foo acceptable when said users really want bar because you tell them that bar is now the standard "get over it".
Firefox? 2025 at the latest. Firefox was the project that deprecated ALSA a few years back. Now that all major distros ship with Wayland as the default, it's time to assume Wayland and not assume X. Eventually X support will become burdensome, and be removed.
The majority of users are still using x11 which is why for example Firefox just added hardware decoding under X last month. Optimistically for wayland this might change between 2024-26 at which point application developers can stop supporting it at which point people who are so inclined can provide an x11 build of Firefox in 2026-2028 which are liable to work through 2030.
In a less optimal world we are still in step one in 2030.
Anyone who thinks X is going anywhere this decade is dreaming.
I'd like to use Wayland. But there's no replacement to my bspwm+picom setup that works with a little configuration. Tough luck, guess I won't be using Wayland for now.
This is NOT a hypothetical. Projects have dropped ALSA support and adopted a policy of PulseAudio or GTFO -- and ALSA has more commitment to its long-term maintenance than Xorg now does. And I suspect the next phase will be Wayland maintainers putting pressure on toolkits to drop X support, much like Lennart pressured the GNOME community to hard-depend on systemd.
Lets keep them separate. I have no PulseAudio, solved Skype with apulse, though I don't use much media except browser, player and tuner.
When about do you think firefox will no longer build for X?
Python 3 was ready in 2008 but 2 will be supported by RHEL until at least 2024 16 years later. I will be surprised if in 2030 I can't simply pick distro with X and fire up firefox.
Actually, that's exactly one of the major reasons put forth for switching to Wayland. The very comment you replied to quotes it:
>>> a major maintainer of X server telling you he's not going to work to maintain the project anymore
If the project ends up truly unmaintained, it really would end up disappearing from the face of the earth as the platform under it (the hardware, the kernel, etc.) changes to the point that it becomes non-functional.
I’ve seen this happen multiple times with replacement systems: as long as people can escape back to the old system the new one remains rough around the edges, but once the old one is turned off the new system rapidly improves to production level quality.
The problem is that they can't be fixed, as I understand. People are asking for things that some see as features and others see as bugs.
The only way to keep everyone happy is for both to continue co-existing, but unless something changes, it doesn't seem like that's going to happen.
The kernel has a pretty strong backwards-compatibility stance, so you'd need to wait a long time.
Nobody stops you from running an outdated and insecure distribution to use X11 (in this hypothetical future). Nobody stops you from patching X11 to support newer interfaces.
If you want to stick with X11, you can. Nobody urges you to upgrade.
You don't want people to use a new thing because it might siphon off resource you're benefitting from now?
If you love X, go work on it, or pay people to. Otherwise... what possible point are you trying to make?
Did I express any want in my comment? I didn't even say anything about my preferences. I wonder if perhaps you replied to the wrong comment?
> what possible point are you trying to make?
To correct emersion about Wayland being an option. Do you think what I said was incorrect?
No, sorry. X11 clients are eternal, there's just way too many of them out there that are line-of-business and will never be ported to anything else. So I'm always going to need some solution to make those apps work, and since for the foreseeable future that probably means "run a nested X server that translates things to the native display server's API", that means Xwayland isn't going away any time soon, and if/when it does it'll be replaced by some other translation layer I'll need to support.
Ahh, classic: blame the user.
You are wrong for expecting things to work in a way that's familiar!
Global hotkey bindings? Sure, that works on Windows, macOS, and X, but it doesn't on Wayland and its your fault for expecting it.
The beatings will continue until morale improves!
> As an end-user you can continue to use what works for you.
LOL, Wayland is literally being marketed as the replacement for X. It's even the default display server in Debian, Ubuntu, and (I think?) Fedora.
Why are you surprised that people therefore expect stuff that works in X to work in Wayland?
It's not that. It's that global hotkey bindings are out of scope for a Wayland compositor. But don't worry. An API for such things for the crufty d-bus broker should be dropping aaaaaaany minute now... then all you have to do is wait for your compositor to support it!
Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
I understand that's not your intention, but that's effectively what you're doing.
I'm a former developer who moved into product management a long time ago, and I've seen the syndrome.
"I understand what you want, but we didn't build it that way, so you need to change your expectations" places the onus on the user to change their behaviour, instead of on the developer to build the thing the user actually wants.
> X is still included on those distros as a fallback option in case you have something that doesn't work.
The trouble is, a neophyte will a) have no idea what the difference is between Wayland and Xorg, and b) not realize that switching might fix whatever issue they're encountering.
And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
> Re global hotkey bindings: Can you please describe your setup to me? I honestly have no idea what you're talking about, global hotkeys were supported in all the Wayland implementations I tried recently. (KDE, GNOME, Sway, Wayfire)
It certainly doesn't.
Two examples that immediately spring to mind:
Guake, a handy pop-up terminal. In X I can press F12 anywhere and it opens. Super handy for quick terminal interactions, always-on commandline tools, etc.
Gnome Do or equivalent. Basically Quicksilver for Linux. Fast search, command execution, etc, from the keyboard. Hit a hotkey and it pops up.
Right now the way this works is that the compositor binds the key and then... does stuff. But that requires these applications to be redesigned to support that. For example, guake added a whole separate binary, 'guake-toggle', and it's only job is to toggle visibility.
Unfortunately, that requires the user to know that they need to go into their compositor settings, bind the key, and set it to run that application.
Meanwhile, on literally any other OS, this would be handled with a config setting right in the application.
Maybe eventually be addressed with yet-another-dbus-protocol, but right now it's just a gaping functional regression.
But they're definitely clever enough to be using xdotool. Lol.
Wayland may not fit with everyone, which is fine, no one is taking X away from you. But allow the vast majority of users to have their scaling displays and multiple monitor setups, which is far more common than your requirements. I'm sorry Wayland hasn't come far enough yet to cover you as well, but it's far enough for the vast majority of users. You bring up xdotool in everything thread as if it's something that Grandma uses Linux for. It's not.
> And BTW, this all presumes that a distro installs Xorg at all. If not, you've gotta dive into the package manager, which adds an additional barrier since you need to know what to look for and install.
So be honest what you're arguing for. You, as an accomplished unix user, want distro defaults to be tailored to your use case. That's not what distro defaults are there for.
That seems distinctly anti-grandma.
What kind of global hotkeys are we talking about that casual everyday users need, as opposed to people who build their own desktop OS from parts?
We all tried the universal frictionless global hotkeys thing. It was a really bad idea for a general audience [1]. That's why we have MPRIS for global media player controls (Firefox supports it now, which is awesome!), and stuff like the keyboard shortcut inhibit protocol for VMs and the like. It's unfortunate for the building an OS from parts thing, but unlike cars and smartphones, at least it is still all open source.
Interesting, I just noticed MacOS allows normally global keybindings to be overridden by applications that really want to override them.
So for example, doing Command-Tab in the VNC viewer will tab through applications on the VNC server you're connected to, which makes sense because you feel like you're using that other desktop. But everywhere else, Command-Tab is intercepted by the window manager and tabs through the local applications.
Same for other hotkeys that are usually universal, like the one that takes screenshots and screen recordings (which are both done really nicely in MacOS by the way), or the one that lets you search for anything.
This entire post is about Xorg becoming abandonware. People are expressing why they're not willing to switch to Wayland, citing lack of features they use.
> As an end-user you can continue to use what works for you.
Until Xorg becomes unmaintained and eventually breaks. Wayland is not being put forth as an option. The idea is that X will eventually be unsupported.
Besides, realistically speaking, not everyone is capable enough to do that. Their only way to contribute is to let the web know that not everyone prefers Wayland and why. Discussions like these are like feature requests and bug reports, only broader, encompassing multiple projects. Some people might interpret that as entitled b____ing, but then apparently so are feature requests and bug reports sometimes.
The right call would be kickstarter, patreon, any kind of sponsorship.
I would appreciate it if you could quote the article where it expounds on the cost.
I've read through it a few times, and could only find two very brief, vague, handwavy complaints against X:
1 - "the code happens to implement an unfortunate specification"
2 - "You can only apply so much thrust to the pig before you question why you're trying to make it fly at all."
As an end-user, I don't find these to be particularly convincing.
Moreover, X works for me now and does everything I need.
https://www.youtube.com/watch?v=GWQh_DmDLKQ
And directly from ajaxnwnk
https://news.ycombinator.com/item?id=24925189
> Moreover, X works for me now and does everything I need.
Someone makes pig fly all these years.
>But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
If X continues to work for you and you don't find it makes your life worse, then... keep using it?
From the article, about X:
> But using it to drive your display hardware and multiplex your input devices is choosing to make your life worse.
This is a weird conflation of this developer's experience after being burned out on development, and the user's experience running a modern distro.
If as I user I confuse those two things, then I'm going to click the button to choose Wayland when I log in. And I guarantee you my experience as a user will be worse on Ubuntu, Debian, and probably any other modern distro by making that choice.
I can work around that worse user experience by choosing alternative to what doesn't work, but that's a separate issue from the default UX under Wayland making my life easier.
This whole "desktop stack" on Linux always makes my head hurt, so these might be really dumb questions:
If I install some distro, Arch say, and I wanted to use Sway, and I then want to run Kile, will Kile then run through XWayland? Will it work just as well as Kile on KDE Neon?
I understand KWin has some Wayland support but it also seems not quite ready for prime time the times I've tried it. So was curious about alternatives, just for curiosities sake.
Kile seems to use Qt5, so should work without Xwayland.
> Will it work just as well as Kile on KDE Neon?
It should, yes. I don't use Kile though, so I haven't checked.
Since Kile is a KDE application it should run using Qts wayland backend.
> Will it work just as well as Kile on KDE Neon?
Depends, do you need anything more fancy than mouse and keyboard? No? Then great.
Power user functionality like copy paste on the other hand? https://github.com/swaywm/sway/issues/4007 might want to pray before using that.
Come on.
Congratulations, you've found the only opened bug report about clipboard on Sway/wlroots. It's triggered by edge cases (X11 client hanging + fcitx apparently), and most of it has been fixed already.
Are you really trying to convince people that the clipboard is broken on Wayland with this? Maybe you could start by actually trying Wayland.
Yikes! So just more fragmentation and half-baked alternatives.
Because Wayland pushes so much logic into the compositor, there's now the very real likelihood that things will work on Gnome but not KDE, or work in i3 but not Gnome.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols
And in my opinion the whole isolation and security concept is hot garbage. It hinders so many useful things. My Linux desktop is not a smartphone where I download random, badly screened closed source apps from a play store. I'm downloading open source tools via my distro's package manager. If one of these got backdoored, Wayland preventing it from taking a screenshot of another Wayland app won't exactly save the day anyways.
Instead we're now getting clumsy, overly complicated solutions for all these simple use cases. Ultimately I don't care. If people enjoy creating these needlessly complicated monstrosities, fine. It's just that we need to wait ten times as long until we get something usable that way. I guess X needs to keep chugging along a couple more years....
You're forgetting all of the untrusted Javascript (and soon Webassembly) most people are running through their web browser.
That seems to be one of the biggest security holes Wayland is designed to plug (to some extent).
Likely at least a decade (Lindy effect).