[PATCH wayland-protocols v3] unstable/drm-lease: DRM lease protocol support

[Pekka Paalanen]

On Thu, 23 Aug 2018 15:12:03 +0000
Marius-cristian Vlad <marius-cristian.vlad at nxp.com> wrote:

> On Thu, 2018-08-23 at 14:39 +0300, Pekka Paalanen wrote:

> > > > > Especially EDID info would be most useful for finding the right
> > > > > VR
> > > > > headset.    
> > 
> > Sharing EDID could be tricky mechanically. If we assume that an
> > average
> > EDID blob is 256 bytes, it would be small enough to pass "inline" in
> > Wayland, e.g. as a wl_array argument on an event. But since we want
> > to
> > provide it for all leasable connectors, the burst of data could grow
> > bigger than the buffers in libwayland, and we start relying on the
> > kernel socket buffers which are much larger usually.
> > 
> > Maybe it's ok to start with a wl_array while we are still in unstable
> > protocol, but this question may need to be revisited in the future.
> > 
> > Is there a defined upper limit on EDID size?
> > 
> > Btw. since we may need to share EDID, and we may need applications to
> > parse EDID to dig out what they need, I believe there will be a
> > demand
> > for a library to do that. Does any such exist already?  
> 
> Isn't this overkill? Asking the client to parse that blob?
> 
> Wouldn't make more sense to add the fields Philipp mentions
> (manufacturer ID/product code) fields in drm_edid? The compositor
> already parses the EDID to provide/supply a serial number/monitor name.
> 
> If the client can ask the kernel (through the leased fd) and chooses
> what mode it wants, then what would be the point to send the whole
> EDID? 

As I mentioned below, I don't know if we *need* to send EDID. It all
depends on what the applications will need for making the decision to
attempt leasing.

A problem with sending just specific parsed fields of EDID instead of
the blob is that we need to update the protocol if new very useful
fields appear in EDID.

It's a trade-off, both ways can work.

For the record, I think on X11 EDID is already exposed to clients, so
VR runtimes might expect it to be available. Of course, one can get it
after creating the lease, too, so not including it in the leasing
protocol will not prohibit clients from getting it. It just takes more
effort on the client.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180824/7a75ea1d/attachment.sig>