How long will Xorg live?

I heard that Xorg is no longer being developed and will eventually be discontinued in favor of the newfangled Wayland.

Whether I use FreeBSD or Gentoo, I usually install xorg + tiling wm (awesome or xmonad). Both of them (awsome and xmonad) won't work on Wayland.

Don't care about Gentoo, I thought, but FreeBSD doesn't change so drastically, and this scheme (xorg + xmonad) will probably work for a long time to come.

I use FreeBSD as Desktop always. How long can I go without worrying about changing my habits and changing Xmonad/Awesome for something that supports Wayland?
 
I don't think X developement is dead.
Oh sure, I don't think so either, but...
"code that is not maintained is bound to degrade over time. The obvious issue is that X11 isn't getting any functionality, and GTK has already moved towards Wayland as the primary design for features and API already. This means that the X11 backend will either not get any new functionality that application developers will very much rely on, or will act as a barrier for implementing that functionality in GTK." (c)

As far as I could understand the contents of the first conference in the list (X.org), it is for developers of libraries such as Mesa, DRM, Wayland, X11, etc., where X11 is only one of the topics.
 
GTK moves towards wayland for the same reason gnome moves towards systemd. Wayland is in development by 14 years already (maybe they're waiting for enlightenment to catch up?😂) and still have some issues that some people refuses to see (IPC anyone?), so no, Xorg isn't gonna die any time soon.
 
First comment on the issue linked in the Phoronix article pretty much sums it up and most of the comments don't seem to think it's a great idea (now).
 
Haven't you heard? BSD is dying too!

Seriously, this is a never ending self-repeating story. BSD was reportedly already "dying" when I was still wearing diapers. And here we are, decades later and we're still going strong.
While I don't know much about Xorg I can only assume that it's a similar situation.

Also, GTK is a truly ugly piece of software in itself (very personal opinion!).

As far as wayland goes: I'm not much of a desktop person but while there are some nice concepts in there I have yet to see which problems it actually solves. Xorg had problems 14 years ago when Wayland started. Many of those issues were fixed or mitigated. A lot changes in 14 years - especially in the world of software.
That being said - I'm not against wayland either. I definitely don't know enough about the topic to make any judgement there. What I mean to say is merely this: People are going to talk shit every day and software changes too.
 
Xorg (or, better, X11R6, cause Xorg is just the current usable open-source implementation of it) will live for as long as there's no suitable successor. And sure, now I here the calls for WAYLAND!

While I don't know much about Xorg I can only assume that it's a similar situation.
There are good reasons to get rid of X11. It's a beast. It carries tons of old cruft nobody would ever use any more. And even the "network transparency" is more or less useless, it doesn't perform well, protocols like Microsoft's RDP are way superior (and there's no need to directly integrate such a feature in your base graphics rendering infrastructure).

So, wayland seems to attempt to "do the right thing". Unfortunately, it doesn't seem to really succeed with that so far. First and foremost, a successor for X11 must be stable and reliable. And then, it must be portable.

I have to admit, I didn't even try running wayland myself. As long as I'm reading so many horror stories, I don't see the point.

X11 is dead, long live X11 🤡
 
Also, GTK is a truly ugly piece of software in itself (very personal opinion!).
Have to add this: as much as I love C and detest C++, and as much as I think the basic idea of GTK (and glib) to use object-oriented C is a good one – I still agree. GTK is horrible. To a degree where I opt to use a language I detest (C++), just to get an awesome GUI toolkit I like (QtGui and QtWidgets).

(edit: Qt works fine with -fno-exceptions -fno-rtti, therefore already avoiding the worst C++ f*ck*ps, hehe)
 
The main issues on Wayland that I have seen so far, is that outside of Gnome/GTK it is still broken/barely working. The other issue is that very few programs are writen for Wayland, they are writen for X11; so you are needing an shim adapter for everything (which again is largely barely working, since they was hastely made then forgotten thinking everything will magically be rewritten for wayland).
 
The Wayland ecosystem only realistically has Gnome, KDE and Sway as window systems. At this rate it has zero chance for adoption industry wide. You only hear about it from the more vocal Linux users because they only really use web browsers and Steam games where it is adequate.

I do however hope that Linux does adopt it so we can get a clean separation between broken Linux things like hald, dbus, udev and our Xorg display system (Like OpenBSD has with Xenocara). Currently our xorg and xorg-minimal are pretty messy. xset m doesn't work well on FreeBSD's xorg compared to OpenBSD's Xenocara for example. Instead you need to potentially set transformation matrices or weird things like that via i.e xinput --set-prop "TPPS/2 IBM TrackPoint" "Coordinate Transformation Matrix" 0.5 0 0 0 0.5 0 0 0 1 after finding the device ID..

The good news is that with the introduction of KMS (inteldrm, amdgpu and radeondrm, etc), it is much cleaner code so yes, just one or two people *can* maintain Xorg. It is even easier to maintain than an individual Wayland compositor. So this will be nothing for the OpenBSD, FreeBSD, NetBSD, Solaris, AIX developers.
 
For Wayland: the compositor, a graphical toolkit, the programs that use that toolkit and shims for older programs may be relevant. Wayland is meant to be modular this way. XCB may be more relevant than Xlib without XCB for Wayland.

Some compositors, especially newer ones (wlroots), are only meant for a toolkit and an XCB shim which is often mistaken as xlib (and it is often a part of xlib), but not xlib. I'm not 100% sure on this, but I suspect that people are expecting xlib applications to work on it, when XCB is assumed as Xlib, and they think it's broken. An older compositor of Weston was for use with a shim for xlib as well.

Wayland lacks a graphical display manager on FreeBSD. When I tried ly, it worked for logging in at first, but it risked messing up my computer by writing over other data.

Until Wayland has a graphical login manager, XCB has more applications that can be used without the rest of xlib, and there's a good graphical toolkit with enough applications, Wayland is best kept in jail, perhaps in a nested display.
 
Some compositors, especially newer ones (wlroots), are only meant for a toolkit and an XCB shim which is often mistaken as xlib (and it is often a part of xlib), but not xlib.
If they were serious they would make an API compatible Xlib and XCB library that speaks Wayland protocol underneath rather than X11.

But they aren't serious and they know it. So the solution is Xwayland which is an entire (Xorg based) X server which (yep) every compositor that people write will need to implement. wl_roots does help with this by providing some ratty unstable API code intended mainly for Sway but... this is not how a replacement for X11 is going to work. It is almost embarrassing to see compared to the engineering of the X ecosystem back in the day.
 
If they were serious they would make an API compatible Xlib and XCB library that speaks Wayland protocol underneath rather than X11.

But they aren't serious and they know it. So the solution is Xwayland which is an entire (Xorg based) X server which (yep) every compositor that people write will need to implement. wl_roots does help with this by providing some ratty unstable API code intended mainly for Sway but... this is not how a replacement for X11 is going to work. It is almost embarrassing to see compared to the engineering of the X ecosystem back in the day.
They do. Wlroots has an XCB shim, but not an xlib shim. They have been trying to depreciate xlib. Older libWeston has both the XCB and Xlib shim.

The dependencies of wlroots say XCB, but for some reason it's not clarified beyond that and the step above that is claiming XCB as xlib. People are trying to run xlib applications on it. This is may be why they're thinking it's broken. It's meant for XCB, but is mislabeled as xlib, as beyond the dependency, they think they're interchangable.

There are a lot of libxcb applications, but there are very few that are independent of pure xlib.
 
They do. Wlroots has an XCB shim, but not an xlib shim. They have been trying to depreciate xlib.
But Xlib is built ontop of XCB these days. I.e if you trace Xlib calls in a debugger, they all lead to the underlying XCB implementation. There should be no Xlib shim for wl_roots deprecate.

If the XCB shim can't support an unmodified Xlib, then it is completely unsuccessful as a project.
 
I do however hope that Linux does adopt [wayland]
I don't think that would be beneficial.

First, you have to realize that "desktop" is, in general, on its way out... you won't find classic desktops in private homes any more (except for those of tech nerds). They're being replaced by mobile devices (phones, tablets) and other devices like smart TV sets. Desktops are still a thing in offices, and will probably stay for software development for quite a while... but they're not "mainstream" any more as they used to be.

Now, in this shrinking segment, unix-like systems are only a very small fraction.

And from this very small fraction, the by far largest part are Linux desktops.

So, people developing "desktop" software for unix-like systems develop for Linux. If Linux would exclusively use some incompatible software stack for GUI, the thought of still having a usable BSD-based desktop is probably just an illusion.
 
There's lack of documentation regarding separations of pure xlib and pure XCB, in the compositor. As I've said, they've been trying to depreciate Xlib, for something better, but the movement has stalled, and now it's a setback for something different. I read that some applications were being converted to XCB, but then the authors undid their work, and reverted to X11.

Parts of xlib got replaced with XCB, but most applications are still dependent on xlib.

Older Weston/libWeston has shims for both XCB and Xlib. Also for a combination of them. I read that Xorg sponsored libWeston is a mess compared to wlroots though. WL may stand for Wayland in Wlroots and the defunct wlc. Weston still worth trying to test out the full XCB and Xlib shim.

That's a failure of documentation as to why people think something is broken, when it's not intended to work in a certain way.

But Rust applications and qt have XCB worked into them. They work as standalone as the graphical toolkit or developed language are using newer implementations of X11.
 
No matter what Linux does, it will work out for FreeBSD, bc Wayland is modular in a good way.

It may be on an XCB shim, perhaps on an optional but legacy Xlib shim, a new graphical toolkit, or something based off of wlroots. Many on FreeBSD use Gtk or Qt5 anyway, so that can do a lot already. On Wayland, the toolkit and shims work independently of the compositor. If there's a xlib shim, I hope it maintains a clear separation from an xcb shim. I also hope any future xlib shim adopts more xcb code into it.

There's a lack of graphical toolkits, a graphical login manager and enough that works on shims. It will get there.
 
So, people developing "desktop" software for unix-like systems develop for Linux. If Linux would exclusively use some incompatible software stack for GUI, the thought of still having a usable BSD-based desktop is probably just an illusion.
I agree to an extent but this part. Almost all important *nix software is ported to Windows. If they can do that; it is more than likely that we won't lose anything since our port will be much easier. Only the display parts will need to be ported; not even the POSIX or anything else "unixy".

Realistically we may only need to maintain a GTK / Qt / SDL driver ourselves since 99.9% of Wayland software is stuck with a limited selection of toolkits. That won't be difficult.

And it will only be temporary whilst we wait for a real successor to X11 to come along... ;)
 
Haven't you heard? BSD is dying too!

Seriously, this is a never ending self-repeating story. BSD was reportedly already "dying" when I was still wearing diapers. And here we are, decades later and we're still going strong.
While I don't know much about Xorg I can only assume that it's a similar situation.

Also, GTK is a truly ugly piece of software in itself (very personal opinion!).

As far as wayland goes: I'm not much of a desktop person but while there are some nice concepts in there I have yet to see which problems it actually solves. Xorg had problems 14 years ago when Wayland started. Many of those issues were fixed or mitigated. A lot changes in 14 years - especially in the world of software.
That being said - I'm not against wayland either. I definitely don't know enough about the topic to make any judgement there. What I mean to say is merely this: People are going to talk shit every day and software changes too.
BSD Is Dying
 

SDL which is a library for games and multimedia on top of C has support for Wayland. While SDL worked with Wayland as stable, there was lack of support for other advanced features and applications for Wayland.

Without a desktop graphical kit, it may be limited to SDL, but that's a lot of games by itself.
 
Well for me the main problem is that Wayland does not feel like a product, but a tech set and more like a tech demo. I also disagree with some of their design desicions they've made as well.

X.org will not go away anytime soon, in the meantime they've even solved some of the problems like tearing for which Wayland was created. Of course this does not eliminate the other, questionable design choices in X11, which are also a problem security wise.

Let's face it, Wayland started around the same time systemd did. While systemd managed to become the de facto standard on Linux and now is ubiquitous, Wayland is still a nerdy tech thing a few people might try with its own set of problems and quirks.

For me the biggest flaw in the design of Wayland is the lack of a standardised, central display manager/server like X11 has. I am aware about that there is a reference compositor, Weston, and as well an input library for most input devices called libinput.

But: as long as a compositor talks the Wayland protocol, its creator is free to use whatever parameters he wants, also for configuring that beast. This is a potential source for fragmentation, while X11 has only one configuration there.

More important though the benefits of using Wayland nowadays are still too tiny for most people to even try, while it still has some broken areas after all the years when comparing to X11 functionality. Wayland probably will start to fly if a major Linux distribution will replace X11 with it by default. Until then it is a nerdy tech thingy most users simply put will not be aware or care about. RHEL has plans to remove X11 in the near future in a major version at the moment.
 
Back
Top