cycloptic

I don't know of any significant applications that are Wayland only. If that ever happened, someone could just make a really simple Wayland server that does the reverse of XWayland.

It's not clear what that would solve, XWayland mostly fulfills that role already. It can't run window managers, but you wouldn't really get that everywhere from adding another Wayland extension either -- doing that would require a lot of additional code and the GNOME and KDE implementations wouldn't want that anyway because they have their own built in window managers. So maybe you could get a hacked up version of Weston that can run X window managers, but why bother dealing with maintaining that instead of just maintaining X? It's unlikely the X server will stop working as long as you have a GPU that supports GL or Vulkan, the glamor/modesetting driver should continue to work there.

Or perhaps by then we will have moved onto another protocol that's even simpler.

Look, you're a smart and accomplished person and you have some developed ideas of how thing should be done, please don't hate on other open source developers or accuse them of being "idiots" or "CADT" when you yourself acknowledge that you don't fully understand their work. If you have an idea you think is better then you can just do it, you don't need to trash talk other people's work and use insults like "attention deficit teenager" to get your point across. If you want your X programs to continue working, you don't need to write a Wayland compositor, you can just keep using X. The only reason to write a Wayland compositor would be if you wanted to use Wayland clients, which would not have access to any of the X protocol features anyway.

If you don't care about policies then all those things in X can be a good thing, but if you do care about policies then Wayland could allow for a better design, at least it seems that's what GNOME and KDE are aiming for anyway since their policies are very well established at this point, and they don't really seem to care about breaking ICCCM and other such things.

As for dbus, your solutions would work for some things, but would not have exactly the same semantics as dbus and would come with their own set of issues, and requires building several more infrastructure pieces, some of which you just described. You could build those but it likely wouldn't fit the same use cases as dbus. If you're sending messages that you expect other clients to parse then you still need to agree on a wire format and marshaling library, you can't get around that. If you ask me dbus itself doesn't require much infrastructure at all, you should consider reading the source code for the dbus reference implementation at some point because it's actually pretty small and stable. And I don't understand what you mean by re-implement POSIX IPC analogues, dbus is essentially just a wire format for Unix domain sockets and a message bus that routes the messages, it doesn't re-implement anything. If you want to use dbus from shell scripts, you can use tools like dbus-send and busctl, or you can try to use something like that dbus fuse filesystem -- the nature of dbus makes it map pretty well to that, there's no reason you can't have both a message bus and an easy interface to access from shell scripts.

(Also just another nitpick here, the systemd developers are not the dbus developers, and systemd-logind doesn't take over the init process, that is its own smaller daemon)

If you want to read more, see some comments from the original dbus author:

https://news.ycombinator.com/item?id=8649459

https://news.ycombinator.com/item?id=8648995

Sure but that's not any different if your application depended on some other GNOME or KDE specific API. If KDE decides an API is KDE only and GNOME doesn't want to make their own implementation then there's not much that you could ever do about that. The point with using a toolkit is that it's an abstraction layer that handles the differences between window systems and implementations for you. It would be better if you mentioned the specific reason why your app is breaking because that would likely be a bug in the toolkit.

You asked if other X servers are used, there are other X servers that are widely used outside Linux (Xquartz, Xwin, etc) which would break if the clients required DRI3.

Libwayland is a small library carrying the implementation of the wire protocol, and a few other bits like a simple event loop for servers and a library that can load X cursors. The point with that is that you're bringing your own compositing and multiplexing anyway. From there it's optional if implementations want to put in additional features for IPC, window management, hotkeys, screenshots, etc, and they can choose if they want to put that in the server or put it in a separate program. So you can still mix and match on some level anyway, it's not quite the same though.

I had exactly the same idea as you a few years ago to build something like that and I thought it would be useful too, and I thought about it for a while and realized that it doesn't really give you any of the benefits of Wayland or the benefits of X11. The point with wayland is already that it strips the unnecessary bits out and maintains a legacy code path with XWayland, and the point with X is that it's always going to keep the legacy code running anyway, so you don't gain much by combining them. If you have a minimalist window manager that's only a few thousand lines of code, and you want to get the benefits of Wayland, it's much easier to just port that using wlroots or something than it would be to rewrite the whole X server. That's just my experience.

>Sounds like a problem with the particular extension, not X11.

Since this is an issue with Xorg lacking the right extensions it's basically the same thing.

That's not really a reasonable comparison here, because option 2 has already mostly been done, for other reasons.

That's only if you're using functionality specific to the DE, which is handled mostly the same as it is under X. GNOME and KDE for example tend to provide their functionality as dbus services. If you just have a simple app that needs no special privileges or features then that will work just the same. If you use GTK or Qt, the transition will be mostly seamless and would only be a problem if you were circumventing that and calling Xlib or xcb directly.

AFAIK DRI3 is also Linux-only and is not supported on any X server outside of Linux.

In Wayland those tasks have been split out into libraries. The details of the protocol IPC is handled by libwayland, the input is handled by libinput. Screen multiplexing is specific to the compositor and not really something you can farm out to a library, which is the same as composited X where the compositor process takes over the entire screen and handles all the rendering.

It would be interesting if someone combined an X server with a Wayland server like you described, but I don't think it would be useful. A lot of your legacy applications would still be broken, for example no old clients or window managers are rendering using DRI3. If you want to design an extension for client isolation, the problem there isn't that X doesn't have that but that the existing methods don't really work well. My suggestion there would be to talk to any desktop environments to find out what their requirements are, if they haven't already committed to switching to Wayland already. (i.e. GNOME and KDE already have their solution for this in Wayland) It may be that an additional X extension is unnecessary for what the other desktops require.

What you're saying is mostly what has happened already except the work has just been done outside the X server. The features in X that people don't use are already considered deprecated, and factoring the legacy parts off into a separate code module is essentially what XWayland is anyway.

If you added all those things as X extensions, it would essentially be the same thing as Wayland, because clients that wouldn't use them would still be broken, and every graphical program and toolkit would still be need to be updated to use them.

Your suggestions for dbus would work for some applications but would not really work for other things that a message bus handles like multicast, global message ordering, and resource accounting. Plus GNOME and KDE adopted dbus specifically so they could get away from having to pass around random sockets in folders everywhere. I assume by "put-it-in-the-kernel-because-performance development ideology" you're referring to kdbus, which was an alternate implementation not made by the original dbus developers, and is now a dead project and is not really a thing anymore. Please don't get those things confused. Of course the reason they could do that is because dbus is also just another protocol with a reference implementation, and you could make another implementation that works closer to what you describe and maybe gets 80-90% of the way there depending on some changes in the kernel, for example I saw a hacky dbus fuse filesystem a while ago: https://github.com/sidorares/dbusfs

The basic idea of Wayland is that it is a simplification and streamlining of a display server protocol. The work of designing that core protocol is already done and doesn't need to be done again, the original developer likely did it because they found it interesting or useful to work on in some way.

The situation isn't that much better in X, the window manager and desktop environment can break clients in other subtle ways that have nothing to do with the X server. There's no guarantee that graphical programs would always work if your setup does something strange.

Not really, it's the same amount of work either way considering this doesn't exist yet.

Is that any different from normal? In my experience, if you're shipping a product on a Linux-based desktop, usually you target a specific set of distributions, i.e. the default configuration of the last few LTS versions of RHEL or Ubuntu or whatever, which at least for those examples all happen to be GNOME based. Customers who come with some weird hacked-up distribution would be on their own for support anyway, they can try it but there's no guarantee it will work. If KDE (or something else) really is doing something different here then you would have had to extend the same amount of effort as you did previously.

That's one of the things Wayland was designed to do, of course implementations can build other things around it that allow privileged clients to break client isolation. The effort could have been put into X11 but it seems the people interested in this would rather put that effort into Wayland.

I don't understand what you mean. You can still continue using X if that's what you want, people deciding to spend their time developing Wayland doesn't somehow break X or make it worse.

Also just FYI, it seems x.org has merged with freedesktop.org so they are mostly equivalent at this point, being run by the same group of people.

There are X extensions for shared memory buffers. Client isolation for X could also have been implemented as some kind of extension. With both of those you could solve some issues but it still wouldn't be the same as redesigning the core protocol.

If you are expecting every Wayland server to implement things exactly the same way, that will probably not happen, the point with having different implementations is that they can choose which parts they want. It's currently not looking like there will be any one standard-definer, you can build a monolithic implementation if you want but you don't have to. Yes this might cause some fragmentation but realistically, has X really helped there? The huge proliferation of clones and forks of various X window managers that are incompatible in various ways is another kind of fragmentation.

You could do that but such an X server would not really be any practically different from Wayland. You would still complain that it broke your old clients, and newer clients would still have to maintain two code paths for the newer server and for the X servers that didn't support DRI3. (DRI3 is not supported when running X clients over the network for example)

You really should consider watching the youtube talk that was linked in some sibling comments, it explains it in more detail than I could in just one post. For me personally, the real bad issues are things like the core protocol being synchronous, the coordinates being limited to 16-bit, the inherent raciness and insecurity of various things like window properties and server grabs... There is a lot of legacy functionality there too like colormaps, window borders, bitmap fonts, all the core drawing primitives, all the core input stuff.... Newer applications are not using any of that, and often with that legacy stuff the the only specified behavior for edge cases that clients expects is "do whatever Xorg does" which makes a rewrite pretty impractical. It would be interesting to see a secure rewrite of the X server in Rust or some newer language like that, but doing that would probably take many years for little benefit, I'd advise against it.

Side note, I don't get the hate for dbus, it's a rather simplistic message bus, orders of magnitude smaller than the X server. It would be much easier to implement your own dbus daemon for example.

No, the hard part is building a good API and user interface that works for everybody. IMO that's mostly why there are a lot of half-finished and inconsistent things like that X11.

Someone could build a combined Wayland/X server in the same process like that, but why? The only reason you would need to do that would be to run Wayland clients natively on your X server. IMO if you want to use Wayland it is much easier and more valuable to just port those tools. The hotkey daemons, screenshot tools, and command-line clients are pretty small and not that hard for someone to rewrite as a weekend project, people have done a lot of that already. The harder part is the window managers, but if you're a hard-core window manager author used to doing things the X way then you won't see much reason to switch anyway.

Wayland doesn't have the equivalent of XGetImage for various reasons, but screen capture applications can use the ScreenCast flatpak portal to select window sources: https://flatpak.github.io/xdg-desktop-portal/portal-docs.htm...

I am not sure what you mean by Wayland can only be used sanely with toolkits, any GUI usually need a toolkit or some equivalent, even under X. if you are not using a pre-existing toolkit and are writing your own routines to draw buttons and text boxes and such, that would be implementing your own toolkit.

That's mostly a misconception, Wayland implementations don't need to start from scratch. Weston and wlroots are minimal from-scratch implementations, but GNOME and KDE for example do their implementations by re-using most of the code from their X compositor.

There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.

I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server.

Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

The main problems with X11 are within the core X11 protocol itself, things that are long considered deprecated/obsolete and can't be fixed or removed without doing a protocol break. I could go more into detail, but if you depend on some old X clients that use all those old protocol features, and you're already committed to putting money down on X11, it seems unlikely that those details would be relevant to you. Please let me know if I'm reading this wrong here. I support you working on X11, but just be warned, it is highly unlikely that the major desktops are going to want to continue on that path going forward.

There isn't much difference there, but it would be more of an uphill battle if you tried to put everything different that Wayland does into X extensions. That still requires maintaining an extra code path for old X servers that don't support the new extensions, and creates additional risk of breaking things and causing regressions in the X server because of all the new code you're adding.

Clients like term, xpdf, and xfig should work fine in XWayland. Window managers won't work without getting ported, but someone has been working on a port of Openbox: https://github.com/johanmalm/labwc

Can you be more specific about what are you comparing this to? An X client with similar functionality would likely be longer and require several X extensions.

I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.

There is a wayland protocol called presentation-time that's supposed to provide precise timing information to clients, GNOME just merged support for it two days ago: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1484

(AFAIK random clients should not really be using this though, the intent is for it to get used internally by the GL/Vulkan implementation)

There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.