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

[Keith Packard]

Daniel Vetter <daniel at ffwll.ch> writes:

> On that, I think we could just unconditionally hand leases all encoders.
> Encoders turned out to be a bit an uapi mistake.

Well, given the complexity of hardware these days, even crtcs would
probably best have been hidden...

> Neither setcrtc nor atomic use it, the kernel always selects the right
> encoder for you. It's only exposed to give userspace some hints wrt
> routing (and it's pretty bad at describing modern restrictions, which
> often means you get a 1:1 encoder/connector mapping). Unconditionally
> exposing all encoders for all lessees would fix all these troubles.

Yeah, I can't find encoders passed into any kernel api, other than the
getencoder call. It seems like we can leave them as shared objects not
subject to leasing as they are query-only. I'll go ahead and do
that. The encoder crtc set still needs to be filtered in the query
operation so that the client knows which crtc to use for each output.

Now as to how we report the kernel objects that have been leased, we
have two options:

 1) Report them back via the X protocol

 2) Have the client query the resulting lease for its contents

I already suggested that the drm query API should be changed to report
both type and id for each leased object, that would make it sufficient
here. Instead of duplicating that over the X protocol, I suggest we just
use the adjusted kernel API.

> Note that there's also no properties on encoders, those only exist on
> crtc, connector and planes.

Any thoughts on access control for properties? Right now, the set
property ioctl checks for access to the containing object, but there's
no check when querying properties. This means that you don't need to add
leases on properties.

> Kinda more a comment on the kernel side than for xrandr.

It's all tied together :-)

-- 
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170402/10f10e1a/attachment.sig>