Add an example screenshotter using export-dmabuf

[ids1024]

This takes a screenshot for each display and saves to .png images.

I'm not entirely sure the dmabuf/OpenGL logic here handles formats. I assume OpenGL can be trusted to convert any DRM format to 8 bit per channel uncompressed RGBA? Which could be lossy depending on the format?

It could be good to have examples testing other protocols. And something testing dmabuf exporting for workspaces and toplevels. (It could similar iterate over workspaces and toplevels and export an image for each.)

[ids1024]

Not necessarily no. Some formats would just not be compatible. We need a conversion table for those and need to extend ExportMem to take a format argument. However in case of cosmic-comp everything should be RGBA-encoded and thus convertible by OpenGL.

So would this at least be expected to work with RGBA or ARGB, 8 bit or 10 bit, etc. and convert to 8-bit RGBA? While failing in some way with something like YUV?

I know there are a lot of DRM formats including vendor specific compression, so it wouldn't be possible to support all of them without the driver providing some way to convert. But then I don't know what subset cosmic-comp would have any reason to use. Supporting HDR is something we'd be interested in having at some point though.

(And then I don't know how this sort of thing works if the compositor is using multiple planes, hardware decoding on one plane, how Widevine DRM works on X/Wayland, etc.)

Additionally not every dmabuf may be importable as a GL-texture, as that assumes the contents of the buffer can be sampled. It might be safer to instead bind the dmabuf as a framebuffer (using the smithay::backend::renderer::Bind-trait) and using copy_framebuffer instead of copy_texture.

Ah, I didn't know that, but I guess it makes sense.

[ids1024]

Presumably transparency isn't that relevant for capturing the whole screen, so it would make sense for it to only download RGB from OpenGL and encode as an RGB png instead of RGB. Capturing a single window would be different though.

[Drakulix]

Not necessarily no. Some formats would just not be compatible. We need a conversion table for those and need to extend ExportMem to take a format argument. However in case of cosmic-comp everything should be RGBA-encoded and thus convertible by OpenGL.

So would this at least be expected to work with RGBA or ARGB, 8 bit or 10 bit, etc. and convert to 8-bit RGBA? While failing in some way with something like YUV?

I am not sure, about 10bit. cosmic-comp doesn't support that right now. I guess we have to test, but otherwise yes.

I know there are a lot of DRM formats including vendor specific compression, so it wouldn't be possible to support all of them without the driver providing some way to convert. But then I don't know what subset cosmic-comp would have any reason to use. Supporting HDR is something we'd be interested in having at some point though.

Modifiers (representing hardware specific compression for example) are handled transparently by OpenGL as long as the modifier can be rendered to (as exposed by EGLContext::dmabuf_render_formats and EGLContext::dmabuf_texture_formats).

Some vendor specific modifiers might not be importable into OpenGL (or vulkan for that matter), but could be produced by hardware encoders/decoders and scanned-out. Those might prove troublesome once we support direct-scanout and a fullscreen-capture could contain these modifiers. Right now however there is no way for a client to send such a buffer, as the compositor is not advertising these as supported.

Once that is happening we might need some modifier negotiation code in the export_dmabuf protocol though, so cosmic-comp could force the clients to send renderable modifiers, if the portal (or the consumer of the screencast) requires it.

(And then I don't know how this sort of thing works if the compositor is using multiple planes, hardware decoding on one plane, how Widevine DRM works on X/Wayland, etc.)

Planes essentially will cause the same problems as direct-scanout. How DRM works with this (and HDCP) I don't know. ^^

[ids1024]

Okay, DRM/HDCP, 10 bit color, multiple planes, and direct scanout are things we'll need to test when there are supported in some form in Cosmic-Comp.

Direct scanout in particular is likely relevant with screen capture since capturing games would involve both. With DRM content, presumably we expect that part of the capture to just be black so it's fine if it is, I'm just wondering exactly how that is handled on Linux.

[Drakulix]

I know I am nitpicking small stuff, but do we maybe want to add compiling examples to CI? :sweat_smile:

[ids1024]

Yeah, true, it should probably build the examples on CI.