h2-1 thank you for taking the time to spell everything out for the folks who haven't taken the time understand what is what and folks like me who continue to get mixed up dispute our better efforts. Great post!

What everyone needs to realize here is that nobody is going to take up X.org beyond basic, fix-what-I-have-to-so-it-builds anytime soon. Just like 'it works well enough' is barrier to Wayland adoption it is also a hurdle for forking X.org. I don't think the FOSS community would be really excited about a third competing graphics stack anyway. Nobody really wanted that when X.org came about either, I don't recall all the details anymore but the Xfree86 -> X.org was more a coup than fork, with almost all the active developers moving over to the new project. I think there were things like quorum rules and a bunch of folks were basically non-responsive so fix was just stand up a new organization and name new leaders IIRC.

This is just going to resolve one of two ways from what I can see. Either the support for wayland as a backend will mature and everything will eventually move over; or the project will just sort of run out of steam and however reluctantly the folks interested in doing UNIX display stack will move back to developing X.org with all it warts. Right now if I had to guess Wayland will be the path forward the big DE's have migrated or at least hit parity as far as support, RH and Ubuntu have moved over to it being the default. That is a lot mind share. For the most part on the application side things written to QT or GTK are not hard to port/remove X dependancies. As I sated before I am in no hurry to switch; but I am betting Wayland is the future.

Some of our truly ancient apps, athena/xt stuff you might still be running probably isn't coming along for the ride. If its important now is probably a good time to find something to replace those that use GTK/QT and is actively maintained even if you don't see migrating off X.org anytime soon.

3 members found this post helpful.

Until Wayland has composer-independent support for screensavers and root-screen-lockers it's a week late and 20 dollars short. Because I have yet to see any advantage wayland gives over X11 besides being new code.

4 members found this post helpful.

It was mainly over a licensing dispute, a not very open development model and the expulsion of Keith Packard.

Oddly the xfree86 website is still up, with informatin on the next planned release in 2009: http://www.xfree86.org/releases/releaseplans.html

It seems time stood still there.

Why not put that support IN the compositor or IN the screensaver instead? Is that not where it belongs?

hazel, if that happens, let me know and I'll update that post with proper references and links. I am astonished that I actually remembered what DRM stands for correctly, lol, but I have read a lot of the docs on this. Doing these also helps me because it forces me to try to verbalize in coherent order the random stuff I have to learn to add wayland support.

Pixxt, re screensavers, I totally agree, and you are actually highlighting an issue KDE and Gnome devs also have had, which is deciding stuff people like and use is not needed because... well, their architecture breaks that stuff because it was not considered when designing the core architecture.

A proper wayland post would list core issues, with initial issue request date, and final delivery live protocol spec dates, coupled with specific compositors attempt to supply this needed feature before wayland protocol did.

I forgot a few key items, specifically the worst, most amateur development error imaginable, throwing a new protocol out into the world without specifying and designing compositor agnostic core tools to get debugging data for user bug reports. I have NEVER found, for example, a gnome-session or kwin_wayland or enlightenment CLI wayland debugging and data collection tool (like glxinfo, xdpyinfo, xrandr suite). I look maybe once a year, give or take.

When you create such timeline, what you find is:

• Constant feature request, not really a feature, a core requirement: fractional scaling, particularly critical for super high resolution screens (what apple calls 'retina displays', with many pixels per inch/cm, and > 1 physical pixel per display pixel. I believe it was only last summer that was finally added, though several compositors had added an incredibly absurd workaround of basically lowering the resolution, then cutting it by an integer (like changing 1x to 3x then dividing by 2 to gert 1.5x, which meant slow, slow slow since it had to do two trips through to create the illusion of fractional scaling. This was a "won't fix" item for years. It meant the devs did not have retinal displays, basically, otherwise it would have been designed in.
  
• Basically current issues with Wayland, as of today:
  Jun 10, 2022: https://dudemanguy.github.io/blog/po...land-xorg.html [that's the guy who got commit rights to wayland, used sway compositor, etc, see where wayland support was at less than 2 years ago]
  I'll just add the section headers, but it's well worth a read if you want to get basically a developer's perspective based on working in wayland project:
  • Wayland Isn't Going to Save The Linux Desktop
  • What even is Wayland anyway?
  • Wayland's client API is gimped.
  • Wayland's lack of feature parity with Xorg cripples it.
  • Wayland's render loop design is ridiculous.
  • Wayland's Mesa implementations are leagues behind Xorg's. [this one honestly really surprised me, I had believed that OpenGL was legacy, and EGL/Vulkan would be getting all the work, and be the ones leagues ahead. This registered strongly with me because I'd just been adding EGL and Vulkan display API support to inxi, and I can tell you for sure, the people who wrote the docs about EGL and Vulkan wrote as if they were already far advanced, and those docs were certainly written some years ago, that is, current with this blog posting]
  • Wayland itself has bad core decisions. [see no ability to run a screensaver]
  • Was it really worth it?
  Aug 29, 2023: https://blog.jetbrains.com/platform/...yland-support/ [big problems with xwayland/compositor fractional scaling]
  Nov 23, 2023: https://discourse.gnome.org/t/any-ne...-scaling/18163 [this is only 3 months ago!! Gnome!]
  Jan 24, 2024: https://gist.github.com/probonopd/9f...ent_id=4815737 [Think twice before abandoning Xorg. Wayland breaks everything!]
  
• Note: damentz of Liquorix pointed me to this quite recent posting, and it's important to see where various views focus when it comes to Wayland/X.org, then to see where your own personal workflow intersects with those views:
  https://pointieststick.com/2023/09/1...wayland-thing/
  this is a KDE dev I believe, and keep in mind, KDE is probably, along with sway, the furthest along when it comes to actually shipping a fully functional wayland compositor:
  • So let’s talk about this Wayland thing
  • What is Wayland?
  • Why does Wayland exist?
  • Why did X die?
  • How is Wayland any better?
  • Wait, that sounds like it sucks
  • Yes, but there are solutions
  • Why is the adoption taking so long?
  • “Are we there yet?”
  • Which brings us to Fedora KDE
  • Putting it all together
  But I want to remind, this is NOT about Wayland, this is about KDE's implementation of a wayland compisitor. The June 2022 article was about the actual Wayland protocol status in 2022, so it's not like one is right the other wrong, which is one reason talking about Wayland/x11 is so difficult, with x11, we are always talking about X.org, but with Wayland, we are talking about a specific implementation in a specific compositor.
  
  I recommend reading the comments under the article, one in particular raised an issue I forgot, wayland protocol support is built into the toolkits, so with latest Qt or Gtk, and I think ELF for enlightenment, if your gui program uses that toolkit, it's already got native support without the dev doing anything. As long as it's built with current version of toolkit...
  
  There you can see that not even the KDE developer guy is able to keep up with what is going on, as some comments point out, so it's not surprising that non devs/regular users can barely even get their head wrapped around this stuff. Very poor messaging, to put it mildly.
  
• So there has been NO DELAY at all, what there has been is very poor handling of issues, poor sense of what real users require as a base / core functionality in modern display compositors.
  
• The screensaver issue if you have a good memory had a similar issue in kde 4, the devs created their core virtual desktop architecture wrong, and it did not support different backgrounds per virtual desktop due to the flawed design, and they kept rejecting valid requests to add different backgrounds per virtual desktop, but the problem was, they designed the desktop architecture without considering what people, aka their users, actually wanted and liked.
  
  I am in the camp of liking screensavers (and different backgrounds per virtual desktop) too, even though I know they are a legacy from CRT monitors, to prevent line burn in, but they are nice, and pleasant. Telling people that what they like and want is not a real thing is a very bad design and developer culture action, and it's not how you make good progress. They failed to design the spec to handle something that is very nice and that people like. That's all. Then you get into stubborn developer defensiveness, plus maybe some core design errors in the protocol which made what should be trivial and easy hard.
  
  I was and remain absolutely astounded that a guy like Keith Packard, I believe the original wayland spec designer, could make such totally amateurish mistakes when trying to introduce a fundamentally new and certain to have major adoption issues protocol, that made me really question his project lead abilities.
  
  Note that I always know when an internal inxi refactor was good because it instantly uncorks new features that were hidden before due to bad coding and poor internal architecture. And most important: it NEVER breaks existing features or functionality! This is kind of basic programming. The correct wayland response for that should be: oh, damnit, we just forgot that, we may have to upgrade some stuff to get that working, sorry about that, we'll work on it, thanks for the nudge.
• For those counting, apparently KDE has best large DE wayland compositor, GNOME is significantly behind and may not be fully ready for prime time, which is honestly no surprise, and I don't know where Enlightenment is at, or Budgie. Most other DEs are spins of GNOME essentially so those will basically just be what GNOME is with gnome-session. I tend to trust damentz of liquorix kernel, and he said he switched to kde wayland about 1 year ago and likes it, so my feeling is many core issues have been resolved, at least enough for his work flow.
• I believe KDE 6 is dropping x11 support. That would mean they are dropping kwin_x11 compositor/wm. I am not sure of this, but that is what I hear/read. I find this bizarre, and I'm not totally convinced this is true. GNOME is on same path, but I don't know their timelines.

I would add however that apparently there was really huge progress between that June 2022 blog posting and now, which is why they are pushing so hard to get it out in fedora as default. A default that has been tried several times over past years, Ubuntu tried it, and immediately pulled it when they realized wayland or rather gnome/kde wayland compositors were not even remotelely close to ready for prime time. Maybe 8 years ago? I forget.

But the key takeaway should be that due to fundamenntal project design errors, wayland protocol is NOT behind schedule, the marvel is that it's even trying to ship today as default, and that it even got to this point in the first place, so its not late, it's still quite early. I have no plans on switching until the xfce devs determine it's ok, I view the xfce project as quite similar to Slackware with Volkerding, they don't rush, they go carefully, and don't shove junk that doesn't work down user throats, which is why I use xfce or light wm only now.

6 members found this post helpful.

_blackhole_ if I remember right, OpenBSD shipped XFree86 for a long time, in fact, I remember being surprised to realize they had finally moved to X.org a few years back. There's talk of Xenocara being their X.org fork, but I find it hard to believe that the roughly 50 core devs of OpenBSD would possibly take on that type of project, and I've never seen any sign of their X.org default x11 display server being anything other than X.org. They do have xenodm, which is kind of an xdm fork. But that's the only hint of the Xenocara project I can find there. When they forked OpenSSL into LibreSSL and fixed it, it's libressl, not openssl, so I suspect that the OpenBSD project had to be realistic about their limits, and maybe just add in some security stuff like Pledge into X.org when they build it.

chemfire good points, and good history reminders, it's very hard to track all this stuff, so having all the bits out there/here helps. But I hope I'm not creating the wrong impression, Xwayland is going to be around a LONG time, and in theory your old x11 only programs will continue to work on it, them being old, and x11 protocol not aging, and Xwayland basically already being a few versions ahead of X.org (they used to be the same version a year or two back)
Note that Xwayland just dropped the '1.' of X.org version. So they are already 2 full versions ahead of X.org.

So in terms of a future move to Wayland, if you use and depend on specific x11 programs, they will keep working, just via the Xwayland layer. As someone upthread also noted, don't bother trying to run your x11 wm via Xwayland, that's not going to work well, think of Xwayland like a single window VM from virtualbox, where the vm appears to be a single program window. I think the main issues with Xwayland (but I'm rusty here) have been integration with the compositor environment, that is, getting the x11 program to 'just work' and feel integrated roughly speaking into the compositor environment has not been easy, see the 2 full Xwayland version bump for an indication of how difficult that has been.

For Xwayland, trust your own personal direct experience, not what other people say, I stopped using WINE years ago because no complex, or even simple, program, I ran in it worked right, so it didn't matter what the WINE project said, the stuff didn't work in my real world. So test and trust yourself when it comes to your x11 programs working or not.

2 members found this post helpful.

Well, Wayland doesn't run as root, is one big advantage. I suppose that has to do with the fundamental approach to how things are done and how the graphics stack work. There is a workaround to not run Xorg as root, but that's not really a solution.

You think about it.. How do you actually do that.. It's another approach completely to that of Xorg. And if you really want to think about it, Xorg has full access to your hardware, like keyboard and mouse, and it it written to make it secure to use it. but if it is somehow compromised, it's a big issue.

Personally I've been more into looking into fundamental security for awhile than the graphics stack, and I know we all liked to think GNU/Linux was fundamentally secure in its approach, but that's not true, in many ways it was/is fundamentally insecure in several big ways. Why do you think things like containers are so popular right now?

Could you explain to me why this is an advantage to anyone since, when not disallowed, it is merely an option most never employ? Many don't even realize it IS an option.

FWIW this is a deal breaker for me because upon early moments after a new install, I routinely disconnect all networking and launch Xorg as root and set appearances to a unique style so I instantly recognize when I choose to be root in X. Then, rather frequently, I will use "kdesu dolphin" when I have multiple administrative edits to accomplish or need access into the /root directory. Nobody has access to my PCs but me, so I don't see root lockout as beneficial. One of the main reasons I choose Slackware, and have for 20+ years, is options for power users. It seems to me Slackware requires one to be an Admin. Locking that out anywhere seems anathema to me.

It seems to me one more step in taking control away from the owner of the PC and allowing someone else to have permissions I can't have. I have to ask, just like I have to do with Microsoft or Apple, who owns "my" PC? Sorry, but "It's for your own well being, (sotto) moron." doesn't cut it.

3 members found this post helpful.

Of course, it's okay if you stay away (=never connect to the internet). Otherwise, it's just an opportunity to steal your valuable data.

My valuable data lives in /home/$USER. You don't need root to access ssh keys, gpg keys, and any information people put in $HOME/Documents that could potentially be used for identity theft, extortion, or blackmail. You can even install a keylogger to some hidden folder in .local, modify the user's $PATH without them realizing, and steal passwords.

1. Theft, in its most common form does not require root access.
2. Escalation to root is used for escaping any permissions that prevent the infected user from touching the rest of the system. This is mostly useful for servers (where X and wayland are not needed) where the target data is held by a different user or for establishing persistence in the system firmware.

Complaining about the X server running as root on a single-user desktop system is pure FUD. There is very little to be gained by breaking out of an end user's home directory with the only exception being those users who are in positions of authority or leadership and may be targeted specifically. Those people know who they are and are already taking additional measures to protect themselves.

You created an opportunity for people to steal all the data stored in /home/user the moment you logged in as "user", opened a web browser and connected to linuxquestions.org.

2 members found this post helpful.

Isn't OpenBSD's xenocara aiming to get x-windows as rootless?

No idea. I'm not saying running X as root isn't a security issue, I'm just pointing out where it lives in the ocean of exploitable software. That said I have worked for a company where this level of paranoia is relevant. Maybe this is one of those problems wayland fanboys are referring to when talking about how hard it is to maintain the X server.

I understand this mentality, having mainly used DOS & single user Windows through the 1990s. The whole multi-user/security aspect of Linux was a significant part of the learning curve for me.

But I think you're looking at it the wrong way. Let me explain:

At first, I was trying to do everything as root, and to a certain degree Slackware seemed to facilitate that. I read a ton of forum posts about not running as root, and why it shouldn't be done. It took some time, perhaps several months to switch from using root for everything, to an unprivileged user account. And that's how I've been operating for more than 2 decades now. Not because I'm a masochist who is into self-disempowerment... but because I want the highest level of security I can have, and that is only truly available in Linux if you operate from within an unprivileged user account. Users are separated from admin/system on every level, including in memory. root can overwrite system processes, where users cannot. Errant processes cannot take control of the whole system if you're running them as a user.

With all of that said, while I don't use it for anything outside of system administration, I certainly do not disable the root account. All system-admin tasks are done at the command line, so I don't even have a GUI set up for root. I'd consider the fact that Wayland doesn't need to run as root to be a good thing.

2 members found this post helpful.

is just plain wrong. It's only good for explaining why you're ignoring your own safety.
Escalation to root is used to collect everything which is possible (accessible). Including your forgotten old temp files, password databases, excel sheets, personal videos or whatever is there on your network. Granting root access means everyone can look around. Yes, some data can be stolen without root access, but if you want to make sure your personal data can be stolen then don't restrict them just use root.

Just FTR I did not move from DOS to Windows. Other than simple DOS Shells like PcTools PcShell and Midnight Commander, my first real GUI based OpSys was OS/2 2.1. It was networking capable by default and a Multi-User environment. 2.1 didn't have sophisticated permissions (though it did have rather potent Extended Attributes) but introduced in Warp 3 and fully capable in Warp 4 and downright awesome in WSeB, I broke the "always root" habit quite early.

With Slackware I login to Runlevel 3 as root every time, do a few routine checks and possibly handle planned maintenance and additions, and then launch SDDM where 99.9% of the time I login as User. I don't think I used sudo more that 3 times for all of 2023 but I did at least weekly find reason to launch Dolphin with kdesu where I find it more convenient when I need or might need to check and possibly edit configs. One common example is handling .new files from "slackpkg upgrade-all". It's just faster to have them all at a single or at most 2 clicks away than to scroll and type 3 keypresses to get each one ready to edit. I love VIM but I don't find it as quick and convenient as "rt.clk > Kwrite" when I have multiple files to edit, often in the same directory or close by.

So I would edit your last sentence to say "I'd consider the fact that Wayland doesn't ---- -- allow running as root to not be a ---- bad thing for my workflow". It is for me and I don't see how it inconveniences anyone that doesn't wish to use the option, so why make it Law?