6 ms·

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 ba

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?

traverseda 3y ago
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 3y ago
  > 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_requests/54 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
  - traverseda 3y ago
    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_355246 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 3y ago
      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/ 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 3y ago
        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).
- hulitu 3y ago
  > 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
- type0 3y ago
  > 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 3y ago
    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.
sprash 3y ago
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.
sho_hn 3y ago
> (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 3y ago
  Accessibility software needs access to the window details like executable, new title, window size and so forth and to be able to emulate peripherals.
tov_objorkin 3y ago
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.
pseudotrash 3y ago
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)
- hulitu 3y ago
  > X11 is dead. After decades of serving us well it's not maintainable Why not ? Is the wayland "maintainable " ?
  - DyslexicAtheist 3y ago
    The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
  - tadfisher 3y ago
    The X11 maintainers said as much, then created Wayland?
- nsajko 3y ago
  This is just FUD.
- dekhn 3y ago
  X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.
  - dale_glass 3y ago
    It already appears to be effectively dead. Pretty much all the commits in the repo are wayland related.
- 3y ago

traverseda 3y ago

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 3y ago
> 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_requests/54 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...
- traverseda 3y ago
  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_355246 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 3y ago
    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/ 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 3y ago
      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).
hulitu 3y ago
> 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
type0 3y ago
> 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 3y ago
  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.

sprash 3y ago

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.

sho_hn 3y ago

> (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 3y ago
Accessibility software needs access to the window details like executable, new title, window size and so forth and to be able to emulate peripherals.

tov_objorkin 3y ago

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.

pseudotrash 3y ago

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)

hulitu 3y ago
> X11 is dead. After decades of serving us well it's not maintainable Why not ? Is the wayland "maintainable " ?
- DyslexicAtheist 3y ago
  The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44 https://www.youtube.com/watch?v=RIctzAQOe44
- tadfisher 3y ago
  The X11 maintainers said as much, then created Wayland?
nsajko 3y ago
This is just FUD.
dekhn 3y ago
X11 will continue to exist and be maintained for decades. I would not even be surprised if it lasts longer than Wayland.
- dale_glass 3y ago
  It already appears to be effectively dead. Pretty much all the commits in the repo are wayland related.
3y ago