The Linux graphics stack in a nutshell, part 2

Posted Dec 30, 2023 9:59 UTC (Sat) by vadim (subscriber, #35271)
Parent article: The Linux graphics stack in a nutshell, part 2

The one thing I'm still a bit confused about is why PipeWire has anything to do with screen sharing.

Could somebody explain? PipeWire is an entirely separate project from a compositor, so what does it do to get the screen data?

The Linux graphics stack in a nutshell, part 2

Posted Dec 30, 2023 11:37 UTC (Sat) by tux3 (subscriber, #101245) [Link]

Not an expert, but my understanding is the following:

Pipewire is a thing that applications talk to to shuffle audio and video buffers around, optionally doing some extra processing. It has nothing to do with the compositor, but it's good at exposing reasonable audio/video APIs to apps.

The wayland compositor is the only one with direct access the screen data. Actual implementations of the compositor are free to add their own stuff on top of the (small) base of wayland APIs, and they provide a permission system.

Apps ask permissions through XDG Desktop Portals, which is a DBus API with an implementation for each desktop environment that might for instance show a pop up to the user with "X app wants to record your screen, Yay/Nay?"

The implementation of the XDG portal for accessing the screen uses Pipewire for the logistics of passing buffers around, so that's why it sits in there in the middle between the compositor and the app asking for access. Pipewire asks the compositor, which pushes its data inside Pipewire, and the app gets the data from Pipewire through the portal.

Pipewire and portals is just the de-facto standard in the implementation-specific world of Wayland compositors. Wayland as she is spoke.