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

From: Pekka Paalanen <ppaalanen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Mario Kleiner <mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	"Michel Dänzer" <michel-otUistvHUpPR7s880joybQ@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Date: Mon, 8 May 2017 10:33:51 +0300	[thread overview]
Message-ID: <20170508103351.02b60ae9@eldfell> (raw)
In-Reply-To: <7f68d9fe-a40f-cfb2-3efd-1149d93bb5cb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

[-- Attachment #1.1: Type: text/plain, Size: 1710 bytes --]

On Sat, 6 May 2017 13:34:44 +0200
Mario Kleiner <mario.kleiner.de-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel