Does the multiple compositor situation result in duplicated effort and/or constraints for the end user such as being unable to run Konsole on Gnome3 etc?
My understanding is that simple applications like Konsole should be fine because they only use widely-implemented protocols. Where it goes off the rails is when you want to do exotic things like take a screenshot, and GNOME, KDE, and wlroots have each implemented a different protocol to do so.
I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Capturing your screen is, too. Even by third-party programs.
And yet they never put it in the protocol but just said to go to dbus.
> GNOME, KDE, and wlroots have each implemented a different protocol
Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1].
Nowadays I think every compositor(?) just implements the xdg-portal stuff.
I think to the Wayland folks, anything other than using Windows is an exotic use case. They’re not entirely wrong, but if we wanted to use Windows, we … would be using Windows. The great thing about Linux was that we could do more than Windows or macOS permitted.
Weird take. Windows and macOS both let you do things Wayland doesn't currently have widely adopted protocols for. Only thing Xorg can do that any of the others can't is let a client application manage windows, and it's only macOS that really doesn't like that.
> I'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often.
Yes, I was intending to mock Wayland for failing, after 15 years of development, to have a single way of taking screenshots that works in all environments. I understand wanting to make things modular and flexible and make as much optional as possible[0], and I understand wanting to ship the core protocol first and then follow up with drafting other things and building consensus, but the fact that this thing was allowed to hit end-users with screenshots this broken - and that it still hasn't been fixed, and AIUI never will be fixed because GNOME seems to think that the situation doesn't need fixing - is a fairly damning incitement of Wayland as a whole.
> Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff.
I think it's true, though it's honestly hard to tell. Most of the screenshot tools I could find are using the wlroots protocol, KDE's official tool notes,
> Spectacle is a screenshot taking utility for the KDE desktop. Spectacle
can also be used in non-KDE X11 desktop environments.
which doesn't really explicitly say much, and in fact the only tool I could find that claimed to be able to support everything was ksnip, which seems to work fine with wlroots but beyond that https://github.com/ksnip/ksnip#known-issues outlines the situation well enough; KDE is at least only temporarily broken, but GNOME isn't going to improve because GNOME did that on purpose. Now, that readme says you can use xdg-desktop-portal, but I have a GNOME+Wayland machine on hand, and I couldn't get it to actually work. I think what's supposed to happen is that every time I do a screenshot it prompts for permission, which I wanted to verify so I could complain that that was totally unreasonable, but what actually happens is that it just fails, which is... not better. Oh, and while searching for solutions to that I found flameshot, but that just refuses to even run. So... maybe someday the portal solution will work; in the meantime, I feel comfortable describing the situation as Wayland not having a uniform working way of taking screenshots.
[0] In particular, so we can avoid the situation from X11 where a load of drawing primitives are baked in that nobody has any use for anymore.
You definitely get discrepancies in hardware support. Historically, different Wayland desktops had wildly differing support for Nvidia cards, for example, from "works perfectly" to "deliberately rejects them because the maintainer is angry about their lack of commitment to Wayland".
There's been volumes written about the problems with X and what would've been done differently. Of course given enough time I'm sure Wayland will end up in the same place, it does have the advantage that it was designed to be extended upon and for implementations to be built from interoperating components (vs the monolithic Xorg).
The big difference really comes down too that X was designed to connect applications, input devices, and displays (including printers!!) across a network in a time when the concept of a untrusted network didn't really exist. Neither was there a concept of a GPU as they exist now.
Conversely Wayland was designed to connect those items (sans printers) within a computer and to default to providing the minimum amount of trust to those things, particularly applications.
I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default, and IIRC will actually fight you about trying to do so to the extent that when I wanted to use it that way I ended up using socat to bridge TCP to the local socket.
The general comment about trust and security is true, though; ex. the usual complaints about any X11 application being able to keylog any other (which XACE exists to counter, but since nobody seems to have done so I'm assuming it had problems!?)).
> I don't think the network thing actually matters; modern Xorg doesn't expose anything to the network by default...
It matters from the design and architecture perspective. It's foundational underpinnings we're constructed to support remote terminals. That really hasn't been a usecase for a very long time but the core architecture was built with that in mind and the monolithic nature of the code makes it very hard to change that.
The issues that got us to where we are with X are twofold and unlikely to repeat:
1) The nature of the hardware changed completely. The core X protocol [0] was designed around 2D shapes and is prepared to do things like FillPoly or PutImage. This means it was largely caught unaware by the move to shader-based graphics and the absurd amount of processing power we have todaty in graphics cards. Wayland from what I understand just manages buffers which is better design. Things like OpenGL were tacked on to X as an extension, and now pretty much everything wants to be handled through OpenGal, but the X design wasn't prepared for that.
2) That would have been enough to kill X from what I've seen, but ... the major vendors had horrible binary drivers that only supported X, so every fork or new project died. The big change was AMD buying ATI and taking the drivers open source from 2007, since then there have been the sound of plate tectonics as the Linux graphic stack has reformed because now it is possible to develop deep in the graphics stack independently of AMD/Nvidia support. Note that if Wayland needed to work well on Nvidia it would have likely died a decade ago.
So the positive things are Wayland probably won't be hit by the same level of hardware change, and if it is it is much easier to replace. Really what has changed is that the majority of vendors have open source drivers, and Nvidia is eventually going to fold and join the club. Not that it matters, anyone who cares in the Linux ecosystem buys AMD - this deep learning thing has been an unfortunate stumbling block but that looks like it will be transient to me.
> confidence wayland wont end up in a similar state?
wayland have the issues of today. So they are not the same as the issues of yesterday like x11. guaranteed a different state!
In ten years you will probably be crying that opening a window on wayland requires you to enter a hostname which is long gone into your etc hosts file, pointing to a local server, so it can download the window theme on the fly, as root, or something. You know, today's problems.
However, the fundamental problem is that Linux is the only OS with more than one GUI toolkit. This means that you have to insert extra layers of abstractions that other OSes don't deal with.
Every other OS has a native toolkit which is integrated with native drivers. The GUI and compositor and OS go together. And even those have lots of issues.
When you try to sidestep that integration, you get lots of jank and problems (see: Flutter, for example).
Wayland and Co. are wrangling a bear that other companies struggle with with way less resource and way less control over the interlocking layers.
What counts as a GUI toolkit? Microsoft has like a half dozen dead or deprecated attempts at GUI frameworks, unless you're using a different definition.
Pick one. And note that all of those GUI toolkits still work on Windows 11, AFAICT.
Touch screens work even on old VB6 programs, for example. Try that on Linux and watch the tears flow. This is my point.
Everything is locked together and tested together. The OS, the toolkit, the input mechanism, the video driver, etc. all get developed together and don't need 4 layers of ill-defined abstraction between them.
Xenocara works right under OpenBSD and HyperBola GNU/Linux. It works on legacy devices and newer ones. Security? Use separate accounts for work and entertainment. Don't run untrusted crap. If any, use an UXterm with the keyboard locking option in the menus and do the sensitive stuff there.
> Use separate accounts for work and entertainment.
Doesn't quite save you if one of your work programs secretly siphons all your clipboard contents away to a third party. This is why we can't have nice things.
You're thinking too much in the realm of user-friendly. Of course on openBSD you would enclose work programs in a xephyr and an ad hoc rdomain, or connect a xephyr to a vmm's Xenocara with its own tap device. Xephyrs don't share clipboard per default.
I guess I'll repeat something I kind of wondered in the other thread - if xwayland works, including in rootful mode, is it practical to just polish it a tiny bit and ship a... xorg-server-shim package or however is easiest, that acts as a drop-in replacement and just runs on top of Wayland? I've been playing with this on my local machine, and running cage[0] with xwayland seems to mostly[1] just work - you run cage, you run an X11 window manager on it using xwayland, and then you ignore the underlying Wayland stuff and run X11 programs, including things like xdotool or such that don't really work in a mixed environment.
The advantage is that you can have it both ways - users who are ill served by Wayland can keep running an effectively pure X11 environment, but ex. graphics drivers only need to support Wayland.
[1] Not 100% - there's some weirdness with keyboard configuration, and of all things xscreensaver-settings wouldn't run, even though everything else I ran worked just fine.
I think the reason for rootful XWayland to exist, and the fact that it's like 100% made by Red Hat, hints that this is why they are doing it.
But I would like to run native Wayland clients too, and have them behave in such an environment. Can a compositor be made in such a fashion that it would cooperate with XWayland and manage native clients?
> I think the reason for rootful XWayland to exist, and the fact that it's like 100% made by Red Hat, hints that this is why they are doing it.
I had assumed the same, but then they announced that they were discontinuing xorg-server without pointing to rootful xwayland, so I'm not sure how to read the situation.
> But I would like to run native Wayland clients too, and have them behave in such an environment. Can a compositor be made in such a fashion that it would cooperate with XWayland and manage native clients?
You can have a mix with non-rootful xwayland on a wayland compositor; that's the easy path, really. I don't know if there's a way to have a X11 window manager control Wayland windows in that kind of system, though.
He is much more positive than I expected. He kept the ranting and insults to a minimum and even acknowledge that the new model is superior, he gives ideas how to do the port while stating that he doesn't have the patience to do it!
A decade before people start looking for a replacement is pretty good numbers. Especially if you consider that's when the search for replacement starts. Xorg continued to see significant development for about a decade alongside Wayland.
Of course W was only a couple years old before being replaced by X. So maybe we'll see Waylands replacement much sooner. I wonder if people were debating W vs X the way we debate X vs Wayland?
Whenever I think of X or Wayland it always makes me think of what the Windows code must be like. What secret monolithic struggles have the Windows devs secretly been fighting with for the past 30 years that nobody will ever appreciate?
I think it was raymond chen's blog that made it clear a lot of work was done by MS trying to survive the market with competition, legacy, partnership constraints .. a lot that was never mentioned because it wasn't a business argument and was just expected to be done behind curtains.
I don't really understand how one engineer working full-time on Xorg, two weeks of QA, two months for a feature, etc. should be even remotely considered a burden to a company as large as Red Hat.
Well RH is already locked into this level of maintenance support for existing RHEL releases. By dropping Xorg support now, they can fully drop this effort in a decade plus. If they keep Xorg support in new releases, it keeps pushing that horizon out further and further.
What he said was, a couple of weeks of QA, per stack, per hardware enablement.
Given that new hardware is constantly being released every couple of months, that adds up to a lot of QA. And as they said in a followup, that's "a couple of weeks" for a team of people and not just one or two.
So yeah, "two (additional) weeks of QA" wouldn't be that bad, but really it's more like "two (additional) weeks of QA, multiple times a year, for a team of multiple people". And that's not insubstantial given the meager revenue opportunities in the desktop linux market.
Thanks for replying, that makes more sense. Since you work for Red Hat, do you happen to know what the process for certifying hardware is? I'm curious to know what goes into guaranteeing that a given hardware configuration is supported by RHEL.
The tl;dr is that the comment on one engineer's tasks and the QA that one of the chores takes weren't intended to communicate that the team was 1 person big (or, presumably, that there's only one QA chore).
FWIW, my read of the wording around QA was that when a each new hardware platform is enabled, it takes 2 weeks for the whole team to work through their test cases. I assume, though I don't know, there's a lot of other QA done, such as when a new feature is added or something.
> Customer with expectations that are difficult to match. e.g., using xorg modesetting you had tearing, which is not acceptable for e.g. digital signage. Intel-drv driver had tearfree, but then new hw didn't work. Solving took more than 2 months. This is standarized in Wayland.
I'd like to know more about this one.
I mean, suppose the digital signage hardware/software supported OpenGL GPU-accelerated rendering. In that case how would Xorg tearing/tearfree matter? The software is just rendering using OpenGL so Xorg vs. Wayland shouldn't make any difference. IIRC some game dev mentioned this once, how their game is just using a toolkit doing full-screen accelerated rendering-- the underlying display server didn't really make a difference.
If I'm right, then the signage hardware must have been using non-accelerated path under Xorg.
That leaves me wondering:
* is most modern digital signage running without any GPU acceleration?
* does software rendering work well enough under Wayland to deliver smooth animation for professional use cases on underpowered hardware?
I'm just having trouble thinking of digital signage constraints that need high-enough framerate that Xorg was a problem, but also low enough that software rendering was feasible.
I expect a lot of digital signage is running through a browser engine these days, like everything else. Who would be targeting raw OpenGL surfaces these days?
Even if you render with whatever you please, software, OpenGL, Vulkan, you have to communicate with Xorg to slap it on the screen, and that'll result in tearing. On my Nvidia machine, the only escape from tearing is manually enabling the full composition pipeline in Nvidia's settings application. Nothing else, even Vsync settings, can save me from it.
For some background on the setting, you can check out this thread [0]. My system rarely reboots and I'm the only user, so I just set this manually every single boot by popping open nvidia-settings, going to the X Screen settings, clicking Advanced, then enabling the Force Full Composition Pipeline checkbox, and applying. While I was searching, I also found a this resource [1] for automating that a bit, a few shell scripts that just call nvidia-settings and some xorg config tweaks.
> ...I just set this manually every single boot by...
Man, folks talk about all sorts of things that X11 doesn't do. (And you have some manual steps that you do every boot (but (as you say) could easily automate.)
and I get all these things that people say X11 doesn't do:
* zero tearing... whether in KDE or WindowMaker
* zero problems with my mixed-DPI displays (one 32" 2160p display, and one 24" 16:10 1200p display)
* zero problems with my mixed-refresh-rate displays (one at 60Hz and one at 59.95) (This one I've tested with my eyes and also with MPV. MPV is 100% aware of the display's refresh rate, and will dynamically get updates to that information as its window moves between the two displays.)
I DO NOT get VRR, because (last I checked) kwin on xorg doesn't support that.
I wonder how many folks who think that this stuff doesn't work are on Nvidia hardware. (Which (by the sound of it) doesn't work all THAT much better on Wayland.) I also wonder how many are on AMD/ATI hardware and don't know about the 'TearFree' option.
X11 doesn't do it. I did it. X11 would be tearing til the cows come home if I didn't intervene. I'm glad MPV is well-behaved but not nearly every application is. I can't get smooth motion in many applications on my machine because my main display running at 59.95 will hitch regularly as it lags behind the 60Hz secondary monitor.
Even you had to manually configure your system not to tear uncontrollably with a config file. Wayland isn't as mature as X11, sure, and the lack of color management (sorta) is a critical and fatal flaw, but it doesn't have these foundational issues that need to be worked around manually by the user on every system 20 years after every other display stack on the planet figured this all out.
X11 is mature and workable but it's not good. And it often shows the decades of mud its codebase has been dragged through. I'll be thrilled when Wayland matures and when Nvidia finally pulls its head out of its butt.
mpv is the tool I used to demonstrate that software running in xorg has access to the screen's refresh rate... and that mixed-refresh-rate screens obviously work fine in xorg. ALL of the software I use is tear-free on ALL of my installed displays, not just mpv.
> Even you had to manually configure your system not to tear uncontrollably with a config file.
The __entire point__ of `/etc/X11/xorg.conf.d/` is so that both distros and users can put configuration snippets in there to configure behavior for whatever hardware is currently installed. I use Gentoo Linux- a distro that requires that you supply your own batteries, so I supply my own config files.
> I can't get smooth motion in many applications on my machine because [I'm using NVIDIA hardware and have displays with unmatched refresh rates.]
> I'll be thrilled when ... Nvidia finally pulls its head out of its butt.
NVIDIA is okay if you're doing one of the very few things they expect you to. If you want to do most other things (like suchas have multiple displays attached to your video card that don't have exactly the same refresh rate) they are terrible. NVIDIA regularly goes off and does their own thing (usually very poorly), rather than use the thing that everyone else developed that works well.
The NVIDIA-on-Linux situation has been bad for at least twenty years. Torvalds' now-eleven-year-old "[NVIDIA is] the single worst company we [Linux developers] have ever dealt with ... NVIDIA: FUCK YOU!" remark [0] was motivated by legitimate, long-standing complaints that have yet to be resolved.
If you're using an NVIDIA card on Linux, and you're using it as a graphics display or 3D accelerator card (rather than -say- CUDA and friends) you're deliberately and enthusiastically plunging your hand and whole arm into a bag of sharp knives. It's not going to get notably better because it hasn't gotten better in the last 20+ years.
That's what the sponsor of Wayland development is saying, yes.
> Is there an official announcement of the death of xorg or something?
No, because after fifteen fucking years of development, it still isn't good enough to work everywhere that xorg does. (Over those years it has also lost many of the much-touted "xorg server developers" that abandoned working on xorg to start on another project that was less awful to work on.
Well... guess what Wayland turned into? XD
xorg works, and -at least for me- most of the things that people seem to say doesn't work on it actually do [0]. Contrary to popular belief, you don't need a billion-dollar company to fund development on a piece of software that runs your application software just fine. And this isn't the fucking webdev world, so you don't need a team of twenty just to keep up with unending churn-for-churn's sake.
Yeah, this makes sense to me. One problem that open source has is like a million fractured efforts for the same wheel. It can lead to a million half-baked solutions instead of maybe just a few solid options. I know it has pros, too, but in many ways it would be easier if there were less projects and more people contributing to main projects.
>One thing I saw in comments about the removal of xorg server is that some might not see how much work is/was to maintain xorg server. I understand is hard to see from outside, but maintaining xorg server with the standards we have in RHEL is not a small beast
So you choose a big beast to maintain because "it's cool".
And, btw, which standards do you have in RHEL ? (Some years ago fvwm was removed. The feeling at that time it was that fvwm ate to few memory, that's why it was removed)
I'm afraid it's too easy to characterize things as too hard and expect people to believe it.
Protocols can be versioned, there's no reason Xorg can't become more of a compositor itself.
I'd like to see someone describe ame compare building simple and medium complexity GUIs in both Xorg and Wayland. Maybe I'll do it myself if there's some interest or ideas for test targets.
How is rewriting Xorg to be very different from what it is now much different from writing Wayland from scratch? If you make it more like wayland it will break probably as much stuff. And rewriting can be harder than starting from a blank slate.
Creating Wayland made it possible to do some very radical changes. When rewriting software you are much more careful to not break anything.
Apart from that the discussion is pretty much settled. Most distros and major desktop environments have commited to wayland. You'd have to have a very compelling argument to move things back to Xorg.
Who decided the discussion was settled? That's needlessly dismissive. Just because Wayland devs used to work on Xorg and gave up? That's their decision, it doesn't dictate mine.
Most things can be improved and adapted, that is especially true of software.
78 comments
[ 0.26 ms ] story [ 150 ms ] threadI'm not sure but is this meant ironically? Because taking a screenshot is a thing people do very often. Capturing your screen is, too. Even by third-party programs. And yet they never put it in the protocol but just said to go to dbus.
> GNOME, KDE, and wlroots have each implemented a different protocol
Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff.
[1]: https://gitlab.freedesktop.org/wayland/wayland/-/issues/32#n...
Yes, I was intending to mock Wayland for failing, after 15 years of development, to have a single way of taking screenshots that works in all environments. I understand wanting to make things modular and flexible and make as much optional as possible[0], and I understand wanting to ship the core protocol first and then follow up with drafting other things and building consensus, but the fact that this thing was allowed to hit end-users with screenshots this broken - and that it still hasn't been fixed, and AIUI never will be fixed because GNOME seems to think that the situation doesn't need fixing - is a fairly damning incitement of Wayland as a whole.
> Is that true? My understanding was that GNOME never put forth a protocol but always did their dbus thing. I know that wlroots proposed a bunch of protocol extensions but those never went anywhere since, well, GNOME didn't want to implement them[1]. Nowadays I think every compositor(?) just implements the xdg-portal stuff.
I think it's true, though it's honestly hard to tell. Most of the screenshot tools I could find are using the wlroots protocol, KDE's official tool notes,
> Spectacle is a screenshot taking utility for the KDE desktop. Spectacle can also be used in non-KDE X11 desktop environments.
which doesn't really explicitly say much, and in fact the only tool I could find that claimed to be able to support everything was ksnip, which seems to work fine with wlroots but beyond that https://github.com/ksnip/ksnip#known-issues outlines the situation well enough; KDE is at least only temporarily broken, but GNOME isn't going to improve because GNOME did that on purpose. Now, that readme says you can use xdg-desktop-portal, but I have a GNOME+Wayland machine on hand, and I couldn't get it to actually work. I think what's supposed to happen is that every time I do a screenshot it prompts for permission, which I wanted to verify so I could complain that that was totally unreasonable, but what actually happens is that it just fails, which is... not better. Oh, and while searching for solutions to that I found flameshot, but that just refuses to even run. So... maybe someday the portal solution will work; in the meantime, I feel comfortable describing the situation as Wayland not having a uniform working way of taking screenshots.
[0] In particular, so we can avoid the situation from X11 where a load of drawing primitives are baked in that nobody has any use for anymore.
Xorg is a server.
The big difference really comes down too that X was designed to connect applications, input devices, and displays (including printers!!) across a network in a time when the concept of a untrusted network didn't really exist. Neither was there a concept of a GPU as they exist now.
Conversely Wayland was designed to connect those items (sans printers) within a computer and to default to providing the minimum amount of trust to those things, particularly applications.
The general comment about trust and security is true, though; ex. the usual complaints about any X11 application being able to keylog any other (which XACE exists to counter, but since nobody seems to have done so I'm assuming it had problems!?)).
It matters from the design and architecture perspective. It's foundational underpinnings we're constructed to support remote terminals. That really hasn't been a usecase for a very long time but the core architecture was built with that in mind and the monolithic nature of the code makes it very hard to change that.
1) The nature of the hardware changed completely. The core X protocol [0] was designed around 2D shapes and is prepared to do things like FillPoly or PutImage. This means it was largely caught unaware by the move to shader-based graphics and the absurd amount of processing power we have todaty in graphics cards. Wayland from what I understand just manages buffers which is better design. Things like OpenGL were tacked on to X as an extension, and now pretty much everything wants to be handled through OpenGal, but the X design wasn't prepared for that.
2) That would have been enough to kill X from what I've seen, but ... the major vendors had horrible binary drivers that only supported X, so every fork or new project died. The big change was AMD buying ATI and taking the drivers open source from 2007, since then there have been the sound of plate tectonics as the Linux graphic stack has reformed because now it is possible to develop deep in the graphics stack independently of AMD/Nvidia support. Note that if Wayland needed to work well on Nvidia it would have likely died a decade ago.
So the positive things are Wayland probably won't be hit by the same level of hardware change, and if it is it is much easier to replace. Really what has changed is that the majority of vendors have open source drivers, and Nvidia is eventually going to fold and join the club. Not that it matters, anyone who cares in the Linux ecosystem buys AMD - this deep learning thing has been an unfortunate stumbling block but that looks like it will be transient to me.
[0] https://x.org/releases/X11R7.7/doc/xproto/x11protocol.html
Meanwhile, I understand that Wayland in 2023 still doesn’t support what X11 supported in 2000. If true, then it’s simply not fit for purpose.
wayland have the issues of today. So they are not the same as the issues of yesterday like x11. guaranteed a different state!
In ten years you will probably be crying that opening a window on wayland requires you to enter a hostname which is long gone into your etc hosts file, pointing to a local server, so it can download the window theme on the fly, as root, or something. You know, today's problems.
However, the fundamental problem is that Linux is the only OS with more than one GUI toolkit. This means that you have to insert extra layers of abstractions that other OSes don't deal with.
Every other OS has a native toolkit which is integrated with native drivers. The GUI and compositor and OS go together. And even those have lots of issues.
When you try to sidestep that integration, you get lots of jank and problems (see: Flutter, for example).
Wayland and Co. are wrangling a bear that other companies struggle with with way less resource and way less control over the interlocking layers.
In addition to the major ones that are supported in X11 / Wayland!
Touch screens work even on old VB6 programs, for example. Try that on Linux and watch the tears flow. This is my point.
Everything is locked together and tested together. The OS, the toolkit, the input mechanism, the video driver, etc. all get developed together and don't need 4 layers of ill-defined abstraction between them.
Doesn't quite save you if one of your work programs secretly siphons all your clipboard contents away to a third party. This is why we can't have nice things.
The advantage is that you can have it both ways - users who are ill served by Wayland can keep running an effectively pure X11 environment, but ex. graphics drivers only need to support Wayland.
EDIT: Oh hey, it looks like Puppy Linux actually did exactly this, including using cage: https://github.com/puppylinux-woof-CE/woof-CE/pull/2265
[0] https://www.hjdskes.nl/projects/cage/
[1] Not 100% - there's some weirdness with keyboard configuration, and of all things xscreensaver-settings wouldn't run, even though everything else I ran worked just fine.
But I would like to run native Wayland clients too, and have them behave in such an environment. Can a compositor be made in such a fashion that it would cooperate with XWayland and manage native clients?
I had assumed the same, but then they announced that they were discontinuing xorg-server without pointing to rootful xwayland, so I'm not sure how to read the situation.
> But I would like to run native Wayland clients too, and have them behave in such an environment. Can a compositor be made in such a fashion that it would cooperate with XWayland and manage native clients?
You can have a mix with non-rootful xwayland on a wayland compositor; that's the easy path, really. I don't know if there's a way to have a X11 window manager control Wayland windows in that kind of system, though.
jwz must be so happy...
Or, in the next year or two, going by the Xfree86/Xorg timeline.
It’ll be interesting to see whether the (inevitable) Wayland or X11 compatibility layer is the more-heavily-used one in that future system.
Of course W was only a couple years old before being replaced by X. So maybe we'll see Waylands replacement much sooner. I wonder if people were debating W vs X the way we debate X vs Wayland?
Wayland is a fundamental rethink of the entire graphics stack -- much needed for modern systems.
Red Hat Enterprise Linux 10 Plans for Wayland and Xorg Server - https://news.ycombinator.com/item?id=38440607 - Nov 2023 (160 comments)
Enjoy
Disclosure: I work for Red Hat.
What he said was, a couple of weeks of QA, per stack, per hardware enablement.
Given that new hardware is constantly being released every couple of months, that adds up to a lot of QA. And as they said in a followup, that's "a couple of weeks" for a team of people and not just one or two.
So yeah, "two (additional) weeks of QA" wouldn't be that bad, but really it's more like "two (additional) weeks of QA, multiple times a year, for a team of multiple people". And that's not insubstantial given the meager revenue opportunities in the desktop linux market.
The tl;dr is that the comment on one engineer's tasks and the QA that one of the chores takes weren't intended to communicate that the team was 1 person big (or, presumably, that there's only one QA chore).
FWIW, my read of the wording around QA was that when a each new hardware platform is enabled, it takes 2 weeks for the whole team to work through their test cases. I assume, though I don't know, there's a lot of other QA done, such as when a new feature is added or something.
I'd like to know more about this one.
I mean, suppose the digital signage hardware/software supported OpenGL GPU-accelerated rendering. In that case how would Xorg tearing/tearfree matter? The software is just rendering using OpenGL so Xorg vs. Wayland shouldn't make any difference. IIRC some game dev mentioned this once, how their game is just using a toolkit doing full-screen accelerated rendering-- the underlying display server didn't really make a difference.
If I'm right, then the signage hardware must have been using non-accelerated path under Xorg.
That leaves me wondering:
* is most modern digital signage running without any GPU acceleration?
* does software rendering work well enough under Wayland to deliver smooth animation for professional use cases on underpowered hardware?
I'm just having trouble thinking of digital signage constraints that need high-enough framerate that Xorg was a problem, but also low enough that software rendering was feasible.
[0] https://www.reddit.com/r/linux_gaming/comments/6voivr/can_an...
[1] https://unix.stackexchange.com/questions/510757/how-to-autom...
Man, folks talk about all sorts of things that X11 doesn't do. (And you have some manual steps that you do every boot (but (as you say) could easily automate.)
Me? I just have this one file:
and I get all these things that people say X11 doesn't do:* zero tearing... whether in KDE or WindowMaker
* zero problems with my mixed-DPI displays (one 32" 2160p display, and one 24" 16:10 1200p display)
* zero problems with my mixed-refresh-rate displays (one at 60Hz and one at 59.95) (This one I've tested with my eyes and also with MPV. MPV is 100% aware of the display's refresh rate, and will dynamically get updates to that information as its window moves between the two displays.)
I DO NOT get VRR, because (last I checked) kwin on xorg doesn't support that.
I wonder how many folks who think that this stuff doesn't work are on Nvidia hardware. (Which (by the sound of it) doesn't work all THAT much better on Wayland.) I also wonder how many are on AMD/ATI hardware and don't know about the 'TearFree' option.
Even you had to manually configure your system not to tear uncontrollably with a config file. Wayland isn't as mature as X11, sure, and the lack of color management (sorta) is a critical and fatal flaw, but it doesn't have these foundational issues that need to be worked around manually by the user on every system 20 years after every other display stack on the planet figured this all out.
X11 is mature and workable but it's not good. And it often shows the decades of mud its codebase has been dragged through. I'll be thrilled when Wayland matures and when Nvidia finally pulls its head out of its butt.
> Even you had to manually configure your system not to tear uncontrollably with a config file.
The __entire point__ of `/etc/X11/xorg.conf.d/` is so that both distros and users can put configuration snippets in there to configure behavior for whatever hardware is currently installed. I use Gentoo Linux- a distro that requires that you supply your own batteries, so I supply my own config files.
> I can't get smooth motion in many applications on my machine because [I'm using NVIDIA hardware and have displays with unmatched refresh rates.]
> I'll be thrilled when ... Nvidia finally pulls its head out of its butt.
NVIDIA is okay if you're doing one of the very few things they expect you to. If you want to do most other things (like suchas have multiple displays attached to your video card that don't have exactly the same refresh rate) they are terrible. NVIDIA regularly goes off and does their own thing (usually very poorly), rather than use the thing that everyone else developed that works well.
The NVIDIA-on-Linux situation has been bad for at least twenty years. Torvalds' now-eleven-year-old "[NVIDIA is] the single worst company we [Linux developers] have ever dealt with ... NVIDIA: FUCK YOU!" remark [0] was motivated by legitimate, long-standing complaints that have yet to be resolved.
If you're using an NVIDIA card on Linux, and you're using it as a graphics display or 3D accelerator card (rather than -say- CUDA and friends) you're deliberately and enthusiastically plunging your hand and whole arm into a bag of sharp knives. It's not going to get notably better because it hasn't gotten better in the last 20+ years.
[0] https://www.phoronix.com/news/MTEyMTc
Is this saying xorg server is dead?
I don't understand - there must be virtually infinite (relatively speaking) software built around xorg.
Is there an official announcement of the death of xorg or something?
Someone can of course take up the mantle, but no one is interested and most of the Xorg team has moved on to Wayland.
That's what the sponsor of Wayland development is saying, yes.
> Is there an official announcement of the death of xorg or something?
No, because after fifteen fucking years of development, it still isn't good enough to work everywhere that xorg does. (Over those years it has also lost many of the much-touted "xorg server developers" that abandoned working on xorg to start on another project that was less awful to work on.
Well... guess what Wayland turned into? XD
xorg works, and -at least for me- most of the things that people seem to say doesn't work on it actually do [0]. Contrary to popular belief, you don't need a billion-dollar company to fund development on a piece of software that runs your application software just fine. And this isn't the fucking webdev world, so you don't need a team of twenty just to keep up with unending churn-for-churn's sake.
[0] <https://news.ycombinator.com/item?id=38455077>
So you choose a big beast to maintain because "it's cool".
And, btw, which standards do you have in RHEL ? (Some years ago fvwm was removed. The feeling at that time it was that fvwm ate to few memory, that's why it was removed)
Protocols can be versioned, there's no reason Xorg can't become more of a compositor itself.
I'd like to see someone describe ame compare building simple and medium complexity GUIs in both Xorg and Wayland. Maybe I'll do it myself if there's some interest or ideas for test targets.
Creating Wayland made it possible to do some very radical changes. When rewriting software you are much more careful to not break anything.
Apart from that the discussion is pretty much settled. Most distros and major desktop environments have commited to wayland. You'd have to have a very compelling argument to move things back to Xorg.
Most things can be improved and adapted, that is especially true of software.
I'm not convinced by what others are doing.