[PATCH v2] unstable/drm-lease: DRM lease protocol support

[Simon Ser]

> > This patch adds an event advertising the EDID of the connector. Given
> > that this is already tied to DRM, this seems like a reasonable addition.
> > I think this should give clients everything they need to make an
> > informed decision on which connectors to pick.
>
> IIRC Pekka had concerns last time about the potential burst of data when
> large EDID blocks are sent for all connectors at the same time, but I
> suppose in the common case they are rather small.

We discussed about it on IRC and this concern seems valid since Wayland messages
are sent in bursts.

tl;dr is that if you have a couple of connectors, a 4*128 bytes EDID on each
connector, you can easily read the 4KiB limit. A simple solution is to just use
a mmapable FD.

Logs:

2019-07-03 11:27:09     pq      ddevault, emersion, putting lots of bytes into a Wayland message has to be done very carefully, because even if one message would be ok, you usua
lly don't send messages one at a time, they go in bursts, and it will be really hard to poll for writable in the middle of a burst, especially for a compositor.
2019-07-03 11:27:38     emersion        ah, i haven't considered that
2019-07-03 11:28:19     emersion        so if you have multiple connectors, each with a 4*128 byte EDID, maybe it'll blow up
2019-07-03 11:38:24     pq      emersion, exactly. Even if libwayland-server had API to see that the client connection is filling up, making the compositor actually return to it
s main loop to poll for writable and then continue sending is a bit difficult.
2019-07-03 11:39:49     pq      something has to be buffering the outgoing messages somewhere, and having unlimited buffering is not a good idea - but then again, the buffer in
libwayland is very small, though that is mitigated by the kernel socket buffer which is much bigger.
2019-07-03 11:41:15     pq      if everything fills up, the client get disconnected I believe
2019-07-03 11:44:11     pq      emersion, EDID hits very much the awkward spot in the size range, where it is slightly too big to safely pass inline in Wayland, but too small to
 bother setting up shared memory. I think I sent a proposal about a protocol extension for one-way medium size data transfers once...
2019-07-03 11:44:32     emersion        yeah :)
2019-07-03 11:48:42     emersion        other solutions: write to a pipe and rely on PIPE_BUF being big enough
2019-07-03 11:48:52     daniels EDID is going to be >128 bytes, due to extension blocks like CEA
2019-07-03 11:49:01     emersion        daniels: 4*128 is the max
2019-07-03 11:49:11     daniels right
2019-07-03 11:50:19     emersion        other solutions continued: have a shm pool for EDIDs
2019-07-03 11:50:24     daniels anyway, all you lose from passing a mappable anon FD is the delta between 4096-512; if you're worried about proliferation of connectors causing t
oo much cumulative loss, then allocate a single buffer rounded up to the page size, then pass ... yes, that
2019-07-03 11:51:29     emersion        but yeah, just using shm is probably good enough

> Between the "name" and the "edid" event, I think clients should have all
> they need to make an informed decision which connectors to request a
> lease for.

That's good to hear.