> > 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. _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
