Proposal for RandR version 1.6, Leases and EDID-based output grabs

Pekka Paalanen ppaalanen at gmail.com
Mon May 8 07:33:51 UTC 2017


On Sat, 6 May 2017 13:34:44 +0200
Mario Kleiner <mario.kleiner.de at gmail.com> wrote:

> Just please make sure that one (user configurable/opt-in if necessary) 
> policy from the beginning is to allow leasing out any output to 
> applications, not just HMDs. My type of scientific/medical applications 
> would benefit as soon as it has the option to get a drm lease for a 
> given output on both X and Wayland based systems. That's not a 
> theoretical future use case, but one i'd try to offer to my users as 
> soon as a stable protocol/implementation is available in a regular Linux 
> distribution. It wouldn't be fun for inexperienced users if they had to 
> hack the database for every model of display they want to use, or if 
> every untrusted user would have to have a root password to do so.

Hi Mario,

as Keith said, the DRM leasing API is ok for that. Such policy must not
be part of the database, IMO, so it's not an issue for the database.
This is another reason why I think the database should only describe
the hardware, not set usage patterns nor be an extension of display
server configuration.

For Wayland, we would need to experiment. I would not start with the
assumption that the Wayland extension used for grabbing HMD outputs
could also be used to grab an arbitrary output that the compositor is
already using for the desktop. Since an output is a part of the
desktop, it is possible it needs more strict or slightly different
grabbing semantics. I believe one should design both cases separately
and then see how much they have overlap.


Thanks,
pq

PS. Keith, I started writing a reply to you, but didn't finish yet.
-------------- 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.x.org/archives/xorg-devel/attachments/20170508/028097f3/attachment.sig>


More information about the xorg-devel mailing list