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

[kpedersen]

A diagram like these are what I had in mind, so others can improve upon the ideas, if I missed something, or if more detail is needed, and as this doesn't show the underlying proposed or existing workings of Wayland and X11.

I do kind of get where you are going with these. You are basically trying to make a thing capable of running both X11 programs and Wayland programs. So either top down (Xorg supporting Wayland programs) or bottom (so very, very bottom!) up (Wayland compositor supporting X11 programs).

It is good to consider but I don't know if this approach is the one to take. It seems to just be wanting "more", when really I think maybe we should be finding ways of evading the Wayland ecosystem entirely. Otherwise it will just be tread-milling and compromises all the way down.

It is not only the compositors. It is all the widget sets, the code already written and no real maintainer behind it. Who will port that? Noone. Outside of QT and GTK, what will work?

True. Though on the other end, we need to brace ourselves for the announcement of:

Gnome's Gtk has officially removed X11 support due to [some vague reason relating to client side decorations]

We have around three options:

• Bend over and just use Wayland with "legacy" X11 programs in the occasional nested window or VM
  
  
• Reinstate X11 support into Gtk ourselves. Upstream will make this purposefully hard leveraging more Wayland specific gimmicks such as client side decorations (that not even their own users even care about) until this is almost impossible.
  
  
• Simply maintain the last X11 supported versions of software. Almost split the ports collection. In some ways, the older shite is often better when it comes to open-source so if we stand our ground, this might actually be an option. We would have to plan now. The fact that Gnome 3 killed Gnome 2 before it was even working properly a long time back, suggests that FreeBSD as a project isn't great at standing ground though...

Its going to be exceptionally annoying because they will still have Win32/Cocoa support in Gtk. Just not X11 to strong-arm the community into being reliant on freedesktop/Gnome (and ultimately Red Hat/IBM).

 

[sidetone]

There's a 4th option, that we make X11 better, and take some ideas to make it better for the BSD way. It's the one I described, where we add a Wayland layer on top of X11, which can be optional and kept modular, and actually, it would be halfway between that and having our own type of compositors. It can be optional, doesn't have to be bloated, and be minimal, to only support if people really want to use a compositor or a Wayland toolkit. If newer versions of programs decide to abandon X11, that's what we may need. It may make it easier if we want to implement a newer gtk version meant for Wayland to be for X11 as well, so it would be halfway to that as well. A Wayland layer for compositors on top of X11, can also be a separate project and be kept modular, where we keep that from infecting its way down.

The fact that Gnome 3 killed Gnome 2 before it was even working properly a long time back, suggests that FreeBSD as a project isn't great at standing ground though...

Actually, them leaving gtk2 and the gtk3 implementation for X11 alone, is an opportunity in disguise. We often complain how they drive those projects and make it their way, and now they don't have interest in that for those two libraries. Since gtk2 and gtk3 are under LGPL2, they're not so bad, and the BSD community can embrace them as second class citizens. Because they allow dynamic linking, and are compatible for use with everything, we can build BSD licensed components around them, keeping a clear separation. Additions wouldn't be forced into dual licensed code because they are allowed to be outside of gtk2 and gtk3 boundaries.

This is a separate project, but we could have a common libxcb layer of gtk (gtk-libxcb), that uses the FreeBSD license, and becomes a dependency of both gtk2 and gtk3 (X11 version). We make gtk2 and gtk3 pure libraries, and merge what else can into gtk-core, then make the differences of style for either one as gtk2 and gtk3 style. Additional dependencies such as CUPS, go into a separate metaport, as gtk-utils, as they're nonessential to the graphical toolkit. This would make maintenance simpler. Perhaps the graphical toolkit xcb layer can also be for non-gtk libraries as well.

As for Athena Widgets, the only Xaw worth preserving for forking is libxaw3dxft. The other Xaw implementations are obsolete, and don't have anything towards multifonts (even in libx) for internationalization. Though, keep this from being dependent on any LGPL/GPL.

qt5 is already taken care of for libxcb.

Anything that doesn't have an libxcb equivalent, we proudly use libx components there. For instance, font rendering, which there is sourcecode for libxcb, but they're broken or incomplete.

 

[LibreQuest]

Does xwayland not allow Wayland to perform the same functions that x11 can perform by using x11 libraries?

It would be very nice to see feature parity between the two.

 

[unitrunker]

Anything that doesn't have an libxcb equivalent, we proudly use libx components there. For instance, font rendering, which there is sourcecode for libxcb, but they're broken or incomplete.

That's a gap that most xcb apps fill on their own (I create a shared pixmap). Would be nice to have a standardized way of handling fonts.

Does xwayland not allow Wayland to perform the same functions that x11 can perform by using x11 libraries?

There's a wayland wrapper for X and an X wrapper for wayland. I forget which one is which. I used sway a while back to play with wayland client code without actually running wayland. My toy wayland app was trapped inside the sway frame window. It could not interact with the X desktop.

 

[kpedersen]

Does xwayland not allow Wayland to perform the same functions that x11 can perform by using x11 libraries?

An important one is that Xwayland does not allow an X11 Window Manager to control all windows on the screen.

 

[sidetone]

Does xwayland not allow Wayland to perform the same functions that x11 can perform by using x11 libraries?

An important one is that Xwayland does not allow an X11 Window Manager to control all windows on the screen.

That, and other topics already mentioned in this thread. That may be window reparenting or similar. It doesn't work with Screen savers, as is in a link, and discussed. Also, how it may not work over server display forwarding over a protocol.

It would be very nice to see feature parity between the two.

At least, if limited to little more than those features.

 

[ssokolow]

As long as there's one X11 application which relies on libx, Weston will be definitely needed.

Why?

I admit I've only ever used BSDs (FreeBSD and OpenBSD, specifically) in headless networking hardware but, as someone who's written the odd thing against python-xlib or xcffib (Python xcb bindings) and has been daily-driving Linux for desktop use since the early 2000s, I was under the impression that it didn't matter whether your application used Xlib or xcb because both were just abstractions over the same underlying wire protocol and optional SHM extensions.

How else would you be able to forward even something like a GTK 3 or Qt 5 app over SSH and only suffer "VNC at best" performance as a downside?

Xwayland is equivalent to Xephyr but you probably don't run your Window Manager of choice in a nested Xephyr session do you? Do you know anyone who does? Imagine that KDE could only run in an Xnest / Xephyr instance so couldn't actually handle any of the windows that pop up natively. Would that be a good experience? This is what a user running Mwm, Fvwm and other standard Window Managers would face.

XWayland originally only supported rootless mode, with rootful mode (the Xephyr-like one) only getting attention much more recently.

Think less "Xephyr" and more "An ordinary looking desktop except that the X11-only applications like xprop/wmctrl/etc. can't manipulate or snoop on input events from the Wayland windows for security reasons".

KDE even wrote a proxy that allows forwarding of Wayland windows or the whole screen into a hidden XWayland window so screencasting can work with applications that don't do Wayland.

As for running an X11 WM to manage Wayland windows, people like me who just need to get s..t done are starting to look into options for getting actually usable desktops in a maintainable fashion using things like "Find a Wayland compositor with an X11 backend that can operate in rootless mode. Run that on top of XWayland to support Wayland-only applications, and then run XWayland in rootful mode on top of a kiosk-oriented compositor like cage or weston kiosk-shell to get a maintained X server on top of a Wayland HAL."

Widget libraries are preferring CSDs (Client-Side Decorations) which means, Server-side decorations become harder to do/impractical.

GNOME is petulantly refusing to implement the protocol extension for negotiating decorations and trying to spin "we're hamstrung by Mutter's technical debt" as "SSDs or any other reparenting-esque behaviour are inherently bad for performance".

KDE still prefers SSDs so much that they originated the protocol extension for SSDs. (Like with modern X11, one must not judge Wayland by what its core protocol looks like.)

Things that follow the GNOME HIG use GtkHeaderBar, which forces CSDs, but things which don't want to follow GNOME's lead on that can still use normal titlebars and GTK will then negotiate SSDs using the decoration protocol if offered. (eg. wxWidgets, Inkscape, GIMP, etc. etc. etc.) ...though GTK is still dragging its heels on upgrading off KDE's old, deprecated proprietary version of the decoration protocol to the new, standard one. (According to Wayland Explorer, that shouldn't matter to end users right now since wlroots supports the old KDE-proprietary version too.)

Qt supports the decoration protocol and doesn't have a preference one way or the other.

wlroots implements the decoration protocol.

it's widely agreed that Weston has bigger points of incompleteness than the decoration protocol if you want to use it for something other than a kiosk.

People often forget that Mir still exists, so it not implementing the decoration protocol shouldn't be a concern.

Enlightenment is so forgotten that its Wayland support doesn't even get a column in the comparison tables on Wayland Explorer.

The omission of decoration protocol support in Arcan's column in Wayland Bites is probably more in the vein of "Arcan doesn't implement decoration protocol because it'll just defer to your preference, even if that means wrapping CSDs in SSDs", given this post by its creator which does not have a very favourable view of them and presents a proof of concept for having Durden crop away the CSDs so they can be hidden behind a toggle-button on the SSDs.

That's partly my fear here -- the flare for individuality is diminished with Wayland because the focus appears to be more on the graphics rendering backends than it does providing the same capabilities as xorg has now -- in effect, throwing everything out with stale bath water. It's also a mammoth task in making wayland usable at the moment, when you compare that to xorg.

It's more a mix of three things:

First, GNOME being obstructionist and bikeshedding on anything that doesn't fit their vision, which draws out the process of figuring out whether things can go into the extension namespace that implies "everyone is willing to implement this".

Second, KDE and and the author of wlroots weren't really pushing very hard for most of Wayland's life, refusing to implement EGLStreams and sort of waiting for Wayland to "become viable" in the "too many people rely on nVidia GPUs" sense because of that. They are only now building up inertia to counterbalance GNOME and steer the set of available features in new directions.

Third, the protocol extension discussion is taking a Rust-ish "Let's not rush things. We have to support this effectively in perpetuity" approach to protocol design.

When this happens, applications using such a widget library would be unable to compile on top of xorg, hence they'll become Wayland-only.

See previous comment about Wayland-as-API/XWayland/Wayland-as-HAL stacks.

 

[birdie]

Mind you all this thread is the only activity of the account creating it. Think about it ?

I'm genuinely concerned about the future of FreeBSD. I did not intend to troll, spread FUD or anything like that. I'm extremely upset to see such a weird and almost degrading reaction.

 

[Jose]

If you've ever wondered what concern trolling looks like, birdie delivers a pretty clear and transparent example of it.

However, this trolling spawned a useful and interesting discussion, probably much to the initiator's distaste.

 

[Jose]

As for running an X11 WM to manage Wayland windows, people like me who just need to get s..t done are starting to look into options for getting actually usable desktops in a maintainable fashion using things like "Find a Wayland compositor with an X11 backend that can operate in rootless mode. Run that on top of XWayland to support Wayland-only applications, and then run XWayland in rootful mode on top of a kiosk-oriented compositor like cage or weston kiosk-shell to get a maintained X server on top of a Wayland HAL."

Wow, that's complicated. It seems reasonable to you?

 

[smithi]

I'm genuinely concerned about the future of FreeBSD.

This is now your fifth post to the FreeBSD forums, all on this topic. It's not easy to see why you may be concerned, and what your connection with FreeBSD has been, over time?

I did not intend to troll, spread FUD or anything like that.

I'm seeing people say that we don't perceive what Redhat in particular or Linux in general does to be creating F, U or D in the FreeBSD community.

You still appear to assume that those entities have some sort of control over FreeBSD. I see people pointing out that most of us don't see FreeBSD as being subservient in that way.

I'm exremely upset to see such a weird and almost degrading reaction.

Really?

As Jose said, you've spawned some useful and interesting discussion, so thanks for that!

 

[Cath O'Deray]

If you've ever wondered what concern trolling looks like, birdie delivers a pretty clear and transparent example of it.

That's unnecessarily rude.

Moderators can, less rudely, sense whether a newcomer is trolling.

… New users are always moderated of course. …

useful and interesting

Rudeness is neither useful nor interesting. It's a turn-off.

Off.

 

[sidetone]

as someone who's written the odd thing against python-xlib or xcffib (Python xcb bindings) and has been daily-driving Linux for desktop use since the early 2000s, I was under the impression that it didn't matter whether your application used Xlib or xcb because both were just abstractions over the same underlying wire protocol and optional SHM extensions.

I didn't fully understand.

Some X applications are made that they don't use libx and libxcb at all, and they go directly to X. It seems excessive to have to rewrite those layers for each application. That may need a shim too, if it doesn't work natively.

Are you saying, that programs run on libx and libxcb can be plugged in, without having to rewrite for each program those lower X11 layers?

Are you saying XWayland uses those direct X11 layers, without libx or libxcb. Then, something has to make all 3 types of X11 programs compatible. Unless XWayland and the compositors do that already, without them being called libx or libxcb. Compositors only have dependencies for either or both of libx or libxcb. Most have dependencies for either one.

The documentation needs to be explained if, what speficially within XWayland and specific compositors, allows each of libxcb, libx and direct to X11 to directly run on those XWayland layers.

 

[ssokolow]

Wow, that's complicated. It seems reasonable to you?

It should be as simple as replacing /usr/bin/X with something like "/usr/bin/cage /usr/bin/Xwayland" in whatever script you use to start your X session and then adding whatever Wayland-on-top-of-X server you want to ~/.config/autostart or ~/.config/openbox/autostart or wherever else your chosen desktop session looks for things to launch on login.

I didn't fully understand.

Some X applications are made that they don't use libx and libxcb at all, and they go directly to X. It seems excessive to have to rewrite those layers for each application. That may need a shim too, if it doesn't work natively.

Are you saying, that programs run on libx and libxcb can be plugged in, without having to rewrite for each program those lower X11 layers?

Are you saying XWayland uses those direct X11 layers, without libx or libxcb. Then, something has to make all 3 types of X11 programs compatible. Unless XWayland and the compositors do that already, without them being called libx or libxcb. Compositors only have dependencies for either or both of libx or libxcb. Most have dependencies for either one.

The documentation needs to be explained if, what speficially within XWayland and specific compositors, allows each of libxcb, libx and direct to X11 to directly run on those XWayland layers.

X11 is a network protocol with TCP and UNIX domain socket transports and an extension for doing the bulk of the data flow via shared memory.

When nginx became popular, there wasn't some libApache that Firefox and Internet Explorer and so on were linked against that needed to be preserved. It's the same sort of situation here.

Think of XWayland as an HTTP server, like Apache or nginx or what have you, and Xlib and xcb as HTTP client libraries. You don't need your HTTP server to explicitly support every HTTP client library and, barring bugs that need to be worked around, you don't need your HTTP client to explicitly support every HTTP server.

it's perfectly possible for people to write their own raw implementation (IIRC, python-xlib is a pure Python X11 implementation, not a library binding)... you just need to make sure that, when you switch to something with a completely different implementation, like Wayland or HTTP/3 (which takes HTTP/2's multiplexed transport and runs over QUIC instead of TCP), that you maintain compatibility with the old protocol, like X11 or HTTP/1.1.

 

[unitrunker]

My take on the whole wayland thing is this: as long as my xcb apps work, I'm good.

 

[Jose]

It should be as simple as replacing /usr/bin/X with something like "/usr/bin/cage /usr/bin/Xwayland" in whatever script you use to start your X session and then adding whatever Wayland-on-top-of-X server you want to ~/.config/autostart or ~/.config/openbox/autostart or wherever else your chosen desktop session looks for things to launch on login.

OK, so the entry door into your Rube Goldberg machine is clearly marked. What are my chances of troubleshooting it when something goes wrong in its innards?

 

[Matlib]

That other junk is never going to work properly, so I wouldn't be too worried about X disappearing.

 

[birdie]

If you've ever wondered what concern trolling looks like, birdie delivers a pretty clear and transparent example of it.

However, this trolling spawned a useful and interesting discussion, probably much to the initiator's distaste.

Spoiler: A bit off-topic only meant to be seen by a single person

I don't understand why offtopic remarks and ad hominem continue unabated in this thread.

The f-k it matters how many posts I have here?

The f-k it matters when and why I signed up?

The f-k you know about me? Nothing.

I've been using FreeBSD on and off for almost 25 years. Does that count? Why should I have signed up earlier or participated in these forums at all? Why do you care and why are you so invested?

Could you just stop with this sarcastic and highly offensive crap? It's the first time in my entire life that people instead of sticking to the topic are discussing the OP instead.

 

[sidetone]

While the poster only came to this topic, some of the accusations are a bit unwarranted. As long as the person isn't causing issues to people and so on, who cares why they're here. A lot of good came from this discussion.

Sometimes, I'll watch something I have an interest in for years, and not have an account, then when there's something I want to comment on or contribute to, I'll make an account.



Back to Wayland and Xorg. We don't need Wayland in the foreseeable future, as a lot of Xorg applications still need X, and a lot of fundamental parts of Wayland are broken, such as screensavers. When, they fix those parts, an X compatibility layer can be run on Wayland. The way the Linux community is, they may never fix that, and pile on junk before they fix it. It seems like an alternate way of Xorg may be formed. If an Xorg fork can run Wayland compositors or similar, that will be better. It's time for a BSD style Xorg fork anyway.

Xorg is still fundamentally needed, and the problem is that it adheres to legacy applications and hardware due to its rules. If Wayland can be hosted at the Xorg project, so can the BSD community fork Xorg.

2023's Moments That Marked the Open-Source World

2023 in review: The most remarkable events in the Open Source ecosystem that shaped the year. Let's recall them!

linuxiac.com

Xorg has been the cornerstone of graphical display in Linux for decades,

Xorg’s architecture, designed in the 1980s, struggles to keep pace with modern graphical requirements, particularly regarding security and efficiency.

Better off forking, trimming and fixing Xorg to be modern. Improving this is what we need than Wayland, and why not use concepts from Wayland, while remaining as an Xorg fork.

 

[scottro]

I hope that's what happens. This thread got me interested enough to try a couple of Wayland managers, labwc and dwl, (openbox and dwm replacements), and while they worked, they both had various glitches, which I didn't care enough to try too hard to fix. For example, dwl ignored some of my custom keyboard shortcuts in config.h and labwc doesn't seem to resize windows the way I'm used to, though most openbox shortcuts in my working rc.xml worked.

 

[astyle]

Y'know, I can also 'concern troll' about 'Concern trolling', and ask about the future of FreeBSD Forums (and FreeBSD itself) considering that there's a load of users who don't understand what Open Source is about, fail to see the forest for the trees, don't know how to do research to solve their own problems, and the like.

If OP has specific technical questions about Xorg / ZFS / whatever configuration, the Forums are a fantastic place to come for pointers. But what if I ask, "Hey, there's plenty of people complaining about the fact that their favorite Open Source project is no longer in active development, what should we do about that?". Frankly, just let it rot on the Internet. ?

This thread probably belongs in the 'Off-Topic' section of the Forums by now.

As a reminder to OP about how things work:

• FreeBSD and Open Source are a largely DIY thing. If you don't like the defaults you get, you can always get the source tarballs, edit them, recompile, and get things to work your way - the best you know how. Or you can look for something other than Xorg to work on YOUR machine.
• Dependency hell will always be there. Yeah, Xorg has its fans who accept the downsides. But there's also plenty of people who are actively looking for viable alternatives to Xorg.
• Sometimes, people do have the skills and motivation to join a project and actively contribute. Yeah, it can be a long process just to get a handle on the project's processes, and to use those without messing things up for everyone else.
  • I think that it's probably people who are actually involved with a project long-term who are even in a position to be concerned for the project's long-term future. As in - it's appropriate for Xorg's devs to be concerned that Wayland is gaining steam for good technical reasons, but how much does that even matter to the end users like us?
  • I think that Xorg will probably go the same way as telnet. Telnet was useful in its heyday, but eventually replaced by SSH because it's better suited for the task.
• BTW, what's the problem with setting up FreeBSD as a headless server? it's not your personal hardware, if somebody else wants to do it, why would you tell them that's a bad thing? ?
  • Well, we do point it out if an idea happens to be a bad security practice or a bad backup strategy... or if the idea just won't give the expected results.

 

[Cath O'Deray]

… (HI major) KDE bug 78871, which will never be fixed for users of X11? …

Defocusing from KDE: how many other significant bugs exist, for which the answer is (or is akin to) "use Wayland"?

… Better off forking, trimming and fixing Xorg to be modern. …

Realistically: where developers' attention has shifted to Wayland, will that attention return to X11 in addition to Wayland?

 

[kpedersen]

Realistically: where developers' attention has shifted to Wayland, will that attention return to X11 in addition to Wayland?

Developers don't focus on display system. They focus on toolkits like Gtk, FLTK, etc.

For example, most open-source guys have no clue what macOS truly uses underneath for a display system and yet stuff tends to be ported to that fairly easily.

 

[Jose]

Y'know, I can also 'concern troll' about 'Concern trolling', and ask about the future of FreeBSD Forums (and FreeBSD itself) considering that there's a load of users who don't understand what Open Source is about, fail to see the forest for the trees, don't know how to do research to solve their own problems, and the like.

Nah, you have a long posting history; and though I often disagree with you, you come across as sincere.

 

[sidetone]

Realistically: where developers' attention has shifted to Wayland, will that attention return to X11 in addition to Wayland?

A lot of drivers are shared from Xorg to Wayland, so that will be shared until they decide to change it enough to make it incompatible. There's communities which need Xorg, so they would be part of the fork. Modernizing, and trimming away legacy parts should make it easier to maintain. There's people at Xenocara who could help too.

As long as screensavers and other components don't work on Wayland, there will be a need for a Xorg or a better Xorg fork. And as long as those components don't work on Wayland, developers may come back to a better project. So, if we have an Xorg fork, why not have a layer for some Wayland components or compositors.

Developers don't focus on display system. They focus on toolkits like Gtk, FLTK, etc.

For example, most open-source guys have no clue what macOS truly uses underneath for a display system and yet stuff tends to be ported to that fairly easily.

That will also help, which I didn't think about. Making programs on top of other Xorg clients like libxcb or libx should also help to a lesser extent. With those, there would be common developers maintaining those for XWayland.