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.
> 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.
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...
My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad. Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
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.
> My opinion - today - is that X doesn't work on laptops where the user expects to use a touchpad. Nor does it work on a laptop with a resolution that requires scaling (at least not the second you plug in another display).
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.
> 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!
Honestly - It sounds like it's been a minute since you've tried it.
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.
The GNOME Settings app allows you to assign global hotkeys under Wayland using the normal GUI [1]. Not sure about configuring those hotkeys in a config file like i3/sway, I assume it’s some dconf thing.
> Now, all that said, if you've tried recently and it's still not there, I absolutely get it.
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).
"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."
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...
s/That particular X developer/All X developers, except maybe for Keith Packard/g
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.
This is an interesting dichotomy. Alternatively just keep using X until 2030-2040. If X does everything you presently care for well and major apps like gimp and firefox are apt to support X for the next decade+ an alternative contribution might be bug fixes for X or packaging for distros that opt to continue to support it.
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".
> When about do you think firefox will no longer build for X?
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.
You can still build Firefox with Alsa support and probably still will be able to in 2025.
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.
Or, we could just use X if it still works for us. I don't need any "more powerful and knowledgeable forces" to tell me what works for me and what doesn't.
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.
Yeah, except what happens when the apps and toolkits you use drop X support because they consider X a dead end? What will you do then?
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.
At that point the Wayland ecosystem is hopefully mature enough to make the switch less painful than it is now. I don't see anyone saying they'd rather toss their computer in the garbage than ever use Wayland, just that it doesn't currently meet their needs.
This is an interesting dichotomy. Alternatively just keep using X until 2030. If X does everything you presently care for well and major apps like gimp and firefox are apt to support X for the next decade an alternative contribution might be bug fixes for X or packaging for distros that opt to continue to support it.
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.
The other option is to maintain X. I'm not interested in that, and since thise who have done that in the past agree Wayland is the future I'm cautiously going to trust them and so I'll transition my systems to Wayland (if they are still x).
> Nobody is arguing that X.org's server will disappear from the face of the earth.
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.
X disappearing from the face of the earth would be a great thing for wayland, because people would be forced to fix the remaining issues.
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 issues can’t be ‘fixed’ in the Wayland protocol, but have been addressed by individual compositors and libraries like wlroots. The difficulty is not in building a decent Wayland desktop from scratch (GNOME, Sway and ChromeOS have all done this), but in rewriting X11 window managers, screen sharing apps and automation tools that perform functions that are the compositor’s responsibility under Wayland.
>as the platform under it (the hardware, the kernel, etc.) changes to the point that it becomes non-functional.
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.
That's precisely what people are arguing. That's precisely what Kristian Høgsberg wanted from the get-go: for X to simply go away, except as a compatibility layer for "legacy applications". (And I bet Xwayland will eventually be deprecated and unsupported, except for Red Hat's government clients or something.) X has been quasi-officially deprecated for years now, with Wayland offered as its replacement.
> (And I bet Xwayland will eventually be deprecated and unsupported, except for Red Hat's government clients or something.)
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.
I said this last time, but ydotool probably won't ever have the same features as xdotool because the scope isn't the same. A lot of the X commands in xdotool don't even make sense in the context of wayland, so it would be unreasonable for them to have the same scope.
I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way. It's not, that's the entire point. As an end-user you can continue to use what works for you. Yes X is much more flexible at some things (and Wayland is more flexible at others) but it comes at a cost which is expounded on by the article.
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way. It's not, that's the entire point.
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?
> Global hotkey bindings? Sure, that works on Windows, macOS, and X, but it doesn't on Wayland and its your fault for expecting it.
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!
Please tone down the rhetoric, I'm not blaming anybody. X is still included on those distros as a fallback option in case you have something that doesn't work.
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)
> Please tone down the rhetoric, I'm not blaming anybody.
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.
> 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.
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.
And regarding global hotkeys? Something which before would involve going into an application's settings and seeing "Choose hotkey for X", a la Windows, now involves going into the compositor's settings, adding a hotkey, knowing what the command line is and how to achieve X via the command line, understanding how launching commands can affect already-running instances of applications, adding a hotkey there...
I think we should acknowledge many people have grandmas who build desktop operating systems, so this is perhaps a source of misunderstanding :b
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.
> I'll repeat: please tone it down, this is not the way to contribute to open source.
I don’t have a dog in the Wayland-X fight, but I don’t see any excess or unproductive rhetoric in GP’s contributions here. They seem factual and specific with some background thrown in. When you twice asked for it to be toned down, I went looking to find offense and couldn’t.
Contributing to open-source by stating concerns as a user of the system is a minor positive way to contribute. Writing docs for workarounds is a greater positive. Contributing code patches is a yet greater way, but those don’t take away from the fact the filing bugs (literally or conversationally) is still a positive action.
I also apologize if I was seen as being rude or demanding or condescending but my request was sincere. I don't find that type of conversation to be productive and all I can do when it's directed at me is ask someone nicely to stop. I'll repost the other part of my post because I think it gets to the substance of the issue.
Re global hotkeys: I still don't understand your complaint. You just described two applications that didn't work and then went on to explain how one of them was made to work on Wayland. Yes, applications need to be ported, no solution on the Wayland side will ever change that. If the complaint is that the chosen method adds latency, or that the config setting has moved, those are vastly different than your original complaint which is that it doesn't work. Is that closer to what you were getting at?
> Re global hotkeys: I still don't understand your complaint. You just described two applications that didn't work and then went on to explain how one of them was made to work on Wayland. Yes, applications need to be ported, no solution on the Wayland side will ever change that. If the complaint is that the chosen method adds latency, or that the config setting has moved, those are vastly different than your original complaint which is that it doesn't work. Is that closer to what you were getting at?
Let's compare the workflows.
In X, in order to make guake open by pressing "F12" on the keyboard (which, by the way, is probably the feature that makes guake useful, since its entire purpose is to be a terminal you can pop up with a hotkey), I have to take the following steps:
1. Install Guake
2. Run Guake
That's it (F12 is the default hotkey for guake). It just works.
And it's the kind of thing that's possible on literally every other desktop OS that's ever existed prior to Wayland coming along.
Here's the steps I have to take when using mutter specifically.
1. Install Guake.
2. Realize F12 doesn't work because, in the Wayland ecosystem today, it is impossible for an application to bind a global hotkey.
3. Find a workaround online. Discover "guake-toggle" exists and that I have to manually bind a hotkey to call it.
4. Open the Gnome hotkey configuration screen.
5. Add a new binding for F12. Enter "/usr/bin/guake-toggle" as the command to execute when the key is pressed.
(actually, that's a lie, my vague recollection is you can't actually bind F12 at all in Gnome and so I used F11 as my test... but that's a whole other thing and probably a Gnome bug)
However:
1. This set of steps only works with mutter. For another wayland compositor the steps may be completely different. Or there may be no steps at all if the compositor doesn't have some mechanism to specify a global hotkey.
2. It happens to work with Guake because the author realized a wayland compositor was gonna need a workaround, and they created guake-toggle. For other applications it's possible no such workaround exists at all.
3. It's in any case a profound UX regression.
Now, yes, you can make the claim that guake was "made to work on Wayland".
But if your claim is that therefore nothing is wrong in this situation, I have to admit to simple astonishment and bafflement because I don't know how anyone could not see a problem here.
Now, to be clear: I'm not suggesting this is the sole issue that's preventing my use of Wayland. There is, after all, this crappy workaround.
Rather, as a reminder, this thread started with my replying to this remark:
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X in exactly the same way.
I hope you can see that my issue isn't that I expect Wayland to "do all the same things as X in exactly the same way".
Rather, I expect Wayland to enable applications to offer the same kind of basic functionality, with the same level of usability, that users are used to experiencing with applications, not just on X, but on any modern desktop operating system.
This is just one example where that's actually not possible today due to immaturity in the ecosystem.
In the first post, it was suggested that I was blaming someone. There is nobody there to blame, it seems more like a misunderstanding or a case of missed expectations, which is why I said I didn't understand. In the second post, it was suggested that my request for clarification means I have some sort of "syndrome" which was based on a misrepresentation of my position. I don't find this to be productive conversation.
I'd love to talk about bugs but I have no interest in talking about them if it involves this kind of behavior. And I don't have a dog in any fight either—both of these projects will likely be around for a very long time.
> I don't understand where you're getting this idea that Wayland is or was supposed to do all the same things as X
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.
Yes it does, but that's not going to stop people from expressing themselves online or discuss the disadvantages of what's coming.
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.
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.