I've found the abstractions with Flatpak, xdg-desktop-portal, pipewire, and misc. web browsers to be decent for screen sharing with Wayland
Native clients, not so much :/
Many-years user of Sway here. My screen sharing is actually broken now, and I'm pretty sure I missed something in my reinstall - it had been great for a year or so
Browsers are my screen-sharing magic, though not every service allows those... or offers an equivalent experience.
What desktop environment/window manager do you tend to prefer? Depending on that you'll likely have to choose/consider a different 'xdg-desktop-portal'.
It may be helpful to share this tool: 'xlsclients'
It can show you things running in that compat mode 'XWayland'. This is usually the explanation for something looking pretty choppy or showing strange clipboard behavior :D
XWayland server provides limited capabilities for X11 desktop applications (see X11 Application Support and JDK-8269245). In order to get full support of the desktop features, we need to implement a pure Wayland client toolkit for java. Wayland architecture in many ways differs from X11, so we cannot reuse XAWT even for basic capabilities. The new toolkit should be implemented from scratch. Here are some major chunks of work: Event handling (...), Graphics devices support (...), java.awt.Robot (...), Client-side decorations for windows (...)
(That JDK is related to java.awt.Robot.createScreenCapture, and global screen capture is restricted by Wayland)
In short (and I've used this metaphor before) they've thrown away the complicated, dangerous steering wheel and provided a clear description of the steering column so that each app developer or desktop compositor (i.e. someone else/not us) can develop their own, presumably safer, steering wheel. For the functionality they tore away, apps either must use XWayland (the compatibility layer), rewrite to conform to pure Wayland, or submit a merge request for the thing they want to one of the Wayland repositories.
Of course, larger apps with lots of dependencies need every dependency to do Wayland appropriate things or have the XWayland server connect the dots. In some cases, for reasons I don't fully understand, the compatibility layer can be slow as hell.
For example, if I run OpenSCAD's AppImage (in Wayland with either an AMD GPU on a 3K 10bpp display or Nvidia GPU on a 4K 10bpp display) and type something like
cylinder([
it takes about a second to type but at least three seconds to fully appear in the editor. Switching to X instantly resolves the issue. OpenSCAD is Qt and has a handful of other dependencies that I guess are also not as actively developed, plus the official release has lagged the nightly for the past 3 years or so despite active development.
The Wayland developers are few and seem to work on the things with the biggest impact to users/themselves while restricting a lot of proposed changes for security, stability, or "takes too long/doesn't make sense to us" reasons. Things like non-Intel GPU compatibility, unusual hardware, and legacy software have to rely on compatibility layers until someone else fixes issues upstream or downstream.
It's possible I misunderstand this system/organization and will gladly get schooled by anyone not blindly yelling, "Wayland works on my machine! Your problems exist not because of Wayland but because XYZ"
Depends on the framework you used. If you used gtk or qt, it is enough for them to support wayland.
If you have something homemade, or you talk directly to x11 server; well now you have to talk directly to wayland server, using a different protocol.
There are also some changes in semantic, most visible & commented in the screen sharing scenario: with x11, you could just silently grab the desktop framebuffer and run to the bank. That's a no-no with wayland, you must ask a privileged process to mediate the access (and that process will ask the user which display or window to share, if any). Some apps are taking their sweet time to switch to this concept.
Speaking of Electron... vscode even intentionally ignores .config/electron-flags.conf (or it's own -flags.conf), so you must pass the ozone flags on the command line (i.e. edit the launcher, which will be replaced on next update).
There were many issues filled on vscode wrt. wayland support, hidpi, fractional scaling... and they all were closed with half-baked solution that are not really solution. It's tragic, how a project like vscode can ignore wayland and it's features for such a long time.
Argh, that's frustrating. That's been my default (uninformed) state -- those flags files never seem to work for me. I override launchers all the time.
I've found some comfort by placing my edited copies in ~/.local/share/applications and informing 'fuzzel' (my launcher) of it by ensuring the parent directory is in $XDG_DATA_DIRS
As long as the file names match those in the 'system' directories, these will win.
13 comments
[ 3.0 ms ] story [ 43.0 ms ] threadNative clients, not so much :/
Many-years user of Sway here. My screen sharing is actually broken now, and I'm pretty sure I missed something in my reinstall - it had been great for a year or so
Browsers are my screen-sharing magic, though not every service allows those... or offers an equivalent experience.
What desktop environment/window manager do you tend to prefer? Depending on that you'll likely have to choose/consider a different 'xdg-desktop-portal'.
It may be helpful to share this tool: 'xlsclients'
It can show you things running in that compat mode 'XWayland'. This is usually the explanation for something looking pretty choppy or showing strange clipboard behavior :D
But at some point you want to implement wayland support directly. If you use a library like qt, that may just be an update away.
It is not just display stuff. There is also libinput which handles gestures for example. These things you would have to change in your program.
XWayland server provides limited capabilities for X11 desktop applications (see X11 Application Support and JDK-8269245). In order to get full support of the desktop features, we need to implement a pure Wayland client toolkit for java. Wayland architecture in many ways differs from X11, so we cannot reuse XAWT even for basic capabilities. The new toolkit should be implemented from scratch. Here are some major chunks of work: Event handling (...), Graphics devices support (...), java.awt.Robot (...), Client-side decorations for windows (...)
(That JDK is related to java.awt.Robot.createScreenCapture, and global screen capture is restricted by Wayland)
In short (and I've used this metaphor before) they've thrown away the complicated, dangerous steering wheel and provided a clear description of the steering column so that each app developer or desktop compositor (i.e. someone else/not us) can develop their own, presumably safer, steering wheel. For the functionality they tore away, apps either must use XWayland (the compatibility layer), rewrite to conform to pure Wayland, or submit a merge request for the thing they want to one of the Wayland repositories.
Of course, larger apps with lots of dependencies need every dependency to do Wayland appropriate things or have the XWayland server connect the dots. In some cases, for reasons I don't fully understand, the compatibility layer can be slow as hell.
For example, if I run OpenSCAD's AppImage (in Wayland with either an AMD GPU on a 3K 10bpp display or Nvidia GPU on a 4K 10bpp display) and type something like
it takes about a second to type but at least three seconds to fully appear in the editor. Switching to X instantly resolves the issue. OpenSCAD is Qt and has a handful of other dependencies that I guess are also not as actively developed, plus the official release has lagged the nightly for the past 3 years or so despite active development.The Wayland developers are few and seem to work on the things with the biggest impact to users/themselves while restricting a lot of proposed changes for security, stability, or "takes too long/doesn't make sense to us" reasons. Things like non-Intel GPU compatibility, unusual hardware, and legacy software have to rely on compatibility layers until someone else fixes issues upstream or downstream.
It's possible I misunderstand this system/organization and will gladly get schooled by anyone not blindly yelling, "Wayland works on my machine! Your problems exist not because of Wayland but because XYZ"
If you have something homemade, or you talk directly to x11 server; well now you have to talk directly to wayland server, using a different protocol.
There are also some changes in semantic, most visible & commented in the screen sharing scenario: with x11, you could just silently grab the desktop framebuffer and run to the bank. That's a no-no with wayland, you must ask a privileged process to mediate the access (and that process will ask the user which display or window to share, if any). Some apps are taking their sweet time to switch to this concept.
Wayland support has been upstream for quite a while, yet most of them I use are relegated to XWayland. Didn't they basically get it from Chromium?
There were many issues filled on vscode wrt. wayland support, hidpi, fractional scaling... and they all were closed with half-baked solution that are not really solution. It's tragic, how a project like vscode can ignore wayland and it's features for such a long time.
I've found some comfort by placing my edited copies in ~/.local/share/applications and informing 'fuzzel' (my launcher) of it by ensuring the parent directory is in $XDG_DATA_DIRS
As long as the file names match those in the 'system' directories, these will win.