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

[sidetone]

Phishfry, I think that Alain De Vos has something on the forums about his experiences with [x11-wm/labwc]

Thread starting-labwc-wayland-script.86122
Thread wayland-labwc-sway-found-0-gpus-cannot-create-backend.87837

x11-wm/labwc even accepts openbox configuration…

Thread how-to-configure-a-labwc-openbox-theme.86268

Those are his threads, there was another one from him on nesting a Wayland session on top of traditional X11, but it didn't have details on doing that. He has several more on Wayland.

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

x11-wm/dwl - dwm for wayland
x11-wm/somebar - dwm-like bar for dwl
x11-wm/sway and a few more sway related ports

 

[cy@]

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?

My laptop's HD3000 uses the i915kms driver.

I know very little about Arm. But if i915 on Arm works with X it should work with Wayland.

 

[angry_vincent]

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.

there is - dwl https://github.com/djpohly/dwl
x11/dwl

 

[Cath O'Deray]

x11-wm/dwl - dwm for wayland

x11/dwl

(The earlier link was correct.)

 

[scottro]

Even if the link was wrong, thanks angry_vincent. One of these days, I should give it a try, but like many others in this thread, no need to at this time. Good to know though. (And sidetone, I put in a thanks for your post too, of course).

 

[angry_vincent]

sorry, correct place is x11-wm/dwl not x11/dwl

 

[ThomasAdam]

The FVWM chief dev said he has no interest in supporting wayland. So the question is answered for me: Wayland? No, thx!

I may have been being flippant, I can't recall, but it's certainly possible.

In all serious though, this answer is unfortunately rather black-and-white for a window manager such as fvwm, and that comes down to the following points:

• Xlib renders everything server-side, meaning it has low-level library calls for specifying shapes, colours, shading of rectanges, etc. Wayland has... nothing like that. So the look-and-feel for those older WMs on XOrg which use xlib to render windows means there's no equivalent on Wayland.
• Widget libraries are preferring CSDs (Client-Side Decorations) which means, Server-side decorations become harder to do/impractical.
• There's nothing like the concept of reparenting in Wayland, which is what fvwm is -- a reparenting WM -- whereby the window drawn by xlib is a container for another window into which it is reparented. This allows for titlebars to have all manner of different buttons based on the capabilities of the application. So motif-aware windows would have capabilities for certain operations which you could query for via XAtoms, and allow the parent window to react accordingly.

So right now, in Wayland, everything is rendered as client-side. So the look-and-feel of windows and everything else will look very similar to one another. If you look at what wlroots provides, it has some notion of what you can term server-side decorations, but that is not the same as reparenting -- rather, a literal box is drawn around the window to give the illusion of a window as you might think of it -- but there will be positioning bugs trying to move the "client" window and the server-side window properly.

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. What RH have done at this point is nothing more than a publicity stunt which is designed to let the rest of us know what to expect -- it's their way or the highway. Trouble is, every other Linux distribution will follow suit quite quickly as they'll have fewer options.

In terms of parity at the moment with a Wayland compositor and Xorg, I know XWayland exists as a shim to running xorg applications on Wayland, which would allow fvwm to run all the existing X apps just fine (x11cp.org for instance, ahem), but the nail in the coffin for having to use Wayland, regardless of whether your existing WM is even available on Wayland, is going to be when the widget libraries themselves drop support for xorg. When this happens, applications using such a widget library would be unable to compile on top of xorg, hence they'll become Wayland-only.

So for me, the current situation with Wayland is unimpressive and frustrating. To say nothing of reducing choice. One of the reasons I like using fvwm so much is because you can make it do all sorts of weird things. But Wayland makes that option harder to obsolete in some cases.

I'm giving serious thought to seeing if I could keep xorg alive myself, but that seems like a fool-hardy and dare I say, arrogant thing to say. But I am thinking about it...

 

[astyle]

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.

I think that a given window manager's visual behavior is something that you can set in a .conf file, rather than hard-coded into compiled code. So if you like the look and feel of a stackable WM like x11-wm/icewm or a tiling WM like x11-wm/i3, there's probably a Wayland compositor that can be set up like that, too. x11-wm/wayfire is a very simple but highly configurable Wayland DE that I can confirm works. And in the last few months, the Handbook got updated to include some pretty good instructions on how to set up Wayfire.

 

[ThomasAdam]

I think that a given window manager's visual behavior is something that you can set in a .conf file, rather than hard-coded into compiled code. So if you like the look and feel of a stackable WM like x11-wm/icewm or a tiling WM like x11-wm/i3, there's probably a Wayland compositor that can be set up like that, too. x11-wm/wayfire is a very simple but highly configurable Wayland DE that I can confirm works. And in the last few months, the Handbook got updated to include some pretty good instructions on how to set up Wayfire.

It's not the same thing -- it's the loss of what xlib is providing in terms of the ability to draw windows directly, which Wayland isn't providing as everything is client-side. It's the way you're able to do this with xlib now which is not being provided on Wayland, so fvwm suffers because it wants to be a reparenting window manager, and it cannot be.

 

[astyle]

It's not the same thing -- it's the loss of what xlib is providing in terms of the ability to draw windows directly, which Wayland isn't providing as everything is client-side. It's the way you're able to do this with xlib now which is not being provided on Wayland, so fvwm suffers because it wants to be a reparenting window manager, and it cannot be.

yeah, the re-parenting part does need to be re-done for Wayland - but I'd think that to the end user, the visual effects are more important than programmatic technicalities. If a dev (or a group of them) has enough talent and interest, nobody's prohibiting them from getting creative and releasing a project that involves object re-parenting in a Wayland compositor. Working proof-of-concept is always welcome in Ports, iirc.

 

[ThomasAdam]

yeah, the re-parenting part does need to be re-done for Wayland - but I'd think that to the end user, the visual effects are more important than programmatic technicalities. If a dev (or a group of them) has enough talent and interest, nobody's prohibiting them from getting creative and releasing a project that involves object re-parenting in a Wayland compositor. Working proof-of-concept is always welcome in Ports, iirc.

Well, the only library I'm aware of at the moment which comes close to what is provided by native xlib for 2D drawing, is libcairo -- but that doesn't have the same functionality as now in terms of drawing routines compared to xlib.

Again though, this is all a moot point until something changes, and I'm not sure what that something is yet.

Heck, I'd be more than willing to do it myself if I knew what direction things were heading in.

 

[kpedersen]

An interesting analysis in general.

I'm giving serious thought to seeing if I could keep xorg alive myself, but that seems like a fool-hardy and dare I say, arrogant thing to say. But I am thinking about it...

I don't believe it to be impossible. I am very happy to invest time into it too if it comes to it. I certainly feel I could at least maintain the modesetting stuff (which is pretty much the only driver of interest these days). Combined with other like-minded luddites, I am sure we will be fine.

The challenge is probably *writing* support for X11 in Gtk for downstream software going forward. I am fairly sure that the RedHat/freedesktop will gleefully pull that out as part of an overreaching power-move. We need to be able to reinstate it and maintain it.

I am also thinking some sort of shim or compat layer that makes Xorg look a bit like a Wayland compositor where the Gtk layer is concerned.

(Gtk isn't the only one. But I focused on that because the codebase is shit and also entwines with far too much other cruft).

Heck, I'd be more than willing to do it myself if I knew what direction things were heading in.

I think the entire ecosystem is stuck in limbo for the same reason. There has been few innovations (or even cleanups / maintenance) in the Linux desktop space for almost half a decade because of this. Just a shame this happened shortly *after* Gnome 2 was broken from ports

 

[ThomasAdam]

I don't believe it to be impossible. I am very happy to invest time into it too if it comes to it. I certainly feel I could at least maintain the modesetting stuff (which is pretty much the only driver of interest these days). Combined with other like-minded luddites, I am sure we will be fine.

I think so, too.

The challenge is probably *writing* support for X11 in Gtk for downstream software going forward. I am fairly sure that the RedHat/freedesktop will gleefully pull that out as part of an overreaching power-move. We need to be able to reinstate it and maintain it.

We could libify this to provide a compat layer. We'd need to know the current wayland calls and their corresponding Xlib ones. That's an over-simplification but it would work. Similarly for things like damage "events" on Wayland would map to expose/configure events in Xlib.

I am also thinking some sort of shim or compat layer that makes Xorg look a bit like a Wayland compositor where the Gtk layer is concerned.

(Gtk isn't the only one. But I focused on that because the codebase is shit and also entwines with far too much other cruft).

Depends. You could go either way -- it needs more thought...

 

[kpedersen]

Depends. You could go either way -- it needs more thought...

Very likely.

Though I would actually be hesitant to go the other way. The Wayland ecosystem is such a volatile wild-west that even considering a compat / shim Wayland compositor drags you right into the messy treadmilling on wlroots and all the other poor foundations that the ecosystem is currently thrashing around with.

Until the main compositor implementations (Mutter, KWin, sway, Weston) use some sort of shared foundation, I would even suggest that "Wayland" as a technology does not yet actually exist as an implementation. Merely a bunch of 4 different pilot studies.

 

[Phishfry]

I have been playing with X -retro again and it is the quintessential blank canvas.

 

[sidetone]

I'm giving serious thought to seeing if I could keep xorg alive

That would have to be a group effort, maybe with someone spearheading it. Every computer user and project is going to have to use a traditional graphical toolkit, since so many programs are built on them, and aren't going away

The Wayland ecosystem is such a volatile wild-west that even considering a compat / shim Wayland compositor drags you right into the messy treadmilling on wlroots and all the other poor foundations that the ecosystem is currently thrashing around with.

Weston is old and more of a learning tool for the ins and outs of Wayland by now. BSD and co can have its own implementation of standards for a compositor, and different implementations (perhaps modular parts of libx and libxcb libraries) to replace XWayland.

Until the main compositor implementations (Mutter, KWin, sway, Weston) use some sort of shared foundation, I would even suggest that "Wayland" as a technology does not yet actually exist as an implementation. Merely a bunch of 4 different pilot studies.

The shared foundation is among the graphical toolkits, which is relevant for the programs which use them, not the compositors.

Wayland is modular, it's about both the compositor libraries and the toolkits for it, which a toolkit would be independent of the compositor. No matter the compositor, and what works for its libraries, the graphical (library) toolkit would be universal across those compositors, regardless of those compositor libraries. So, if you had an application which ran on a gtk Wayland toolkit, it's meant to work across various compositors, regardless of how incompatible those compositor and compositor libraries are, because the toolkit plugs in across the board, in addition to the compositor. Wayland is meant to use the graphical toolkits.

In other words, it doesn't matter how incompatible compositors and their libraries may be to each other, the graphical toolkit links them all to Wayland for programs as long as they run on top of that particular existing gui toolkit. The graphical toolkit can also be about X11 layer shims as well.



A chart of the current toolkits and X11 implementations would help for everyone involved and spectators. It would mean taking a look at current toolkits for X11, and their licenses. gtk2, gtk3 and gtk4 use the same lgpl2.0 license. There could be a fork and/or a merge of these gtk toolkits, with options for differences of each style, then turned into a compositor. The Vala part of gtk can be dropped, and libx parts could be replaced with libxcb for better simplicity and a common layer. We look at what toolkits everything runs on or the best version of them, gtk2, gtk3, qt5, libxaw3dxft, plus libxcb and libx. qt5 runs on top of libxcb, and for all programs, the lower levels of libx now run on top of libxcb. libxaw3dxft could also have libx parts dropped in exchange for libxcb.

I believe planning needs to be put out on diagram charts, of how the toolkits and existing applications plug into the shims, and perhaps into more detail. It needs to be considered how libx runs on top of libxcb, and using libxcb where possible for toolkits and programs which run on x, without toolkits.

If a compositor or toolkit doesn't offer a low enough level, maybe those parts need to be forked, with a descriptive or depictive plan on how that will be, for the ecosystem of software which still will stay with X11. libxcb replaces a lot of need to calls for lower level for libx, as many aren't needed. A chart, of what the desire to hook into lower level and being limited to those where it's wanted or necessary which may not be in Wayland may be needed.


As for the panic and commotion, there's too many operating systems, users, and too many programs which use older toolkits which won't be abandoned, and those communities will come together to have their own way to run X11 applications, whether on Wayland or some hybrid X11 on Wayland pieces. It's just a bunch of thumping and scare, because that community of programs isn't going to expire overnight or in the next 10 years. I would like to see an X11 compositor on top of Wayland or something modular like that, because it's cool, not because of Redhat and Wayland fans thumping, and everyone else panicking due to it! Can this pointless panicking please stop.

 

[Cath O'Deray]

I believe planning needs to be put out on diagram charts,

A nice idea. I can't get the big picture through words alone.

 

[ThomasAdam]

I believe planning needs to be put out on diagram charts, of how the toolkits and existing applications plug into the shims, and perhaps into more detail. It needs to be considered how libx runs on top of libxcb, and using libxcb where possible for toolkits and programs which run on x, without toolkits.

I suppose if I squint slightly, I think what you're saying (albeit via a lot of rhetoric) is you want to understand how such a system would be designed?

Sure, OK -- is this just for educational purposes, or because you would like to contribute?

When toolkits talk about dropping support for xorg (xlib), they do so by referring to removing the rendering backend. In the case of QT and GTK, that would be xlib -- and whether that's xcb under the hood is moot at this point, most pure Xlib calls already call out to their XCB equivalents. But XCB is the "newer" bindings, so they would be used, yes. That being said, you'd still need to support the original Xlib calls at any rate.

Enough of this chitter-chatter. I'll put something together to start this off.

If anyone else is interested in helping, let me know, BTW. Not sure if that's via a direct message here -- I'm just aware I'd rather not hijack this thread too much, although that may be too late...

 

[kpedersen]

If anyone else is interested in helping, let me know, BTW. Not sure if that's via a direct message here

Very happy to help. Sign me up!

I'm just aware I'd rather not hijack this thread too much, although that may be too late...

Not only has the OP gone to sleep, I think this is still very on-topic. Potentially this *is* the future of Xorg.

 

[zirias@]

I'm just aware I'd rather not hijack this thread too much, although that may be too late...

If there's anything of value about this thread, it's this plan/discussion ?‍

 

[Maxnix]

Maybe this will be the birth of a X12?

 

[Beastie7]

Though I would actually be hesitant to go the other way. The Wayland ecosystem is such a volatile wild-west that even considering a compat / shim Wayland compositor drags you right into the messy treadmilling on wlroots and all the other poor foundations that the ecosystem is currently thrashing around with.

Y'know.. after reading this article I retract a lot of the cheerleading I did for Wayland. It really puts things more into perspective about the whole matter for me. I hadn't known how intertwined Mesa3d and Xorg was. There's just too much missing.

 

[Cath O'Deray]

this article

Wayland Isn't Going to Save The Linux Desktop (2022-06-10, eighteen months ago)

Related discussion, begun three days ago: <https://news.ycombinator.com/item?id=38508311>. From the first comment:

… Wayland is simply unusable with Nvidia's junky blobs. …

I have no idea whether that's close to true for that person on (I guess) Linux, but it can't be true, generally, on FreeBSD.

We have someone from NVIDIA working on sleep/wake (suspend/resume). It's reasonable to assume that this work is for a system that can be used before sleep.

Blah, blah, blah, junky, less than fifteen minutes later there's someone blah, blah, blah, proprietary blobs. As if open source is a panacea.

Such nonsense, sometimes, in Hacker News. More or less than elsewhere? I don't know, but it's nonsense.

 

[sidetone]

This is an opportunity to try another approach.

A lot on Xorg is for legacy hardware and software which is out of use, but they keep it, because that's in their mission or some other statement or principle. But Xorg already is allowed to exist with Wayland on the same repository.

Xorg could be forked instead of Wayland, stripping out legacy parts that are no longer used. Use Wayland, Weston and WLroots as case studies for a blueprint. Take parts and ideas from Wayland, to make this fork modular. Determine, when you need applications to hook deep into Xorg, and leave it to that, without adding more unnecessary hooks. Also, see about Xenocara contributions what security measures are as restrictions, but make it easier to set permissions so applications which need them can easily use them. libxcb needs to be implemented into this and existing graphical toolkits more than before. There'll need to be a shim for libx, that will be its own equivalent of XWayland.

Instead of making shims for X11 from XWayland to Wayland, make shims from Wayland compositors and Wayland graphical toolkits to this Xorg fork.

I suppose if I squint slightly, I think what you're saying (albeit via a lot of rhetoric) is you want to understand how such a system would be designed?

Sure, OK -- is this just for educational purposes, or because you would like to contribute?

To try to answer question, it's because I believe, when one plans, everything comes out better, and it adds a process of thinking, which we usually think we know on first thought, and then it makes us think it out and we realize we didn't understand it as well as we thought, and it becomes clearer. It doesn't have to be complex, it could be a scratch sheet.

For instance:
graphical toolkit -> libx->libxcb
libx --> libxcb --> X server
libx shim -> libxcb -> X server
reparenting ---> hooks into X server
other essential feature ---> hooks into X server
Xenocara insipired feature---> not so restrictive that it allows dev and file permissions for drivers, users and software to access it
improved driver permissions, by not being overly complicated to --> X server
drivers --> layer? -> layer? how it interacts with X server
miscellaneous --> API --> X server

Or it would be a more primitive less flashy version of, with additional plans where it differs, such as for re-parenting hooking in, or having its own orange square:

The thought or plan could be completely different, as that's an existing example. For clarity, that diagram is an XWayland example.

I'm no good at programming, but if I could understand something, I could write about it. Also, libxcb didn't catch on, because it lacked documentation. So, it would be important to have a scratch sheet basic diagram that takes a minute to sketch.


As for fvwm, it has become dependency entangled, and there's already forks of it, one which has become a Linuxism. There's other window managers on the same basis of it and are light, like ctwm and other classical tabbed window managers. They have a few less utilities, though the main one missing is the one for the WM dock app.

 

[Cath O'Deray]

… over reactions to red hat announcements …

Related (in response to a misinterpretation):

Alan Coopersmith (@alanc@fosstodon.org)

@vermaden@bsd.cafe XWayland will still be there in RHEL 10, allowing the use of X11 programs. It’s only the ability to use an Xserver without an underlying Wayland compositor that they’re taking away - the Xorg server, not the X11 protocol.

fosstodon.org