API to control wlr-screencopy at runtime.

[Fox2Code]

The idea I have is simple, allow compositor to implement handlers for wlr-screencopy to allow compositors to implement a permission system, an example of possible implementation for a compositor could be to only send a pitch black buffer unless permission to capture screen is granted via a dialog box.

Well having something for that in the documentation at least would be cool.

[Fox2Code]

Another idea of possible implementation is showing which wayland process is capturing the Window with a visual indicator.

[ehopperdietzel]

Yes, the API is available, and I'll elaborate on it in a new tutorial chapter. It's as straightforward as this:

void Output::paintGL()
{
    for (LScreenshotRequest *req : screenshotRequests())
        req->accept(true); // Use false or ignore to deny
}

Additionally, each LScreenshotRequest provides the LClient and the desired output rectangle to be captured. This information can be used for client authentication. However, I believe the optimal approach is to use the wlr desktop portal, allowing only pipewire to bind to the wlr-screencpy-manager global. Although I'm not entirely certain, I believe the portal handles displaying a dialog for accepting or denying requests. Regardless, by default, all requests are ignored. In louvre-views and louvre-weston-clone, I simply grant permission to all, as they serve as mere examples.

[Fox2Code]

I completely forgot about cursor capture, yeah maintaining many different buffers just for a cursor is meh, even if it can be handled smartly, I am not sure putting over-complicated code on Louvre is a good idea, as feature creep like this can easily make the project unmaintainable.

Implementing portal should be similar to implementing wayland protocols, but with dbus.

Also Pipewire has a permission API system too: https://docs.pipewire.org/page_access.html

[ehopperdietzel]

I am not sure putting over-complicated code on Louvre is a good idea, as feature creep like this can easily make the project unmaintainable.

Yeah, it was just an idea, but it actually would be simpler for the compositor and harder to implement for clients.

Implementing portal should be similar to implementing wayland protocols, but with dbus.

Just tested the wlroots portal and it works 😄

It has a config file for selecting the output chooser (which can be a wayland app/modal) and I think that if it returns an error code the capture is cancelled, so its perfect!

https://man.archlinux.org/man/xdg-desktop-portal-wlr.5

Edit: It actually says:

To signal that the user has declined screencast, the chooser should exit without anything on stdout.

[Fox2Code]

New xdg-desktop-portal-lvr using ext-screencopy-v1 would be a great idea imo, also an API for compositor to define portals would be great too, but I'm a bit worried about compositor security in some way, and the compositor parsing all client inputs, I think as long as a client input is processed off thread, and that it support invalid request data handling, it should be fine.

But remember to take your time, ext-screencopy-v1 won't be available for 2.0.0 release, better to keep that for 3.0.0 or later

[ehopperdietzel]

New xdg-desktop-portal-lvr using ext-screencopy-v1 would be a great idea imo.

The wlr portal works fine right now, and will probably support ext-screencopy-v1 in the future (maybe it does already), so creating another one just for Louvre compositors is not required yet, unless there is special functionality we want to add. For example, adding support for the custom screen capture protocol I mentioned. On the other hand, everybody is free to create their own portal if they wish.

Also, an API for the compositor to define portals would be great too, but I'm a bit worried about compositor security in some way, and the compositor parsing all client inputs. I think as long as a client input is processed off-thread, and it supports invalid request data handling, it should be fine.

There is wl_display_set_global_filter to allow/deny clients binding to globals, so for example, xdg-desktop-portal-wlr can be started by Louvre using LLauncher (to get its PID), and then in the filter callback, we can check if it matches the requesting LClient PID and only allow that client to bind to the global. Doing so means that there will only be frame capture requests from the portal and no other client (safe). Also, the output chooser (e.g., an auth modal) is launched by the portal, not by Louvre. It doesn't block Louvre's execution, only if accepted, Louvre will receive frame capture requests from the portal. Handling a frame capture request within paintGL() is also non-blocking, it only sets a boolean variable indicating if the frame was accepted, and the copy is done later.

So I think the current API is flexible enough to allow devs to do whatever they want without too much effort. What do you think?

[Fox2Code]

Yeah, devs can always copy paste code from the examples, as long as it's abstracted in a way whatever how the client request, the compositor has to handle the permission one time, and with the same piece of code if possible.

Handling of stuff in the rendering loop or paintGL() should be avoided, unless it's really simple and unlikely to cause slowdowns, the magic of Louvre is it's multi-threading, recent CPUs just have so many cores.

[ehopperdietzel]

There is this protocol currently being developed, which addresses many issues present in wlr-screencopy-manager. For example it introduces the concept of a "session," whereas the current protocol only allows clients to request capturing individual frames without any means to link them together. Once this new protocol is considered stable, I plan to replace the existing one. This will allow for providing an API to allow/deny a session instead of individual frames, which is more suitable.

[Fox2Code]

Well, the most important is still that Louvre API is easy to use, the idea is if someone makes something for one version of Louvre, it still work though the next version.