The no future of X.org, FreeBSD becomes headless?

Why WLroots works with libxcb and probably not with libx, from https://github.com/swaywm/wlroots:
Install dependencies:
If you choose to enable X11 support:
  • xwayland (build-time only, optional at runtime)
  • libxcb
  • libxcb-render-util
  • libxcb-wm
  • libxcb-errors (optional, for improved error reporting)
In that code, I looked into a few headers, under include and xwayland directories and only saw includes for libxcb. It couldn't be expected to find libx includes since the documentation above only mentions libxcb libraries as dependencies. This is my theory for why many say X applications don't work on Wayland, and they weren't specific about which compositor they were using. It might be possible for libx applications to work on it, only because newer versions of libx use libxcb as a lower layer, but I have doubts.

As for libweston, I believe I saw it somewhere vaguely described, but I remember the description lacking specific information. However, according to the sourcecode, it has include headers for libx and libxcb and related ones. https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/backend-x11/x11.c?ref_type=heads

In the defunct wlc directory, I saw x11 includes but no libxcb includes, which newer versions of libx need libxcb as it runs on top of it. wlc is defunct anyway, so if I glossed over libxcb includes, oh well.

I'm aware of Weston and WLroots being a part of Wayland's repository. Other compositors have all kinds of specific uses, there's even one for gaming. I haven't looked into other compositors including more recent ones, that were outside of the stewardship of Wayland repositories. It's possible there's more that support libx and libxcb throught XWayland. When I wrote earlier, I wasn't including that.

I'm all for an organization stewarding Weston and libWeston as a testbed, perhaps a permanent one, and one for temporary mainstream use. Others think it should be permanent for mainstream use, but after a time, maybe they'll see, something better needs to come forward. To note, Weston nor libWeston are in FreeBSD Ports at this time. If that's in, I believe we can start testing X11 on XWayland. Then see, if even if it's not built as streamlined as WLroots, maybe it would still beat X11. That would get the ball rolling. The lack of Weston/libWeston in Ports and the expectancy for other compositors to work fully with X11 through XWayland is probably why everyone claimed that no X11 applications worked on Wayland on FreeBSD.

I see Weston as comparable to the semi-retired F-117, which it's still used as a testbed, when there's more modern stealth aircraft. Weston (and libWeston) sitting in the Wayland repository needs a purpose, and testing and development is a perfect one. It has a perfect use right now, since its XWayland layer might work right now, where WLroots likely won't. As long as there's one X11 application which relies on libx, Weston will be definitely needed.


I did some previous research on libx, libxcb, XWayland, Weston, WLC and WLroots which is at Thread libxcb-x-c-binding-library.81694. The one specific to XWayland is on Post #6. From those old notes, FreeBSD didn't have an XWayland dependency on libx11. There's a lack of documentation and explanation on which applications work with XWayland, that I had to look through it, and make some parts clear. It may take others to verify, investigate, document and/or make it more clear.

If you want to know which X11 applications are in libxcb, and a few which are in pure libxcb, as the rest are in libx, for seeing which compositor they may theoretically work with, also see that thread from the previous paragraph. Now, it seems XWayland in Ports pulls in xorg which now pulls in both libxcb and libx.
 
Mind you all this thread is the only activity of the account creating it. Think about it 😏

I currently see no need at all for sudden concern. There's nothing new. We all know X11 suffers from design problems (like carrying tons of nowadays useless cruft, like an architecture still designed around the idea of directly accessing the hardware, and several others). We all know the Xorg project is moving slow and slower with fewer people wanting to touch the code at all. And we've all observed Wayland with some questionable design ideas, initially being completely Linux-centric and only later moving towards portability at all, and trying to prove it's the sane replacement for perceived centuries. A lot of sceptics remain even in 2023.

Some Redhat announcement doesn't change anything at all. Software (if it was any good) doesn't suddenly break when some contributing entity abandons it. If any this is a slow process, but, see above, we've seen that process already.

There's concern for sure. Concern whether there will be some sane, portable, interoperable open-source display system in let's say ten years. This isn't new, this doesn't suddenly change. The current situation on FreeBSD is: Xorg is working just fine for most desktop users, and Wayland seems to work fine for many testing it as well. This won't suddenly change either.
 
Mind you all this thread is the only activity of the account creating it. Think about it 😏
The username (and image) matches a well known disruptive user on the Phoronix forums.

There he masquerades as an avid Windows user in order to argue about Linux being bad or is dying. There he isn't even particularly a fan of Wayland, so on these forums he is probably just using it as a medium to gain a reaction.

But even though his aims might be nonsense, I think discussion of cleaning up Xorg/Xenocara and strategies for maintaining software is always good to have.
 
Aside from Weston/libWeston, a few existing ports can be investigated for use with for compatibility with libx and libxcb applications. Picom doesn't have XWayland as a dependency, but it might not need it for X11 compatibility.
I'm a little worried, but if we can get that, and x11-/xdm to work on XWayland or an XDM-like program on Wayland, there's nothing to worry about anymore.

My other worry is how, I noticed that FreeDesktop.org has x11-xwayland-run which is GPL. That shouldn't be for common programs. Xorg works with FreeDesktop together now, so the licensing it has been should remain stable.
The X.Org project provides an open source implementation of the X Window System. The development work is being done in conjunction with the freedesktop.org community.
And if GPL creeps on that, Xenocara and others will fork from that GPL stuff.

There will always be a need to run X11 programs, so X or an XWayland layer will always be needed.

The programs that are on Wayland so far, already have their toolkits: https://wayland.freedesktop.org/toolkits.html. It's only for specific versions, such as GTK3, KDE5, and experimental SDL2. Programs which use other versions of those, will still be needed on X11 or an X11 layer, because Wayland by itself may lack that full range of programs.


About that user, it seems like they're not hiding their identity from being on other forums. I don't see the harm in it, if they're a fan of whichever OS it is.
 
What most people here don't seem to grasp is that in the enterprise Linux world you only get some software to run on certified Linux distributions, like Oracle database server. Or at least you get only the support on certified distributions.

For all what's it worth the market leader by a big margin in that area is RHEL, it always has been. So whatever RHEL does, it has a big impact on Linux. Furthermore many important kernel devs are employees of Redhat. Well, nowadays also other players to have a role in it as well, like Microsoft contributing lots to Linux, but in the past Redhat was already big and always there.

Furthermore let's not forget when talking about Redhat, we really do mean nowadays Big Blue, so IBM, because Redhat is a 100% owned subsidiary of IBM.

For me the problem with Wayland is that it took to long to gain traction, it is now 15 years old and still in a somewhat dubious experimental stage given its old age. It takes ages in the project for some measly progress.

I tried it, and it breaks a lot of day to day use stuff, like screen recording or taking screenshots. Applications need to be rewritten in order to achieve that under Wayland. Games often run slower under Wayland than under X11, while the promise was that games will actually run faster.

The biggest issue for me is the lack of some standard components in the beginning people could build upon. So nowadays we've got libinput, which almost every compositor uses and also X11. But that's it.

Now that every WM has to be its own compositor leads to fragmentation, in terms of used version of the protocal as well configuration parameters enabled and used. So there's way too much stuff going in, which is duplicated in every compositor out there. And that's a bad thing.

Above doesn't mean that I am pro X11 and think its the holy grail of whatever, it just means that I mean that Wayland sucks still too much and delivers too little too late.
 
I love XFCE :D
I moved from gnome to xfce since Gnome 3.
I did try Gnome 3 for several months but I really couldn't stand those huge controls any longer, huge buttons,huge dropdowns, title bars, everything is huge and ready for touch devices.
I need display space for reading code and documents so switching to Xfce was the best thing I decided to do.
 
Correct.

We manage about 1400 RHEL boxes at $JOB. 1350 are VMware VMs and the few that are physicals are part of an Oracle ghetto. None have X.
Unlikely? Perhaps.

We manage about 50,000 RHEL boxes at $JOB. About 8,000 are KVM and the rest are physical. Of the physical servers, hundreds, probably about 800 are X workstations that are mission critical, and the company would cease to function without them.

Correct me if I'm wrong, but REL is unlikely to be used on the desktop in the first place, no? Isn't it mostly a server and enterprise used OS?
FreeBSD is unlikely to be used in the data center; isn't it mostly a hobby OS? This is fundamentally the same argument being made of RHEL workstations.

The Fortune 200 company I work for uses RHEL workstations with a need for X.
Netflix uses FreeBSD for content delivery.

Neither widely used for their purposes, but both still used.
 
FreeBSD already has wayland in ports.
I think that kind of misses my point, because just being in ports says nothing about how well it actually works. My point was that Xorg is more or less automatic, 'works-out-of-the-box' installation on FreeBSD, and Wayland is not there yet. Yeah, Wayland demonstrably works on FreeBSD, it compiles and runs. Thing is, it has not yet gained parity with Xorg in terms of ease of setup.

I'm aware that FreeBSD is mostly a DIY, but I think that Wayland is one of those basics that needs to be done right, just like Xorg was in its day.
 
and the few that are physicals are part of an Oracle ghetto.
Haha, bizarrely ours is more like a shanty town. It grows on fringe projects and no-one knows why.

Oracle is installed through an X installer. Some Oracle apps require an X server, so DBAs display to Xvfb. RH has removed support for utilities that Oracle has documented DBAs use to verify the environment before installing Oracle.
Oracle, through OEL (Oracle Unbreakable Linux) will probably support X for a long time because their DBMS installer needs it. I don't see X going away anytime soon.
If I recall, Oracle installer also bundles its own (aging) Java runtime/VM *just* for the installer. Why are they so keen on a GUI installer vs a command line one? I would have thought it had both (I think the express editions do) but admittedly I never bothered looking.

In this case, Xvnc, Xvfb, X11/ssh is a proven solution that does work. I think Wayland is currently just too... random to have a defacto solution to the problem of remote interfaces required for orainstall. It can be done but by the time you have written decent documentation, it will have changed.
 
Haha, bizarrely ours is more like a shanty town. It grows on fringe projects and no-one knows why.


If I recall, Oracle installer also bundles its own (aging) Java runtime/VM *just* for the installer. Why are they so keen on a GUI installer vs a command line one? I would have thought it had both (I think the express editions do) but admittedly I never bothered looking.

In this case, Xvnc, Xvfb, X11/ssh is a proven solution that does work. I think Wayland is currently just to... random to have a defacto solution to the problem of remote interfaces required for orainstall. It can be done but by the time you have written decent documentation, it will have changed.
Agreed.
 
Would such approaches mean an end to (HI major) KDE bug 78871, which will never be fixed for users of X11?

Context (privacy, security): <https://forums.freebsd.org/posts/627337>.
I don't know. It seems like they're different things that one bug might not apply to another program. It might not have that bug, but could have similar ones.

Look at x11/ly which is a TUI login manager, for both Wayland and X11. When I tried it, I logged in, then when logging out, it messed up the screen, and gets parts of X11 and window mangers visually mixed up on the screen with ly. That's a bug that XDM and a few other login managers haven't had, yet ly has, so it's a different category for bug similarity. If that hasn't been fixed, it needs to be. When people know it works correctly, more people will be willing to try Wayland as a standalone desktop. I believe Wayland can be started inside the X11 desktop, and it comes with its own window instead of needing a jail and forwarding for that.

I don't know if Weston works with XWayland the way it's supposed to. I only know that libWeston has the includes for both libx and libxcb which seem to be needed.
 
Here's my Wayland experience. No permanent changes, yet.

I disabled xdm. I started seatd and ran ly (x11/ly) from a root shell prompt. Nothing happened.

Plan B: reboot the laptop. Start seatd and run ly again. This time I could log in. Note: my account is an LDAP account authenticated by MIT KRB5, both served by a machine in my basement with my laptop as a secondary (slave) server for when I'm away from home.

When I logged in, it executed my .xsession. My .xsession displays a selection of windowing environments. I selected CDE. It worked. The only caveat is that the cursor isn't an arrow. It's an Xorg X cursor. That can be easily fixed by setting the cursor in my .xsession file using xsetroot(1).

Xwayland doesn't listen to 6000/tcp, so no remote X clients can connect. Not a big deal if you use ssh with X11 forwarding, that worked.

Performance-wise, it's comparable to X. I don't know if the drm bug (artifacts in apps which use the GPU, i.e. gtk apps) that exhibits itself when performing a lot of I/O while rendering. I'll need to try and break Wayland like X in this regard. I'm betting it will also exhibit the artifacts as this is a drm problem which causes GPU panics, as witnessed syslog messages.

It took all of five minutes to run the test, including reboot the laptop.

I'm switching back to X and xdm because I have FreeBSD work to do and I can play later. Certainly a pleasant surprise.
 
Now we have over 15 competing implementations and some libraries (wlroots, libweston and louvre) which strive to be the backbone of all Wayland servers, unfortunately that's not been happening. Gnome Mutter and KDE KWin don't use these libraries.
Weston and its library are the original, and were for showcase, which came with Wayland. It's considered obsolete, though it's always useful for development, testing or transitioning. Weston applications may also be useful for hobbyist systems and for getting features to work. Wlroots is the most mainstream one, which many compositors use. Louvre doesn't seem to be in ports here, though it would one one of those useful for those who want a library in C++. Anything else, will be for specific use cases.

It's irrelevant that KDE and Gnome don't use those compositor libraries, because Wayland is intended to use graphical toolkits for those applications, instead of the Wayland compositor libraries for them. The graphical toolkits would be used across compositors, regardless of which compositor library they used.

I think we should take Weston and steward development of it towards a reference compositor like Xorg IMO.
x11-wm/hikari is developed on FreeBSD and is in C. It's based on wlroots, and uses it as a dependency. Interestingly, it's inspired by CWM (Calm Window Manager) [*], and a little off topic, Darcs is an interesting version control system which Hikari has used, described as friendly.

Weston can still be very useful, as I wrote in this thread a few times, so I'm for that.

I selected CDE. It worked.
Many other X11 window managers could be expected to work on it as well?
Xwayland doesn't listen to 6000/tcp, so no remote X clients can connect. Not a big deal if you use ssh with X11 forwarding, that worked.
Was that with just CDE on XWayland, without a compositor or compositor library?

So, if it were with a compositor without libx and libxcb dependencies, it would imply that X applications worked on Xwayland, regardless of their libx and libxcb status?
 
Any window manager should work under Xwayland.

Xwayland doesn't support the X protocol over the network. This is by design. But as I said before, you can still tunnel X through ssh.

My test was a simple, "can I get it working without a lot of fuss" test. I didn't use it for more than a few minutes and a quick Google for wayland problems will provide with many hours of reading enjoyment, for example, Think twice before abandoning Xorg. Wayland breaks everything!

I think installing it and playing with it is probably advisable. We may find it distasteful but there's no denying that it will become the dominant Linux GUI over the next two years. Understanding it is better than not.

If you use X through, xdm, gdm, some other display manager, or just use startx (or xinit), once Wayland is installed you can easily switch back to X and back again.

Again, I will continue to use X but I'm not alarmed or concerned over Wayland in the near to medium future.
 
Segments from that article:
Wayland is biased toward Linux and breaks BSD
https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."
That's troubling, and will get worse. Rather than just Weston. We'll need a homegrown implementation to replace XWayland, and this time, make it clear in the documentation the types of X11 applications it supports.

Wayland breaks window managers
Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.
Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality
Wayland breaks NetWM
Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications
Wayland breaks screensavers
Won't be a future issue, since Wayland, a compositor or a Wayland toolkit would be expected to have their own native running screensaver.


I'm not worried about X11 in the short term either. Wayland for widespread use won't be a go, until X11 applications work natively on it. Until then, there's plenty that will rely on X11 to maintain that.

I'm not even going to play with Wayland, until there's homegrown or BSD forks, and projects for more of it, in addition to Hikari.

It was good to learn about what others had to say about it so far.
 

I detect sarcasm. More of the same: hours of clicking before commentary can be read.

A single item at gist.github.com was a poor choice for a complex subject.



Maybe a better point of reference from the same author (I have not read either page, I'm in no rush):
 
Last edited:
Maybe a bit of sarcasm, yeah. Wayland is not enterprise ready.

I could write a lot more about this topic.

No sarcasm: Still worth learning about it if you work at this stuff professionally. I'll probably need to work with it in a year or two. Just like I had to accept systemd and networkmanager. It pays the bills.
 
Here's my Wayland experience. …

… I don't know if the drm bug (artifacts in apps which use the GPU, i.e. gtk apps) that exhibits itself when performing a lot of I/O while rendering. I'll need to try and break Wayland like X in this regard. I'm betting it will also exhibit the artifacts as this is a drm problem which causes GPU panics, as witnessed syslog messages.

It took all of five minutes to run the test, including reboot the laptop.

I'm switching back to X and xdm because I have FreeBSD work to do and I can play later. Certainly a pleasant surprise.

cy@ what's the graphics hardware?

(Is that, the Acer (4752)? I see <https://www.startpage.com/do/dsearch?query="Acer+4752"++"NVIDIA"&cat=web>, but can't guess whether you're amongst the people who choose to use NVIDIA with a 4752.)

TIA
 
Xwayland doesn't listen to 6000/tcp, so no remote X clients can connect. Not a big deal if you use ssh with X11 forwarding, that worked.
Well that makes it easier to swallow.

So a current i915kms DRM video driver is cross compatible? SCFB works with xWayland?
Do you think this stuff will work on Arm?
 
Phishfry, I think that Alain De Vos has something on the forums about his experiences with labwm. As for me I tried it on a Linux, forget which one, but it didn't seem to like my rc.xml file. Rather than looking into it, I just gave up.

For i3 users, there is sway, don't know if there's a dwm equivalent.
 
Back
Top