Xorg development effort slowing in favour of Wayland
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Wayland is easier to write for than X.ORg, but it does need a lot of documentation effort to make that clear. Also, Wayland is still improving, which means changing. For compositor development that is mostly not an issue, but once in a while....
I was doing some testing and wanted to fire up fluxbox today, and I thoughtlessly did that the same way I would back when I was using XFree86: fire up Xnest and run a new X session within my current one. Only after testing did I realize I had started and ended in WAYLAND! I had run an X session under a Wayland session and it all just worked! I mean HOLY COW!
IF I was worried at all before, I am not now. The desktop guys got this, and are getting it right!
I was doing some testing and wanted to fire up fluxbox today, and I thoughtlessly did that the same way I would back when I was using XFree86: fire up Xnest and run a new X session within my current one. Only after testing did I realize I had started and ended in WAYLAND! I had run an X session under a Wayland session and it all just worked! I mean HOLY COW!
IF I was worried at all before, I am not now. The desktop guys got this, and are getting it right!
I did similar with mate, and it all worked. XFCE is on 4.18 right now. They're going to Wayland on 4.20, but will retain compatibility (after some discussion).
Is changing over as simple as changing the /usr/bin/X symlink to wayland?
I did similar with mate, and it all worked. XFCE is on 4.18 right now. They're going to Wayland on 4.20, but will retain compatibility (after some discussion).
Is changing over as simple as changing the /usr/bin/X symlink to wayland?
I am not using SLACK or anything slackware like for my testing.
Running Manjaro Plasma I use a logon manager that has room for me to enter my name and password, and a radio button that selects the desktop (I started with Plasma and added Fluxbox). When I installed all of the Wayland packages it changed the prompts to PLASMA (X.ORG), FLUXBOX (X.ORG), PLASMA (WAYLAND) allowing me to select the one I want at login.
I specifically wanted something that allowed that choice because I did not TRUST Wayland. I was right, it was several updates later before it got so solid I could use it for my daily work,
What we need is someone running slackware daily who has converted to Wayland or can select Wayland or X.Org at login so they can tell you how to get there.
Note: Manjaro runs, like ARCH, pretty cutting edge versions of things. Slackware is more conservative. Better if we find someone who is running VERY recent versions so their experience is predictive in setting your expectations.
Hmmm. Then do you have an extra platform where you can do an new install for testing and playing?
I have one I could lend you, if we lived close enough together. Alas, we live FAR apart!
I have a laptop which I retired. It's running Slackware-Current from the end of last year. I also have disk slices with Devuan and the Windows I was burdened with in buying this pc. I figured someone might want it someday. I have some techno-phobic friends & acquaintances.
All window managers seem to be readying themselves for wayland. Mate, for instance can handle wayland with everything except Mate-desktop. Slackware has wayland in KDE - everything else uses Xorg. They offer KDE & XFCE. XFCE will be wayland compatible soon, but I'm sure they won't drop Xorg.
I have a laptop which I retired. It's running Slackware-Current from the end of last year. I also have disk slices with Devuan and the Windows I was burdened with in buying this pc. I figured someone might want it someday. I have some techno-phobic friends & acquaintances.
All window managers seem to be readying themselves for wayland. Mate, for instance can handle wayland with everything except Mate-desktop. Slackware has wayland in KDE - everything else uses Xorg. They offer KDE & XFCE. XFCE will be wayland compatible soon, but I'm sure they won't drop Xorg.
Wayland (latest code) deals with NVIDIA better. IT also solves the issue of the compositor corrupting the display, sometimes freezing X.org or making it unusable until a refresh. Coding for Wayland is far easier to do correctly than coding for X.Org. If those things are not important for you then there is no reason to jump on Wayland if your preferred desktop is not ready.
I would expect that it will not take the XFCE very long to do the conversion, those are nice guys and they have good help. It is perfectly reasonable to wait for that.
If you have an extra drive you can swap into that spare laptop and load with Slackware, Wayland (WITH XWayland mind), and Plasma I think you will find it interesting. If not, there is no rush unless you love to experiment (as I do). They will both be around when your favorite desktop is ready.
Thanks. I'll go to Wayland when it's easy. Maybe a year's time? I did have one Nvidia card in a 32bit box, and rebuilding the drivers every time I changed kernel was a real PITA. I didn't like the fact that they had no respect for Open Source at all. It would cost them very little to throw the guys doing nouveau a few commits, or a few headers. Instead, they treated them like enemies or competitors.
For the laptop, I foolishly accepted an Intel HD4000 IGPU, but got a 17.3" screen, which was important at the time. Doing the sums, it was 5W of GPU . AMD was at their nadir(2012), with uncompetitive and overpriced CPUS and still sucky GPUs on massive fabrication - 40nm or something. I was reluctantly driven to Intel. Now I'm on AMD all round again. So Nvidia doesn't worry me.
All window managers seem to be readying themselves for wayland.
You seem to be missing a qualifier before window managers, e.g mainstream or actively maintained. Window managers with no apparent movement towards wayland: stumpwm, twm, fvwm and I suppose a great many others.
Perhaps of help to people porting (rewriting really, right?) their own wm efforts is this online book by Drew DeVault, author of sway: https://wayland-book.com/
I also discovered (maybe others all know this) that libegl can be best thought of as an opengl library that doesn't require Xorg. I don't know why I puzzled so over what this dependency is but it seemed not so mysterious to me reading it put this way here: https://github.com/malcolmstill/cl-egl
So how does it work? The compositor (and clients?) call opengl routines to render raster buffers that it combines and sends down to the DRI kernel drivers?
Once I'm done re-reading Oliver Jones's Introduction to the X Window System and have tweaked my twm fork in more satisfying ways I'll have to start reading Drew's wayland book. Maybe he'll have finished it by then and maybe wayland will be closer to ready.
Wayland is easier to write for than X.ORg, but it does need a lot of documentation effort to make that clear. Also, Wayland is still improving, which means changing. For compositor development that is mostly not an issue, but once in a while....
You might be right on the first point you made, and you definitely are on the second. Still, by looking at the number of dead projects floating around I seriously doubt that writing a WL compositor is easier than writing a Xorg WM: this about Way Cooler[1]; read what the wlstem developer wrote[2]; wltrunk seems to be dead[3]; waymonad definitely is.
I've spent the last weekend trying to write some code, using the wlhs haskell binding, with absolutely no results.
This is what the main developer writes about the wlhs haskell bindings: "I’m surely tempted to write the relevant C code and include it directly in the low-level bindings, because otherwise it looks like they’re completely unusable."
It doesn't look like, it is. Even though they have been spending more than three months, still the code is unusable, and I doubt it will be in the near future.
Anyway Sunday evening I gave up: I closed all my browsers tabs with all the documentation I could find, closed by emacs buffers and, in despair, I started googling "Why writing a Wayland compositor is so difficult?"
And than an epiphany... I found many references to a project I never heard about before...
Yes, I found Arcan. I immediately installed it (there is even a sbopkg build script) along with durden and... I was blown away...
So Monday I decided to start writing the Haskell bindings to its shared memory interface and in a couple of days I was able to code a client for it. I also started sharing my code...[5]
Arcan comes with a Wayland (and Xwayland) bridge (which is supposed to be crash resilient [6], something really useful judging from my experience of running kwin_wayland in qemu), the API is very well documented and writing code (Lua or C -- and hence Haskell) for it really straightforward.
So, yes, there are alternatives and I do not despair I will be able to code my way into this brave new world. Still I think that decisions on crucial digital infrastructures are political in nature: we are build the space into which we are living an increasing amount of our social experiences. I'm not suggesting that this is done on purpose, but it is a matter of fact that only big organizations will be able to produce usable desktop environments, something we have already seen with web browsers, and this is not going to be without consequences. The whole FOSS stuff was meant as a liberating tool for ordinary people. My impression, instead, is that we are moving towards monopolies of digital assets. Maybe this is inevitable, but the possibility of reading the code you are using -- who reads code apart from some lunatics like me? -- doesn't have anything to do with freedom.
Wayland is easier to write for than X.ORg, but it does need a lot of documentation effort to make that clear. Also, Wayland is still improving, which means changing. For compositor development that is mostly not an issue, but once in a while....
You might be right on the first point you made, and you definitely are on the second. Still, by looking at the number of dead projects floating around I seriously doubt that writing a WL compositor is easier than writing a Xorg WM: this about Way Cooler[1]; read what the wlstem developer wrote[2]; wltrunk seems to be dead[3]; waymonad definitely is.
I've spent the last weekend trying to write some code, using the wlhs haskell binding, with absolutely no results.
This is what the main developer writes about the wlhs haskell bindings: "I’m surely tempted to write the relevant C code and include it directly in the low-level bindings, because otherwise it looks like they’re completely unusable."
It doesn't look like, it is. Even though they have been spending more than three months, still the code is unusable, and I doubt it will be in the near future.
Anyway Sunday evening I gave up: I closed all my browsers tabs with all the documentation I could find, closed by emacs buffers and, in despair, I started googling "Why writing a Wayland compositor is so difficult?"
And than an epiphany... I found many references to a project I never heard about before...
Yes, I found Arcan. I immediately installed it (there is even a sbopkg build script) along with durden and... I was blown away...
So Monday I decided to start writing the Haskell bindings to its shared memory interface and in a couple of days I was able to code a client for it. I also started sharing my code...[5]
Arcan comes with a Wayland (and Xwayland) bridge (which is supposed to be crash resilient [6], something really useful judging from my experience of running kwin_wayland in qemu), the API is very well documented and writing code (Lua or C -- and hence Haskell) for it really straightforward.
So, yes, there are alternatives and I do not despair I will be able to code my way into this brave new world. Still I think that decisions on crucial digital infrastructures are political in nature: we are build the space into which we are living an increasing amount of our social experiences. I'm not suggesting that this is done on purpose, but it is a matter of fact that only big organizations will be able to produce usable desktop environments, something we have already seen with web browsers, and this is not going to be without consequences. The whole FOSS stuff was meant as a liberating tool for ordinary people. My impression, instead, is that we are moving towards monopolies of digital assets. Maybe this is inevitable, but the possibility of reading the code you are using -- who reads code apart from some lunatics like me? -- doesn't have anything to do with freedom.
I heard a lot of similar negative stuff about rust when devs started using that.
But recently enough, google surveys revealed that their rust devs were twice as productive as their C/C++ devs. I'm don't code, but had to do an Assembler program as part of a hardware project. The guys I tried to farm it out to ran away . So I went through the learning curve had a headache for a month, and wrote and tested the thing really in 2 weeks of part-time work. A subsequent test program went together inside an hour. Wayland might be a tough learning curve due to poor docs. Ever read the pppd info page? Or if you really want suffering read the pppd HOWTO.
What I'd also like to know is: what is the relationship (if any) between plasma & wayland?
Last edited by business_kid; 04-27-2024 at 09:40 AM.
I heard a lot of similar negative stuff about rust when devs started using that.
But recently enough, google surveys revealed that their rust devs were twice as productive as their C/C++ devs. I'm don't code, but had to do an Assembler program as part of a hardware project. The guys I tried to farm it out to ran away . So I went through the learning curve had a headache for a month, and wrote and tested the thing really in 2 weeks of part-time work. A subsequent test program went together inside an hour. Wayland might be a tough learning curve due to poor docs. Ever read the pppd info page? Or if you really want suffering read the pppd HOWTO.
What I'd also like to know is: what is the relationship (if any) between plasma & wayland?
I can't believe this conversation is going on, but given that a wayland fanboy keeps bumping the thread maybe this is to be expected.
With X, everyone uses the reference X server. There are other special purpose X servers, but they aren't super popular outside their isolated use cases. So on every distribution, the X server is launched and after that, a script is called that launches the client application. KDE's plasma desktop and fluxbox, etc, are examples of clients launched in this way.
But with Wayland, the official reference display server (called a "compositor") isn't seeing any major development. So every Desktop Environment ends up implementing their own wayland compositor. So instead of launching the server and THEN running plasma, you just run "startplasma-wayland" and it implements both the server side and client side. This means that performance and functionality varies from one desktop to the next. From what I'm hearing, KDE's implementation of wayland is currently the best in terms of performance, with GNOME being a close second.
So when running in wayland mode, plasma is the display 'server'.
On the subject of "why do people resist learning it", that should be obvious to any non-troll. People write code because they want to, not because they have to. This means that when certain individuals start making statements that are obviously not true, people will avoid the project regardless of whether or not is a good idea. For the past 10 years I've been seeing people saying that "wayland is ready" and "we should all switch because it works just as well as X" but time and time again, they are forced to accept that wayland is not finished, still WIP, and not quite on par with X. @wpeckham clearly wants everyone to get on the wayland bandwagon, but every time he lies he pushes people away. Seems counter productive if you ask me.
...What I'd also like to know is: what is the relationship (if any) between plasma & wayland?
There is no direct connection. The KDE team just jumped to the lead on coding KDE for Wayland compatibility before anyone else got there. Right now KDE PLASMA is leading the pack on Wayland, but it is no longer the only good option. The others will catch up in time.
...the official reference display server (called a "compositor") isn't seeing any major development. So every Desktop Environment ends up implementing their own wayland compositor. ...
Slightly misleading. There is no Wayland Compositor directly. One of the issues with X.Org was that there were many code portions to support and link with compositor behavior, so that part of the code for composition features lives in the display server and the rest in the compositor itself. This made things messy, and a bit wonky. (WAY wonky to code around or test. LOTS of "special cases" that are out of your control.)
Wayland breaks that link. There is a (comparatively) simple API for the compositor interface, and the compositor must do ALL of the lifting for its own features without that targeted 'help' form the display server. This makes things cleaner with fewer places to break, but it does mean the compositor teams have coding to do to refit from X.Org to Wayland. This also makes "reference display server compositor" a term that does not really apply. It is not getting work because, under Wayland, it kinda does not exist!
There are some very good things about that. For one you can swap in any Wayland compatible compositor for any other if you prefer its behavior! Even run two together if you manage them so they do not conflict!
One BAD thing is that if you REALLY like an old compositor that is no longer supported it may work fine on X.Org but never on Wayland. I have no way around that. The ones I like seem to work with XWayland well enough for now, but that is no guarantee for the future.
Luckily the compositor teams for currently supported projects are all pretty good, and are doing the migration or spawning off a new compositor just for Wayland.
Also, we have some new desktops that are Wayland only that are very interesting.
(No specific recommendation, they are popping up faster than I can test them.)
And, again, there is nothing wrong with staying on X.Org if you have any reason to want that. IT is not going away any time soon and there are now Gnome and KDE options that work on both allowing you to swap back and forth if you like.
IF you want to panic, this is not the thing to panic about.
((Climate change: that we can panic about!))
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.