Show "Wayland not supported" or fix it

[stefonarch]

At least until we implement https://wayland.app/protocols/wlr-screencopy-unstable-v1

System Information

• Distribution & Version: all

[stefonarch]

@gfgit @marcusbritanicus Let's discuss https://github.com/lxqt/lxqt-panel/pull/2046#issuecomment-2076870391 here.

I'm quite ignorant about portals, so no idea. It should be this one https://github.com/emersion/xdg-desktop-portal-wlr

[marcusbritanicus]

@stefonarch Thanks. I was thinking of opening an issue here, good we can continue here.

I'm quite ignorant about portals, so no idea.

I too am not very well versed with it. Almost all my attempts to use the portals have failed. I am rather disdainful of x-d-p and it's various implementations. But I have the basic knowledge of how Wayland works, and that's sufficient for me to explain the problem.

It should be this one https://github.com/emersion/xdg-desktop-portal-wlr

Yes, this is the one. This implements the org.freedesktop.portal.Screeshot interface for wlroots-based compositors. And whatever I try, I cannot get this to work. I end up with a same error: No such interface “org.freedesktop.portal” on object at path /org/freedesktop/portal/desktop

The idea of these portal is simple. It was developed mainly for flatpaks. The idea is: I (the xdg-dekstop-portal or its implementations in various forms x-d-p-kde, x-d-p-lxqt, x-d-p-gtk etc) will do certain tasks for you (the client app) because you're running in a "sandbox". Eventually, most normal apps also have accepted this setup. Qt and GTK evolved to make app built using them work smoothly in flatpaks. This meant they have inbuilt support for a few certain interfaces. For example, the file dialog. You'll notice that in a well setup system, you'll almost never see the default boring Qt file open dialog. It's usually, KDE or LXQt or GTK file dialog from the portal. The communication between the app and the portal is via dbus.

All portals work nearly perfectly on X11. Why? They were designed to work on X11. Most portals work great wayland like the file-open/file-save etc. Why? Because most of these do not need any compositor interaction.

Here comes the Screenshot protocol of x-d-p. The x-d-p process can easily access any window and its contents on X11. X11 has the concept of window ids to identify the windows. All X11 clients can access this information. So my screenshot app simply asks the Xserver to give the window id of the app that is clicked. And then it asks the x-d-p to give the screenshot. Works great!!

Enter wayland. Wayland does not have the concept of window ids. Secondly, on wayland, we treat each window and it's contents as private. A random client has no mechanism to ask the compositor to give the view under the mouse or active view or even view which was clicked. On X11/XCB we had a million functions that could do one thing or another. On wayland we can talk to the compositor via the socket, using protocols. And we do not have a protocol to query client id. So, there is no way to ask the x-d-p to get the screenshot of a window with a particular id. Secondly, there is no way for x-d-p-wlr to ask the compositor to give the screenshot of a particular window. The only protocol available is wlr-screencopy, and that allows you to ask the compositor the screenshot of the whole screen.

If you have noticed, on wlroots-based compositors, during screen-sharing, you can share only tabs (of chromium/chrome/brave/etc...) and the whole screen. You cannot share a single app surface. Plasma has its own protocol that allows sharing of particular window or tab or screen. And that is not implemented by anybody else.

TL;DR

There is no mechanism, x-d-p, or otherwise to capture the contents of a particular window on wlroots-based compositors.

[stefonarch]

Afaik the only thing that looks working for me with this portal is screenrecording (obs), sharing should work too according to the test page .

[marcusbritanicus]

That's correct. Screenshot of the whole screen. The extension of this is screen-recording/screen-casting - the protocol is capable of sending the data repeatedly.