hckrnws
https://sourceforge.net/p/twelveto11/code/HEAD/tree/ would be a better link. It still contains the README but it shows the sources and the timestamps, nothing more recent than November 2022. I wonder if it runs apps from the last 18 months.
Furthermore, which Wayland only apps might I want to run on my X11 desktop?
Also doesn't weston have an x11 backend that can also do this? I believe KDE also has kwin_wayland.
> which Wayland only apps might I want to run on my X11 desktop?
I needed to look into this to run Waydroid[1], that's the only one I can think of.
I thought kwin_wayland was just KWin... for Wayland...
In Wayland, though, most of the compositors are also the entire display server. So you can run e.g. Mutter Wayland, kwin_wayland, weston, sway, etc. as an X11 client to varying degrees of success, and it looks and functions kind of like running a nested X server, just, with a Wayland server.
Not, strictly speaking, on the topic that you were talking about but the display server has been broken up somewhat and compositors don't implement all of it. Compositors generally can't do some core functions that the XServer did - so we end up with the compositor acting as the part of the display server that managed ... compositing, funnily enough and display. But we also seem to need other servers like Pipewire's runtime to abstract Wayland clients as shareable objects.
Yeah, that's true. Wayland is, of course, just a protocol (and some C libraries.) You can always implement Wayland compositing under a different display server or compositor, and the best example of that I am aware of is Arcan FE with its Wayland bridge.
Even core functions of the Wayland server that are in the same process as the compositor may be split out to common libraries, and of course there are several compositor server libraries for different programming languages that provide the vast majority of the base functionality of a display server implementing the Wayland protocol, notably wlroots, Qt's own Wayland libraries, and Smithay.
Wayland compositors generally also inherit large parts of what used to be the X server. Over the past couple of decades, the Linux graphics stack has massively expanded and refactored. X used to manage it all: modesetting, buffers, contexts; the graphics drivers were essentially XFree86/X.org drivers. Today, almost all of that has moved to the kernel and Mesa, in the process giving very powerful new primitives as well. It definitely came with a lot of pain, but it improved both what X.org was and what Wayland can become in the future.
Likewise for the input stack: Linux evdev expanded and improved a lot and unified the format of event data from devices, but of course drivers were still needed to handle smoothing out the differences between devices. libinput is probably not everyone's favorite, but I'd say it does a pretty damn good job considering how broad its device support is.
Pipewire is not strictly needed, but it is the defacto way to do screen capture on Wayland thanks to desktop portals. I think this is mostly because of GNOME/Mutter. The Mutter project is very cognizant about features and dependencies being put into the Mutter process itself, and seem to favor moving things out of the compositor process. Their approach to doing this in general seems to be by moving things into DBus servers, like the Desktop Portals system.
Personally, I have some very mixed feelings about this situation, as could probably be seen based on my past interactions. DBus servers can be an awkward fit for some of this functionality; desktop portals are nominally executed as systemd user services, which as far as I know are typically per-user and not per-session, which would make e.g. nested Wayland sessions trickier.
It would, of course, be possible for the Wayland protocols to handle things like this without it explicitly being "in-process", which I personally would prefer; I would prefer if the API doesn't have to map to the underlying structure of the desktop environment. I can definitely see how this is an additional burden and additional point of failure though, so I can't really claim to not understand it at all.
It also has allowed Wayland, for better or worse, to side-step the issue of authorization. Instead, it can be handled using DBus, polkit, etc. Wayland is nominally a capabilities-based system, but with the caveat that it doesn't actually have a way to authorize or authenticate anything. As far as I know, there's no protocol to e.g. "ask permission", you just either get an object or you don't.
All in all, the practical architecture of Wayland clients is... unique. I think it's pretty clear to anyone that it's a bit of a mess. Honestly, though, I am pretty happy for the groundwork that enables Wayland, as I think it is starting to bear fruit on things where there's just no way incremental improvements were going to get there. Definitely hope that some of the mess can be cleaned up in the future so that users (even power users) don't have to worry about understanding this architecture to do practical day-to-day work.
Probably yeah, I have no idea tbh. But it works for me on x11 too if you run it, and then launch wayland only programs like:
XDG_SESSION_TYPE=wayland <app>XDG_SESSION_TYPE more of a hint thought. You actually have to do something like
(export -n DISPLAY; <app>)> Furthermore, which Wayland only apps might I want to run on my X11 desktop?
Waydroid? There aren't many Wayland-only apps, but they exist.
> Furthermore, which Wayland only apps might I want to run on my X11 desktop?
A bit late to the thread but this tool is very much something I've been looking for!
I want it not so much for current use cases but as a way of future-proofing my current setup since there is little hope that I will be replace it with Wayland anytime soon. I worry that a time might come when essential libraries and tools like gtk and web browsers might remove X11 support.
I gave the tool a go and it builds easily and quickly and it was able to run what I've thrown at it so far. One of my concerns was selection/clipboard syncing but even that seems to be working as expected.
It's nice that it doesn't even depend on wlroots which can be a bit of a moving target. It only uses the X11 libs and libwayland-server so I think it should be fairly future proof.
Overall I think this is a much better solution than cage which was the best option I'd found previously.
The better question is why keep using X11, if XWayland works just fine.
XWayland works just fine for applications; accessibility/automation tools and the like are a different story. (Ex. Want to write a script that finds a specific window and sends it keypresses? You're going to use X. Want to watch which window is focused to implement per-application keyboard layouts? X. Actually, want to set the keyboard layout dynamically at all on arbitrary window managers? Somehow Wayland doesn't do that. Once I almost started using a Wayland compositor, until I discovered that it didn't actually hook up the wlroots functions for setting keyboard layout; in X setxkbmap works everywhere.)
One can run an XWayland container transparently. Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension. Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters, if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not. Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either.
> One can run an XWayland container transparently.
That still only helps for applications (unless you mean just run a whole nested X session, in which case sure but that's not really using wayland).
> Broadcasting keypresses is forbidden due to security reasons, nobody forbids patching it in as an extension.
Nobody's writing that extension, either; as a user, X does what I want and Wayland doesn't and I'm not in a position to change that.
> Setting keyboard layout dynamically is as easy as calling swaymsg with the required parameters,
That appears to be just for sway? Or at least (from testing I just did) not all wlroots compositors support it.
> if a particular window is required instead, there's a protocol for that in hyprland. It all depends whether a particular window manager does it or not.
Exactly. In X, I could use whatever wm I wanted and all the same tools just kept working. In wayland, if I want to do anything interesting I appear to be stuck with sway or maybe hyprland.
> Finally, I get that accessibility isn't best with Wayland, but it was not ideal with X11 either.
Oh sure; X is a huge pile of hacks and ugly code, but it's a working pile of hacks and ugly code, and quite flexible at that, which is better than Wayland's elegant, well designed brokenness.
Do I get to run my exotic window managers via XWayland?
There's XWayland rootfull mode, it will probably work just fine.
With the huge limitation of not being able to manage the windows of Wayland clients. This tool is an excellent solution for exactly that.
It does run recent apps as long as they don't use the new Wayland protocols. I decided against that link because there are a lot of files before the actual README.
I tried it some time ago using Qt's environment variable to force the Wayland backend but Qt crashes on startup.
Good to know this exists, so I can keep using what's been rock solid for me for the last decade for the foreseeable future.
X has security issues. For example, an application that has access to your display can do stuff with other applications.
For an interesting discussion, see: http://theinvisiblethings.blogspot.com/2011/04/linux-securit...
> an application that has access to your display can do stuff with other applications.
Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data!
Regardless of x11/wayland, the application "vim" can read (and change!) all files in my home dir. Do you also consider that a security issue?
If you want to run some weird application that you don't trust, you should run it inside a container. But that has nothing to do with display systems.
It kind of is, and it doesn't really have to do with an application not being trustworthy. It's a defense in depth approach against app that become compromised through exploiting bugs with security implications.
The attack surface of Vim is admittedly small, but the browser is a much bigger target. I want my browser to download files, upload files that I provide, and various other things on an allow list, but not more.
IDEs, the tools invoked by them, and their build artifacts should have access to the project assets and not much more.
There are certainly applications that require more privileges, but I'm sure we can come up with ways to restrict them as well. The problem is that it's quite late to retrofit it onto desktop Linux.
Containers are not designed to be security boundaries. They isolate their contents from the host system, but not primarily because of security. They can be used for security, but certainly not with default settings.
> Containers are not designed to be security boundaries.
So you'd prefer your graphics system to act as a security boundary? Seems very weird to me. Containers are clearly the right tool for this job, for they can run as well for non-graphical programs.
The graphics system absolutely is a part of the security boundary. You can pass through your X11 or Wayland server socket in the container to run graphical applications. This is more of less what a Flatpack is.
Yes, the windowing system requires such to prevent applications with less privileges spying or controlling those with more.
On X, it is possible for an exploit in a browser to gain root if you have an application opened as root.
Although such exploit would be extremely difficult to pull off, state actors will do anything for specific targets.
> state actors will do anything for specific targets.
That's either not a problem for me because I am of no interest to them. Or it is a problem that no amount of fiddling with software can mitigate because they can just beat me until I give up.
It has to be. The capabilities exposed via the X socket are way too powerful since they allow the application to mess with any other application running on that X server. There are sandboxing solutions which give each applications its own X instance, which is quite similar to the way Wayland isolates applications from each other, and shares the same disadvantages.
Usually people run all their apps unsandboxed anyways, so cool that Wayland prevents me from accessing any other app via its protocol - too bad I can just open any other process's memory via /proc, or read any sensitive data it stored in $HOME.
It's been a long time since I daily drove Windows, but I'd assume it's still the same situation over there.
I don't care. Sandboxing is annoying, cumbersome. I'm not going to create a container for every single app I run, so Wayland brings zero additional security.
If once in a honeymoon I need to run shady software I use a VM.
Of course it has to be used with another sandboxing layer to be effective.
You don't have to create a container by yourself, a good desktop will do it for you. One such solution is Flatpak. Many applications don't work that great with Flatpak yet and require quite sweeping additional privileges, but we will probably see improvements over time.
There's nothing wrong with users deciding to just have a common folder with all their data, but some applications are of more sensitive nature than others and it should be possible to secure them better. For example password managers or terminals.
What do you mean by "The attack surface of Vim is admittedly small" ? Recently I had to access a file owned by root. The IT gave me the permission to do sudo /bin/less /etc/the_file. That was enough to launch a shell with root permissions. If someone can send commands to Vim, he can launch any command and own your computer.
They're talking about the attack surface to get accidental code execution from opening files that try to exploit vim. Integrating shell commands with vim/less is a valid feature.
That was indeed a bit silly by IT. They could have written a script that gives you a copy of the file and then deletes it after you're done with it, sort of like what sudoedit does. Or just let you sudoedit that file since they obviously had no problem effectively granting you write access.
> Well, of course, that's the whole point of using "applications", isn't it? To change the state of your data!
Why do you think webbrowsers go through great lengths to isolate different tabs from each other?
In my mind, if you're running potentially-compromised code on your machine, you're already hosed and the display server isn't going to protect you.
Not really. You can run potentially-compromised code in a sandbox. X11 is unsandboxable though since X11 programs can see each other freely through the display server.
It’s been under a month since Linux patched a zero-day that made it trivial for any program to get root.
Do you browse the internet with scripts on? (Javascript and Wasm). It is fully untrusted code that runs in a sandbox.
Do you expect that random webpages are ableto steal all data from all applications you run, and all files you have? Including passwords etc.
Spectre was possible to attack from JavaScript:
I don't see how this is related to the topic at hand. A zero-day attack can be patched, but the security issues with X11 are intrinsic to the protocol itself and are nontrivial to fix.
That is not true. There are extensions to the X11 server that can resolve many of the security issues, but almost no one cares enough to use them.
If you are doing X11 forwarding via SSH it defaults to a more restricted configuration that only allows a more restricted access to the server (no direct sniffing of the input devices for instance).
Ah the binary secure/unsecure straw man.
There seems to be XACE/XSELinux, which seemingly exists in the mainline Xorg distro now. I wonder how the experience is with that?
In practice I think it doesn't see any adoption, since most people don't run with SELinux or even AppArmor on their desktop and none of the applications run isolated from each other, so it doesn't matter that they all have full access to the X11 server. And for actual security there is qubes, which solves both the application isolation and the X11 security issue.
Eh even if you secure the X11 API itself, your isolated app (browsers absolutely sandbox and isolate themselves from the rest of the system) will still share memory and have a socket open to an 33 year old c codebase (XOrg).
Not sure having shared memory and socket open to N fresh and under active feature development c codebases is that much more conducive to security? (N since while many compositors use wlroots there is still enough rope to hang yourself). To be fair, unless there is a exploitable bug in wlroots/lower wayland code, the blast-radius will be a lot more limited than if one is found in Xserver.
I think the Qubes approach is the only one worth considering if one deeply cares about security.
This post is by Joanna Rutkowska of the Qubes project (a VM based isolation system) and doesn't contain any comments in favour of Wayland. In fact I think Qubes still uses X11.
Are there any writeups that make a case for how Wayland could be used to implement robust GUI isolation?
X has support issues. For years support for anything other than XRGB8888 and siblings has been bit rotting away.
A few years ago I brought up X on a Y2 display. Ended up implementing RGB888->Y2 blue noise dithering in the driver when I realized how much work native Y2 would be.
There is at least a decade since I have been using only 10-bit color monitors and I have never seen any problem in X with them. I do not know whether you count this as a "sibling" of XRGB8888.
The only software that had problems were various installers for some professional programs, which were written in Java and which crashed immediately on 10-bit color displays.
However that was a Java problem, not an X11 problem, because the same installers also crashed on Windows when the display was configured in the 10-bit color mode.
Of course the color management in X is not good, but I have not heard yet about significant improvements in Wayland.
In my opinion, the only right way to handle color would have been for all user applications to work only in a linear wide gamut FP16 RGB color space, like Rec. 2020. Only the display driver should be aware of the characteristics of the display, like color primaries, gamma, HDR, color resolution or pixel encoding, which should be used for an output conversion in the GPU.
AFAIK, Wayland has also missed the opportunity to make such radical changes.
Java: portable bugs.
I forgot about 10bit. I should have said indexed-mode or non-true-color. I meant anything below RGB888.
Linear for processing would be nice where that conversion can be done efficiently, and where the display driver can make a passable representation.
The system I worked on only had black, light grey, dark grey, and white. What was nice about X was that the driver could express its limitations to clients, so that the client could make smart rendering decisions and handle dithering vs not dithering appropriately, rather than doing it at the display driver layer.
There's another problem: the pels in an X pixmap can be 32 bits wide, max. So while ten bits per color plane is feasible, any more is not.
Looks like we're gonna have to devise a whole 'nother display protocol to accommodate larger pixel sizes... unless...
Yes. That's often really useful, for remote operation, and screen shots/recording/sharing.
On Windows, one app can send events to another window too.
Many of those security issues are features that enable users of X to do their work. Yet Wayland supporters keeping trying to convince them to switch because of those "issues".
This is why Wayland adoption is slow.
Well, that's unfortunate. Someone should fix that. Is anyone maintaining X11, or is there continuation fork?
How can you implement accessibility tools without that feature?
By using other, more secure interfaces like uinput, or libei[1] whose access you can allow it deny separately from the Wayland socket itself.
Those only let you blindly emulate input events, they don't let you inspect, select, or control windows.
Ah for that you want to use the at-spi2 interface. This gets you access to the accessibility tree so you can not only discover and interact with windows, but also individual elements within like buttons, text fields, etc.
>X has security issues.
And Wayland is just a protocol, I would rather trust some old X11 code that was shared by entire Desktop Linux then GNOME devs code, this is my personal opinion and I will not bring forward sourced/evidence why I do not trust GNOME devs and designers.
In the UNIX-HATERS Handbook you will see takedowns of the argument that "X is just a protocol" :)
> Wayland programs will then run as regular X windows.
Well that'd be nicer than my current solution of running a whole Wayland compositor (usually cage) in a window under X. Of course, it's more work, but that is the usual tradeoff to make...
Haha, the "cure" (Wayland) was administeread in such a weak dose over so long time, that the "pathogen" (X11) developed resistance and is now immune to Wayland applications!
It was always possible to run Wayland applications via Weston, which has an X backend.
In your analogy, if you set instead (more naturally I'd say) "x11=organism" and "wayland=pathogen", then you have exactly described a vaccine!
Wayland's weak start allowed the system to develop a healthy immunity to it.
Interesting. Until now the opposite has been more popular because there weren't many apps dedicated to Wayland but that will probably change now.
I’m guessing 11 in the name is for X11, but why is Wayland 12? Wouldn’t a name like WtoX or WayToX be more useful?
2to3 made sense for Python 2 to 3, but using the same naming scheme is a bit weak, isn’t it?
Wayland is X12, sort of. In the sense that it's developed by the same people as a successor, and they've stopped working on X11.
It's much the same way that Vulkan is OpenGL 5. I've been told that's actually the reason it's called V ulkan. :)
The name change prevents a Perl 6 situation I suppose.
More like a PHP 6 situation. People where pushing a protocol specification without implementation as if it would be ready to take over the Linux Desktop within a day or two.
Can a headless app talk GLX or EGL and render on the X server's GPU?
Not to be confused with 11on12 which runs direct3d 11 apps on d3d12
Imakefile found, where a plain old Makefile could be sufficient. Yuck, another dependency on an obsolete piece of software (imake/xmkmf).
That's the X11 tool chain, icky as it may be, it is what it is.
No reason to refactor a build environment "just because"
Hey Makefiles? How quaint! You should use CMake!
Hey CMake? How weird! You should use Maven like the rest of the company!
Maven? Yuck! Why don't you simply and just use Makefiles instead of resume engineering?
Make? Sheesh how do we deal with integrating different environments? It may be crusty but imake is perfectly suited to this task.
[flagged]
I would hardly call modern X11 nicely conceived. It was nice in the 80s when everything was network transparent, X was indeed a graphic terminal for local or remote Motif apps, and everything handled by the xlib. It was then somewhat reminiscent of Rio although foreign and bolted on top of the system.
Nowadays it's just a clunky mess of direct rendering interfaces bolted on top of legacy cruft from a long gone era. It's complex and inefficient.
X11 may be clunky, but it's familiar clunky which my tools and workflows are already set up for. I paid the cost incurred by X11's clunk many years ago and now I feel too old and weary to pay it again for Wayland. I no longer enjoy tinkering so I'm going to stick with what already works for me.
If Wayland were such a great improvement overall that it didn't incur it's own clunky tax, then the situation might be different. On the contrary, Wayland is not only clunky but fragmented as well; hacks and workarounds for one compositor don't necessarily work for another, so if I switched to it I would be faced with the prospect of either figuring out numerous systems or picking one of them blind and hoping for the best.
> I no longer enjoy tinkering so I'm going to stick with what already works for me.
Absolutely feel the same way, I don't wanna work on my tools, I wanna work on my work.
I picked up Linux because I was an enthusiast. Now I use it because Windows became unusable and Linux is actually the best option on the desktop. But I don't care about X11 or Wayland, I just want things to work without fuss - and they mostly do through decades of churn and cruft. In my world legacy cruft is vastly preferable to new problems.
> [...] I just want things to work without fuss - and they mostly do through decades of churn and cruft. In my world legacy cruft is vastly preferable to new problems.
I am curious to know why you decided to choose linux over netbsd if that is your opinion.
gee, because nothing runs on it and the hardware support is deficient?
Isn't NetBSD the one people install on toasters for bragging rights, and FreeBSD is the one people actually use? Anyway, Linux has better support for both hardware and software.
> I no longer enjoy tinkering so I'm going to stick with what already works for me.
You don't really have to in practice if you aren't a tinkerer. Most distros do the whole thing for you and appart from having a smoother desktop, you wouldn't even know you are using wayland on Gnome or KDE.
In fact only the tinkerers can be annoyed by the switch because they are the ones using a non distro polished setup.
I have a small pile of hacks and utilities created in my tinkering days which I still use. I don't care for either GNOME or KDE so my desktop is a hodgepodge of various stuff; Kwin and LXQt plus a bunch of xbindkey, xdotool, tdrop, etc. From what I understand, a lot of this would need to be replaced with compositor-specific solutions if I switched to wayland.
Network transparency is good, but now it is achieved with RDP/VNC.
I like new mode much better: when you change from terminal to terminal you have all the same programs running on "server" without restart. I could work on my Windows workstation locally, go to my office, attach back to workstation and everything works, then I could go to vacation to India and connect to same workstation from my phone (!) and still programs runs without restart.
X11 model with "RPC display server" when you cannot re-attach same clients to new display server without restart or some proxies, which you need to run in advance, is not so convenient, IMHO. VNC was invented to remedy this problem. And VNC is simple pixel buffer, not high-level controls or X11 protocol in any way.
That's perfectly possible with X11 to attach via VNC to an existing session. But what X11 over (local) network does way better than either RDP or VNC is to run individual applications remotely while having them seamlessly integrate with the rest of desktop. At the observatory for example we were running thin clients in the control room while all the control panel windows were coming from many different machines across the mountain and it felt like all the applications were running locally on the machine in the control room (while in reality nothing was running there).
Yes, of course it is possible to use VNC with X11 as we use RDP with Windows. But it is additional protocol. Why do we need it if "X11 is network transparent"?
It is different models: X11 assume you have only one terminal (effectively client, but "server" in X11 parlance) and many system to run software (effectively servers, but "client" in X11 parlance).
VNC/RDP works other way around: one server, which runs all you programs, and you can attach to it from different terminals/clients.
It is not exactly so, as RDP can forward only some programs (windows) and not full screen, of course, but close enough.
I cannot speak for everybody, but for me (and my friends with whom I discussed this) second use case is much more important, than first one.
About speed: maybe, with 10Mbit Ethernet it was true. But now I could work with Photoshop (!) from my office (client) on my home workstation (server) via RDP and don't notice delays. Yes, I have 1000/100Mbit asymmetric connection at home and I don't know what is used by my office. One time I've forgot that it is RDP to my home sysmtem and started Youtube video. I was surprised, that video and sound is slightly off-sync, and only after that recognized that it is RDP, not local browser!
Much worse connection is enough for less demanding tasks, I've worked with "normal" not graphics-heavy programs via 4G connection in India (my home system is in the Netherlands) and it was not painful. Yes, there was perceivable delay, but for task like "Open PDF, open browser, fill form on site by copy-n-pasting strings from PDF, submitting form and authorize with 2FA from phone" it was perfectly Ok.
But, yes, if you need to assemble 10 windows from 10 remote machines on one screen, X11 is the best.
That is a bloody lie. Nothing on X feels like it's running locally except for actually locally running applications. String an Ethernet cable across the room, and run X apps remotely over it, and you'll get lag and chug.
RDP actually delivers on the promise of local-feeling remote apps.
(The revenge of the UNIX-HATERS is that Microsoft designed a better shell than sh (PowerShell), a better X than X (RDP), and a better Emacs than Emacs (Visual Studio Code).)
Maybe the problem was with your specific setup or applications? Because at the observatory it worked flawlessly. Between the local data reduction machine (beefy server) and the desktop computer in my office the same. And I used that setup for years and it worked just fine (and I really really hate any lag or glitches).
VNC really sucked on the other hand, not being able to transparently share single windows (at least I never figured out how to), some windows would fail to refresh and I would need to drag them around to get them to redraw, copy and paste was always a pain, sometimes inputs not registering properly.
To be fair to VNC though, over the internet plain X11 forwarding really sucked (latency is the real killer here) and VNC won out there. Unless one was using NX proxy, then it blew VNC out of the water (while using X11 on both ends). Only RDP was somewhat on par with NX over the internet, but locally still beaten by X11.
X11 with modern frameworks passes only damaged bitmaps too... No local font rendering, not vector primitives.
And for me inability to detach whole session from one server (in X11 terms) and attach to another is showstopper.
X11 needed something like console "screen"/"tmux" from the very beginning, in the core protocol, IMHO. Not for multiplexing of workspaces or desktops, but for this session re-attaching.
It is and will be increasingly adopted by major distros as default so it is nowhere near ipv6. Also unlike ipv6 you don't have to wait for others to be ready, your computer using wayland doesn't have any impact on other computers running X11.
After several attempt of trying it. It is still bad. Games works worse with it. So many quirks that will never be fixed because "This is by design" mindset is screwing desktop Linux's progress. They should as well give up and maintain X11 ,keep the same architecture and rewrite it with modern software development practices.
The argument that it is ‘screwing desktop Linux’s progress’ doesn’t hold well in light of the success of the Steam deck- selling to millions- and running a Wayland compositor. Which ‘non-wayland’ efforts have been thwarted, that had any such numbers?
Wayland works well on the Steam Deck because Valve controls the whole system. Because they have their own Wayland compositor (Gamescope), they're able to implement protocols to work around issues in Wayland without being delayed by the bureaucratic process of getting them approved. Here's an SDL pull request where a graphics developer at Valve discusses how two protocols necessary for good GPU performance haven't been added to Wayland yet so Valve added equivalent protocols to Gamescope as a workaround: https://github.com/libsdl-org/SDL/pull/9345
One thing to note is that the Steam Deck only uses Wayland for its fullscreen gaming mode. When you exit to its desktop mode (meant for running non-Steam software), it switches to X11.
The default will change to Wayland soon because Steam Deck runs Plasma. Plasma 6 defaults to a wayland session.
Comment was deleted :(
But the Steam Deck is hardly desktop Linux. The users there usually wouldn't care less that you can't use it for desktop-y things (like taking screenshots...).
E.g. Linux mobile devices also usually "successfully" utilized Wayland, but failed big time in market share against whatever Android uses. The only thing this may prove is that Android is more popular.
Sure, you wouldn’t call the Steam Deck a Desktop. However as you pick apart its software stack, you’d be hard pressed to find a few parts that don’t also benefit the Desktop usecase. Valve delivered a device that mostly just works for gaming, and the improvements they’ve invested in also benefit Desktop users. I don’t own a Steam Deck, but I am a decades-long Linux desktop user, and Valve‘s success thrills me.
Btw I take screenshots often w gnome+wayland, it just works so I don’t even know how it’s implemented. Not sure if you were making a Wayland jab.
Comment was deleted :(
Wishful thinking: nobody is volunteering to maintain X, let alone rewriting it from scratch, along with its architectural deficiencies.
Wayland is what happened when the Xorg maintainers got sick and tired of maintainting Xorg. They're not going back. Xorg is being led behind the barn to be shot. Wayland is the future. Deal with it.
Nobody is maintaining X. Previous X developers are the developers of Wayland. Wayland is a X.org Foundation project.
> devoted advocates and fans
The loyal opposition seems vastly more vocal & adamant. Endless haters, endless griping, endless whining, while a lot of people are doing just fine & getting along & getting on with things.
Crafted by Rajat
Source Code