[CoastalCoder]

Could someone explain the significance of this for Wayland adoption?

As an outsider to the X11 vs. Wayland discussions, my impression has been that the main barriers to simply ditching X11 have been:

(1) poor Wayland support in nVidia's proprietary drivers

(2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.

Does QtWayland 6.6 address either of those (and/or some other) barriers?

[sho_hn]

> (1) poor Wayland support in nVidia's proprietary drivers

This has improved quite a bit with nVidia eventually implementing GBM support (so compositors no longer need an nVidia-specific codepath, which is nice). I use Plasma on Wayland on my nVidia-powered ThinkPad, and it's generally fine and has been for some time. That said, the nVidia stack does still feel a bit more hit and miss than some others.

> (2) Wayland's security model making some X11 use cases, e.g. screen recording, difficult or impossible.

These largely have been addressed by newer protocols and infra, although application support and maturity for those protocols in deployed systems is still trailing behind X11. Still, the fundamentals have been worked out, and there's steady progress on spreading the solutions through the ecosystem.

And no, this blog post has nothing to do with either topics but is about unrelated technical innovation in the Wayland space.

[FloatArtifact]

Accessibility software needs access to the window details like executable, new title, window size and so forth and to be able to emulate peripherals.

[traverseda]

Well KDE has been pretty good about implementing wayland extensions for things like screen recording, accessibility, etc. Gnome has also been implementing extensions but they tend to go off and do their own thing.

The main barrier is honestly expecting a bunch of unpaid open source developers to go and re-implement everything. Stuff like barrier/synergy technically has the extensions needed to add in wayland support but it's still all unpaid volunteers.

There also used to be some more leeway about protocols and extensions. For a long time now Gnome has been saying "you're either a gnome app or you're not" when they deprecated stuff like tray icons. But there was generally a way back, a way to run your non-gnome app cleanly on Gnome. With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now. There are common desktop extensions that Gnome just isn't really interested in developing.

[tristan957]

> unpaid volunteers

This is not entirely true. A few GNOME developers within GTK/Mutter/GNOME Shell are paid to work on this kind of work at least part-time. SourceHut also pays Simon Ser to do some Wayland work, whether that is maintaining wayland-protocols or something else.

> With the introduction of wayland they seem to be more set on forcing developers to choose, like they really are blocking tray icons now.

This is also not true. GNOME has designs for tray icons in their GitLab repo. The thing that is blocking better tray icons in Linux is a lack of interest in finishing the protocol proposal. The ticket hasn't seen much traction in the last couple of months.

https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...

[traverseda]

I didn't mean unpaid Gnome developers, I meant everyone else. People like this SDL developer: https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3552...

He's certainly not getting paid to make SDL work on Gnome, and I think does a pretty good job of explaining why the proposed solutions from Gnome will result in a poor user experience.

>This is also not true. GNOME has designs for tray icons in their GitLab repo.

Yeah, but every other wayland compositor seems to have gotten it to work already. This is what people mean when they talk about "splitting the linux ecosystem". If they're not able to manage the complexity of implementing stuff like tray icons, things that are really important for cross-platform apps, maybe they should pivot to using a library like wlroots.

[sho_hn]

I don't know about the "on Gnome" part, specifically, but I think Ryan has done work on SDL on contract, or contributed to SDL as part of contract work on e.g. game ports. He's a prolific guy with many stories to tell about the Linux desktop, see https://icculus.org/~icculus/

I do get your point, though, and it's true, there's of course a lot of manhours on e.g. app fixes and porting, and many other things, that happen on a volunteer basis in the community to make it all work.

[traverseda]

Yeah, Icculus' case is a bit odd but also one of the strongest showing this in action. Barrier/synergy/input-leap (or whatever they're calling themselves these days) is another good example, but I can't just link to one polemic thread to get the point across. They've more or less just given up, despite the like 3 grand bug bounty for getting it working on wayland. Waypipe works, but ironically you can't forward x11 apps so you get into this weird situation where you need to use different protocols for different apps and you don't know which ahead of time.

OBS seems to finally be working with linux/wayland again, semi-reliably, and of course most things continue to work via x11 shims. It's getting closer, especially as Gnome gets closer to actually implementing a full set of desktop app protocols, but it is just a lot of work for toolkit developers to port everything over.

I still don't know how you'd go about running GUI apps inside docker containers, something we do at work for a few complicated deployments of ROS stuff (yes I'd rather do it some other way, but we don't have the man power).

[bombela]

And Gnome is slow, with a completely limited UI that barely gives you anything of utility. The file selector is so bad (try selecting a file with the keyboard) and slow it's not even funny, it even has concurrency issues if you select things too fast!?, in Gnome applications, buttons keep changing places for no reasons, 30y olds shorcuts stop working an update to the next (like, press enter to validate), they refuse fractional scaling for... I don't know actually, etc, etx. I am sorry for the well intentioned people working on Gnome. But it's just a dumpster fire at this point.

And the tone in the Gnome issue tracker is insufferable. Everybody that suggest something or tries to help is a moron from their point of view.

I cannot help but think the people working on Gnome live in a weird bubble.

[hollerith]

>they refuse fractional scaling

Huh? I'm using Gnome instead of MacOS because I can choose the size of the text and the other UI elements. On MacOS, the only choices that aren't blurry are 100% scaling and 200% scaling, but Gnome lets me set the scaling to an arbitrary value without blurriness. (I had to fuss with Emacs and my web browser to get them to be non-blurry when the scale factor is something other than 100%.)

Are there stupid design decisions in Gnome? Yes, but I've found Gnome to be usable with a little research (i.e., on how to set keyboard shortcuts for switching between apps instead of the "activities view").

[bombela]

Ok now I am not sure which is which, what it working and what isn't anymore: https://wiki.archlinux.org/title/HiDPI#Fractional_scaling

[type0]

> There are common desktop extensions that Gnome just isn't really interested in developing.

In GNOME 45 all current extensions will loose backward compatibility, that's one of the yet more changes that will force many to migrate to other desktop environments

[tadfisher]

There is a really good technical reason for that, and honestly, I don't want to use extensions that aren't being maintained as new versions of Shell get released.

The reason Gnome doesn't have a stable extensions API is the same reason extensions are powerful: extensions are user code running in the same JS environment as Shell and can do anything. I think that's a decent tradeoff for a best-effort system without a ton of manpower and ecosystem involvement.

[hulitu]

> expecting a bunch of unpaid open source developers to go and re-implement everything

We are really wondering why those "unpaid open source developers" would want to "re-implement everything". Fixing existing systems is hard, i presume. /s

[pseudotrash]

Nitpick: there is no "vs." ... because in the long run X11 is dead. After decades of serving us well it's not maintainable and not a good base to build anything on top that you want to continue maintaining in 5 or 7 years. Any warranty of a "cyber physical systems" is better off starting on Wayland IMHO

What issues are you facing with screen recording?

Can't say anything about NVIDIA because I avoid these chipsets like the plague (even for windows)

[dekhn]

X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.

[dale_glass]

It already appears to be effectively dead. Pretty much all the commits in the repo are wayland related.

[umanwizard]

I am still using X and it is still working fine for what I need. Why would I need it to continue to be maintained?

[hulitu]

> X11 is dead. After decades of serving us well it's not maintainable

Why not ? Is the wayland "maintainable " ?

[tadfisher]

The X11 maintainers said as much, then created Wayland?

[DyslexicAtheist]

The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44

[nsajko]

This is just FUD.

[tov_objorkin]

One very stupid reason is the Qt itself, graphics application can't live without the QScreen instance. If user unplug every screen from the system, in order to prevent crash qt create the fake screen and hang in the headless state.

[sprash]

You forgot the most important reason:

(0) zero community mind share as a result of extremely cumbersome and developer hostile APIs and the lack of standardization of essential functionality.

QtWayland won't be able to address this because vendor lock-in for a de-facto proprietary toolkit won't generate any community mind share either.