5 ms·

I didn’t even realize desktop applications could/should implement the Wayland protocol. I thought it was just WM’s (and some DE’s?) that needed to do that, bas

I didn’t even realize desktop applications could/should implement the Wayland protocol. I thought it was just WM’s (and some DE’s?) that needed to do that, basically anything that directly replaces X, but not the apps running on it. Is this something every Linux desktop application will need to do?

TacticalCoder 3y ago
I'm confused too so I upvoted you. Any information most welcome.
- tapoxi 3y ago
  tl:dr an app connects to the Wayland compositor (like an X server) and sends it draw commands using the Wayland protocol. The compositor accepts these connections on a Unix socket, /run/user/1000/wayland-0 by default The protocol is defined in the libwayland library. Most apps don't use libwayland directly, but their widget toolkit like GTK or Qt does it for them.
  - blibble 3y ago
    at the risk of appearing pedantic: whereas a large chunk of X11 is dedicated to draw commands (circle here, line here, pixel here): wayland doesn't have any instead it's all shared memory buffers
    - LoganDark 3y ago
      X was designed to be used over a network, where sending buffers would have been very slow. Sending primitive draw commands, on the other hand, was much faster.
Quekid5 3y ago
For most applications it's usually enough that the toolkit (GTK, Qt, whatever) supports it. However, Firefox probably does some stuff 'outside' what GTK provides, so it needs to implement those bits itself. I'm guessing stuff like <video/> support. (Wayland is a set of protocols and the toolkit may not support all the protocols or have sub-par support -- in which case the application can choose to do those bits itself.)
- treyd 3y ago
  Accelerated video decoding is an example. It uses VA-API or VDPAU to decode video onto a surface that is then composited into the final frame entirely on the GPU.
HansHamster 3y ago
Usually, the UI toolkit (gtk, qt, ...) should take care of the X11/Wayland protocol details. But if the application is doing its own thing or at a lower level (and I guess Firefox qualifies) then that has to be adapted.
- thedaly 3y ago
  Firefox, pretty much all electron based apps, there are lots of applications that seem to interface directly with wayland.
  - Quekid5 3y ago
    Electron apps interface with Electron-the-platform (and have no direct knowledge of Wayland) so it doesn't seem to make much sense to single that out?
    - OJFord 3y ago
      Single what out, all of them? ,'Electron-the-platform' does then, via which all 'Electron apps' (single thing or not) do, which is what GP's saying? It works this way for Electron-the-platform... And therefore every Electron app that uses it?
      - comex 3y ago
        The point is that Electron-the-platform is playing a similar role to GTK or Qt: it talks to Wayland, and the application talks to it. Therefore the application is not interfacing directly with Wayland, and claiming that it is would be singling out Electron from the category of UI toolkits. But it depends on your definition of “application”.
        OJFord 3y ago
        Yeah, I'm not sure how now, but I think I misread/misunderstood the comment I defended. Can't now read it any other way but as a claim that they typically don't use Electron for it and instead talk to X/Wayland directly. (I have no idea, but would have assumed Electron handled it sufficiently for the vast majority.)
fayalalebrun 3y ago
Yes, desktop applications need to implement the Wayland protocol in the same way they need to implement the X protocol. There is a compatibility layer called XWayland which allows you to run Xorg programs under Wayland. However, running programs under XWayland comes with issues such as lack of proper fractional scaling. This means that although not strictly necessary, from a user's point of view it is desirable to have applications move to Wayland.
pengaru 3y ago
XWayland is a compatibility interface for X apps to still work on Wayland compositors, so it's not mandatory to port everything over to Wayland. But there should be performance and rendering quality advantages to speaking Wayland natively. Core X for instance has zero concept of a frame or buffer swapping, X apps like games generally get that via GL. So your average X GUI application tends to be inherently flickery/tear-ful, since draws just get sent out to the X server and display whenever. XOrg drivers have implemented various hacks to try minimize those effects, but it's all very vendor-specific[0] and never perfect since it's a fundamental limitation of the X protocol. You can at best eliminate literal tearing[1], but nothing prevents displaying a partially refreshed window full of changing widgets, each implemented as X subwindows in the classic X fashion, because nothing in the core protocol says "Ok, this top-level window update is finished, present it (and its descendants)!". That's not even getting into the issues of high dpi and fractional scaling... [0] https://manpages.debian.org/bookworm/xserver-xorg-video-intel/intel.4.en.html#Option~11 https://manpages.debian.org/bookworm/xserver-xorg-video-inte... [1] https://en.wikipedia.org/wiki/Screen_tearing https://en.wikipedia.org/wiki/Screen_tearing
- vidarh 3y ago
  Most X servers implement the Xdbe extension for double buffering with clients that supports it, or you can just render into an off screen pixmap first. In other words, if there is tearing or flickering, it's really entirely the clients fault for just blindly choosing to render straight to the window.
  - bitwize 3y ago
    But with Wayland you don't actually have to do anything to get flicker-free, tear-free output because Wayland was designed with these goals in mind.
    - vidarh 3y ago
      Of course you do: You need to allocate a buffer, and you need to commit it to the visible display, exactly the same amount of work to do so under X. If anything, I suggest you look at the sheer amount of code required to put anything on screen with Wayland vs. X - Wayland requires a lot of boilerplate, as the presumption is that everyone would use a widget library. As far as design goes, Wayland is absolutely awfully verbose for no good reason.
MaxRegret 3y ago
Desktop applications can continue to use the X11 protocol, but then they'll be talking to the Xwayland server, which in turn Wayland to actually draw its clients' windows on the screen. But it's preferable to have applications directly use the Wayland protocol, which is what Firefox is experimenting with. For most applications, this is easy because they use some standard toolkit like GTK or Qt, which will transparently use Wayland without the application caring about it. But Firefox uses its own toolkit, so it's a bit more work.
deleted 3y ago
[deleted]
treyd 3y ago
> Is this something every Linux desktop application will need to do? The idea is that GTK+ and Qt can (and do) add support for Wayland and it's trivial for applications to support Wayland, often without even recompiling.
bitwize 3y ago
Yes, Wayland is a display protocol that applications need to speak in order to display on a Wayland server. Applications built for X can still run on Wayland via Xwayland. But Xwayland is a bodge to allow legacy applications to continue running, an interim solution while toolkits, libraries, and applications are converted to use Wayland directly. To paraphrase the hit song: Once we have enough Wayland software At our call, hackers, at our call, We'll throw out those dirty X code paths, Ever more, hackers, ever more.
- Bu9818 3y ago
  Lots of games won't ever be converted to Wayland (maybe some unofficially by replacing libraries with updated ones that still work with the game), we'll need some nested X server like xwayland in rootful mode once wayland compositors remove their xwm.
  - wmf 3y ago
    Just run games under a native Wayland version of WINE.
    - Fornax96 3y ago
      Once again WINE is the stable Linux ABI
      - a_vanderbilt 3y ago
        Absolutely hilarious that we have reached a point where the most stable API for Linux apps is win32.
        okanat 3y ago
        Reached? Win32 has been the most stable userspace ABI for Linux for more than a decade (or even 2?). Wine is a really old project and Win32 API / ABI has always been stable. The implementation of the API / ABI was very patchy earlier but the functions that defines the ABI has always been there, their signature and calling conventions are stable.
LoganDark 3y ago
The apps need to actually talk to the server, which means they need to also know the protocol for it.
okanat 3y ago
For regular apps the toolkit (Qt / GTK / GDI / Cocoa) handles it. They hide the inner bits of the underlying OS / Graphics API from the apps. Web nowadays is a very free-form environment coming with cross-platform APIs. Using platform specific API and toolkits will create inconsistencies and performance issues. So browsers come with their own rendering engines that uses lower level APIs like Directx and OpenGL. To access GPU video decoders etc., they also need to use those lower level APIs anyway. Regardless of the OS, when the applications want to directly render things they have to communicate with the lower level graphics backend (Wayland, X, DWM, Metal etc) to agree on a memory area and pixel format and some other things. The OS, the direct rendering system and the window management system together manages what application gets the rendering signal, what area, at what display with what metadata (e.g. DPI, or pixel bits) it is drawn. Since browsers are writing their rendering system and the components from scratch (not everything, they still use some system GUI components or text input / font rendering stuff), they need to communicate with the lower layer directly to request screen areas to render, to get the correct display DPI/scale to draw things at the correct size with well-aligned pixels and to utilize various hardware stuff like hardware video decoders.
trealira 3y ago
This is the reason there are cross-platform GUI libraries (like GTK and QT) in the first place. Without it them, an application must either sacrifice portability, or manage the same application for multiple different interfaces over multiple OSes, like X Windows, Win32, Cocoa, and Wayland. Many applications for Windows, OS X, and Linux interface directly with Win32, Cocoa, or X11/Wayland. For example, the Foot terminal emulator only works with Wayland, because the author has chosen not to implement the X11 protocol.

TacticalCoder 3y ago

I'm confused too so I upvoted you. Any information most welcome.

tapoxi 3y ago
tl:dr an app connects to the Wayland compositor (like an X server) and sends it draw commands using the Wayland protocol. The compositor accepts these connections on a Unix socket, /run/user/1000/wayland-0 by default The protocol is defined in the libwayland library. Most apps don't use libwayland directly, but their widget toolkit like GTK or Qt does it for them.
- blibble 3y ago
  at the risk of appearing pedantic: whereas a large chunk of X11 is dedicated to draw commands (circle here, line here, pixel here): wayland doesn't have any instead it's all shared memory buffers
  - LoganDark 3y ago
    X was designed to be used over a network, where sending buffers would have been very slow. Sending primitive draw commands, on the other hand, was much faster.

Quekid5 3y ago

For most applications it's usually enough that the toolkit (GTK, Qt, whatever) supports it. However, Firefox probably does some stuff 'outside' what GTK provides, so it needs to implement those bits itself. I'm guessing stuff like <video/> support. (Wayland is a set of protocols and the toolkit may not support all the protocols or have sub-par support -- in which case the application can choose to do those bits itself.)

treyd 3y ago
Accelerated video decoding is an example. It uses VA-API or VDPAU to decode video onto a surface that is then composited into the final frame entirely on the GPU.

HansHamster 3y ago

Usually, the UI toolkit (gtk, qt, ...) should take care of the X11/Wayland protocol details. But if the application is doing its own thing or at a lower level (and I guess Firefox qualifies) then that has to be adapted.

thedaly 3y ago
Firefox, pretty much all electron based apps, there are lots of applications that seem to interface directly with wayland.
- Quekid5 3y ago
  Electron apps interface with Electron-the-platform (and have no direct knowledge of Wayland) so it doesn't seem to make much sense to single that out?
  - OJFord 3y ago
    Single what out, all of them? ,'Electron-the-platform' does then, via which all 'Electron apps' (single thing or not) do, which is what GP's saying? It works this way for Electron-the-platform... And therefore every Electron app that uses it?
    - comex 3y ago
      The point is that Electron-the-platform is playing a similar role to GTK or Qt: it talks to Wayland, and the application talks to it. Therefore the application is not interfacing directly with Wayland, and claiming that it is would be singling out Electron from the category of UI toolkits. But it depends on your definition of “application”.
      - OJFord 3y ago
        Yeah, I'm not sure how now, but I think I misread/misunderstood the comment I defended. Can't now read it any other way but as a claim that they typically don't use Electron for it and instead talk to X/Wayland directly. (I have no idea, but would have assumed Electron handled it sufficiently for the vast majority.)

fayalalebrun 3y ago

Yes, desktop applications need to implement the Wayland protocol in the same way they need to implement the X protocol. There is a compatibility layer called XWayland which allows you to run Xorg programs under Wayland. However, running programs under XWayland comes with issues such as lack of proper fractional scaling. This means that although not strictly necessary, from a user's point of view it is desirable to have applications move to Wayland.

pengaru 3y ago

XWayland is a compatibility interface for X apps to still work on Wayland compositors, so it's not mandatory to port everything over to Wayland. But there should be performance and rendering quality advantages to speaking Wayland natively. Core X for instance has zero concept of a frame or buffer swapping, X apps like games generally get that via GL. So your average X GUI application tends to be inherently flickery/tear-ful, since draws just get sent out to the X server and display whenever. XOrg drivers have implemented various hacks to try minimize those effects, but it's all very vendor-specific[0] and never perfect since it's a fundamental limitation of the X protocol. You can at best eliminate literal tearing[1], but nothing prevents displaying a partially refreshed window full of changing widgets, each implemented as X subwindows in the classic X fashion, because nothing in the core protocol says "Ok, this top-level window update is finished, present it (and its descendants)!". That's not even getting into the issues of high dpi and fractional scaling... [0] https://manpages.debian.org/bookworm/xserver-xorg-video-intel/intel.4.en.html#Option~11 https://manpages.debian.org/bookworm/xserver-xorg-video-inte... [1] https://en.wikipedia.org/wiki/Screen_tearing https://en.wikipedia.org/wiki/Screen_tearing

vidarh 3y ago
Most X servers implement the Xdbe extension for double buffering with clients that supports it, or you can just render into an off screen pixmap first. In other words, if there is tearing or flickering, it's really entirely the clients fault for just blindly choosing to render straight to the window.
- bitwize 3y ago
  But with Wayland you don't actually have to do anything to get flicker-free, tear-free output because Wayland was designed with these goals in mind.
  - vidarh 3y ago
    Of course you do: You need to allocate a buffer, and you need to commit it to the visible display, exactly the same amount of work to do so under X. If anything, I suggest you look at the sheer amount of code required to put anything on screen with Wayland vs. X - Wayland requires a lot of boilerplate, as the presumption is that everyone would use a widget library. As far as design goes, Wayland is absolutely awfully verbose for no good reason.

MaxRegret 3y ago

Desktop applications can continue to use the X11 protocol, but then they'll be talking to the Xwayland server, which in turn Wayland to actually draw its clients' windows on the screen. But it's preferable to have applications directly use the Wayland protocol, which is what Firefox is experimenting with. For most applications, this is easy because they use some standard toolkit like GTK or Qt, which will transparently use Wayland without the application caring about it. But Firefox uses its own toolkit, so it's a bit more work.

deleted 3y ago

[deleted]

treyd 3y ago

> Is this something every Linux desktop application will need to do? The idea is that GTK+ and Qt can (and do) add support for Wayland and it's trivial for applications to support Wayland, often without even recompiling.

bitwize 3y ago

Yes, Wayland is a display protocol that applications need to speak in order to display on a Wayland server. Applications built for X can still run on Wayland via Xwayland. But Xwayland is a bodge to allow legacy applications to continue running, an interim solution while toolkits, libraries, and applications are converted to use Wayland directly. To paraphrase the hit song: Once we have enough Wayland software At our call, hackers, at our call, We'll throw out those dirty X code paths, Ever more, hackers, ever more.

Bu9818 3y ago
Lots of games won't ever be converted to Wayland (maybe some unofficially by replacing libraries with updated ones that still work with the game), we'll need some nested X server like xwayland in rootful mode once wayland compositors remove their xwm.
- wmf 3y ago
  Just run games under a native Wayland version of WINE.
  - Fornax96 3y ago
    Once again WINE is the stable Linux ABI
    - a_vanderbilt 3y ago
      Absolutely hilarious that we have reached a point where the most stable API for Linux apps is win32.
      - okanat 3y ago
        Reached? Win32 has been the most stable userspace ABI for Linux for more than a decade (or even 2?). Wine is a really old project and Win32 API / ABI has always been stable. The implementation of the API / ABI was very patchy earlier but the functions that defines the ABI has always been there, their signature and calling conventions are stable.

LoganDark 3y ago

The apps need to actually talk to the server, which means they need to also know the protocol for it.

okanat 3y ago

For regular apps the toolkit (Qt / GTK / GDI / Cocoa) handles it. They hide the inner bits of the underlying OS / Graphics API from the apps. Web nowadays is a very free-form environment coming with cross-platform APIs. Using platform specific API and toolkits will create inconsistencies and performance issues. So browsers come with their own rendering engines that uses lower level APIs like Directx and OpenGL. To access GPU video decoders etc., they also need to use those lower level APIs anyway. Regardless of the OS, when the applications want to directly render things they have to communicate with the lower level graphics backend (Wayland, X, DWM, Metal etc) to agree on a memory area and pixel format and some other things. The OS, the direct rendering system and the window management system together manages what application gets the rendering signal, what area, at what display with what metadata (e.g. DPI, or pixel bits) it is drawn. Since browsers are writing their rendering system and the components from scratch (not everything, they still use some system GUI components or text input / font rendering stuff), they need to communicate with the lower layer directly to request screen areas to render, to get the correct display DPI/scale to draw things at the correct size with well-aligned pixels and to utilize various hardware stuff like hardware video decoders.

trealira 3y ago

This is the reason there are cross-platform GUI libraries (like GTK and QT) in the first place. Without it them, an application must either sacrifice portability, or manage the same application for multiple different interfaces over multiple OSes, like X Windows, Win32, Cocoa, and Wayland. Many applications for Windows, OS X, and Linux interface directly with Win32, Cocoa, or X11/Wayland. For example, the Foot terminal emulator only works with Wayland, because the author has chosen not to implement the X11 protocol.