Wayland driver development - December 2021 update and next steps

[Giovanni Mascellani]

Hi,

first of all, thanks for your work on this.

On 10/12/21 18:56, Alexandros Frantzis wrote:
> The first is when applications try to render to window created by
> another process. Although this not a typical scenario, it's how
> Chrome/Chromium and thus applications using CEF, including some game
> store apps, work. For now, the workaround is to instruct the application
> to use "in-process" GPU handling (with the "--in-process-gpu"
> command-line) or turn-off GPU rendering completely (typically with
> "--disable-gpu --disable-software-rasterizer"). For example, one can run
> GOG Galaxy with: "GalaxyClient.exe --in-process-gpu [--use-angle=d3d11]"

Could you expand a little bit on what is the problem here? My 
(admittedly, limited) understanding of Wayland's general philosophy is 
that it doesn't care about how the process computes what should appear 
in a window. It just expects a buffer with the pixel data in it, and it 
has some efficient way to move that buffer from the client to the 
compositor, which then does compositing and brings the result to the 
screen. But if you can efficiently move a buffer from a client to a 
compositor, it doesn't sound that much harder to move it from a client 
to another client and then to a compositor, thus basically allowing a 
process to draw on another process' window. What am I missing?

One problem commonly mentioned about windowing drivers is that they are 
hard to test. My understanding of the reason is that they have to 
interact with external systems (X11, Wayland, native Windows, ...) that 
are hard to mock (especially, hard to mock in a way that preserves all 
the quirks we have to care about) and hard to configure so that their 
behavior is predictable and testable. Does a Wayland driver has a hope 
to make things any easier here?

Thanks, Giovanni.