X.Org Server Development Hits A Nearly Two Decade Low

[betam4x]

Gusar Don’t like fragmentation? Then stop NIHing wayland desktop compositors. It’s that simple.

Just because it’s fun to start yet another compositor project doesn’t make it smart or something that Mutter should deal with.

There’s no cross compositor community. Because there’s no benefits or any needs.

IMO the decision to allow multiple compositors was the biggest mistake. There is no need for multiple compositors. One compositor, written properly, can do it all. Instead we end up with tons of rewrites and forks. Folks on the Wayland team should honestly focus on a reference compositor (if none exists, outside of the bugs that exist I don't follow Wayland development all that much). Once it is mature enough, I imagine most DEs would switch to it.

[ssokolow]

I see the architectural problems in X and would like something "better". But I do not see wayland being there (or anywhere close) yet. Plus, I also don't think the design choices for wayland are good ones. IMHO they should have taken a plugin based approach and defined proper APIs to deal with them, so GTK and QT can hook into it and the DEs can do their stuff. (e.g. plugin a "service" that deals with window decorations so the applications DO NOT have to deal with that shit themselves unless they really want to, in which case they simply could set a flag like "undecorated" and render it however they like.)

Whatever ... We'll see where it goes.

That's what they're doing.

The Wayland core protocol defines stuff common to all use-cases, including things like In-Vehicle Infotainment and Smartphone UIs, both of which it is seeing use in. Things for task-specific situations (such as multiple overlapping windows which can be moved and resized) are then extensions on top of that.

There is also a solution for a window decoration service. That's why SDL windows have proper decorations on KDE if you're running an SDL new enough to have implemented it. The GNOME devs have just decided to be petulant children and declare that "No, you're doing it wrong. We're not implementing the extension to negotiate for SSD and, if your windows don't have decorations on GNOME, that's your fault for not implementing client-side decorations."

(Which is why you're now starting to see non-GTK, non-Qt things like SDL and mpv implementing the bare minimum necessary to be able to say "They function. If you want them to be attractive, go bug GNOME about their decision to not implement the relevant standards.")

[betam4x]

I'm currently reviving a tool I maintain named QuickTile which is a clone of a tool named WinSplit Revolution which monkey-patches the desktop to add intermediate window-tiling support to any WM. (More advanced than Aero Snap and its many clones, less advanced than a real tiling WM)

Likewise, there are various popular Windows and Linux tools which implement things like input macros which are at odds with any security model which attempts to preclude keylogging.

You don't have to be a programmer to want functionality that depends on monkey-patching under the hood.

Input macros implemented properly shouldn't require monkey patching. Key-logging is only an issue on various systems due to the ability for an app to listen to keyboard events outside it's own scope. While one can argue that this may be useful in some scenarios, a secure system would not allow this. Just like a secure clipboard implementation would not allow applications to peak at the clipboard.

What's funny is that Xorg could easily implement many of these security related changes, along with many other changes, all while avoiding causing too much of a headache with compatibility (and since you can run Xorg nested, compatibility is a moot point).

I used to be all hyped for Wayland, but after seeing many of it's initial shortcomings, and suffering through compatibility issues, I am now wondering if we should have just worked on refining Xorg.

[tildearrow]

Oh wow I forgot to mention o-o

Drive-by hacking, short term contractors and weekly blogs won’t cut it in the Age of Wayland.

Guys. This subliminally refers to KDE (hint: Nate posts one report about it in his blog every week). This troll is at it... again.

So he is actually saying the following piece of trash:

KDE won’t cut it in the Age of Wayland.

)*#5;7)'614:4@72?"&4@?*3@'@57?'@5'5!!!!!

[CochainComplex]

GNOME defaults to wayland for several releases already and distributions (Debian, Fedora,...) are not switching back

ok true. but the major players like ubuntu and al their "forks" still dont have wayland as default.

[CochainComplex]

I've been using Wayland on all of my physical Linux systems since about 2016. It's been solid.

As far as I can tell everyone who doesn't use Wayland is using Nvidia or has some strange edge case I would have never imagined needing.

i have used it on my old intel igpu laptop and there it was also very stable.
But as you mentioned nvidia has a rather high market share. Plus one of the most used Distribution and its derivates Ubuntu does not use it by default.
And Distros like Debian just recently added it as Default so LTS Versions of any Distributions are most likely not affected yet.

[DanL]

Guys. This subliminally refers to KDE (hint: Nate posts one report about it in his blog every week).

It's a very thin veil, especially given the troll's penchant for shouting, "GNOME way or the highway!" in as many threads as possible. In fact, some guy named DanL pointed out that it was a KDE reference in post #27.
Note that it's extremely "cute" that the troll still thinks X.org is a GNOME project and is unwilling/unable to understand the concept that X.org is upstream of GNOME, even after X.org devs tell him to STFU.

[240Hz]

I gave Wayland a try very recently (Gnome 3.34.2) and it is still very buggy. For example when using Telegram, the notifications steal mouse cursor focus as they appear which is extremely annoying and does not happen on X. While its "pretty usable", it still has many bugs, annoyances that get in the way for no benefit. The only positive thing I can probably think of is Firefox feels a bit smoother in wayland mode, however in Wayland the Chromium vaapi hwvideo acceleration patch doesnt work..

Also, Gnome is still very stuttery, especially the cursor movement.

[CommunityMember]

ok true. but the major players like ubuntu and al their "forks" still dont have wayland as default.

Especially for their LTS releases, Canonical has prioritized stability and device support over features for their default configurations. While wayland works well for many, and device support is constantly improving, Canonical has made the decision that there are too many edge cases for something they are contracted to support for 5 years. Given that Canonical is still working to find a long term profitable business model, keeping the paying customers as happy as possible is likely their best approach, and today that means x11 as the default.

[Gusar]

IMO the decision to allow multiple compositors was the biggest mistake. There is no need for multiple compositors. One compositor, written properly, can do it all. Instead we end up with tons of rewrites and forks. Folks on the Wayland team should honestly focus on a reference compositor (if none exists, outside of the bugs that exist I don't follow Wayland development all that much). Once it is mature enough, I imagine most DEs would switch to it.

I don't think you realize that compositing and window management are tightly integrated in the Wayland world. So there cannot be "the one" compositor. Not acceptable for KDE to be required to use a GTK compositor or vice versa. I suppose you could go lower-level than toolkits. But even then there are problems, see bellow.

At some point the Wayland devs started to think like you do and turned their reference compositor into a library, libweston, which could be "the one" that other devs would use as a base for their compositor. But not only did libweston come too late (several compositors were already written), it has shortcomings, it basically forces you to do things in a certain way, you can't do anything the weston devs didn't foresee someone would want to do. Here's all the details about it from the wayfire developer: https://wayfire.org/2019/02/24/X11-W...n-Wlroots.html

Going from that above blog post, wlroots could be "the one", and in fact most non-Gnome, non-KDE compositors do nowadays use wlroots, but it's very likely not even wlroots can do everything, or it does things in a way a developer may not like. For example, while wlroots gives you a lot of freedom, this brings with it complexity. A developer of a small compositor may not want to deal with the complexity themselves, they may prefer a library that does more things for them. Hard to define a "one size fits all" solution.

So the solution isn't "the one" compositor, it's to expand wayland-protocols and make compositor devs stick to it. As I wrote in another discussion recently: With proper standards and well-defined protocols there can be as many compositors as people feel like creating, and it won't cause fragmentation because the protocols will ensure interoperability.