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

[Daniel Vetter]

On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote:
> 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.

Hm, if you restrict getresources and getplanes, you'll get your leased
objects query api. Iirc that part was missing in your kernel patch. And it
gives you exaclty what you want: per-type list of object ids.
> 
> > 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.

This changes with atomic - without properties you can't change anything
using atomic. Otoh maybe we just want to add checks on the containing
object for now, some of the finer semantic points like "don't modeset" or
"don't steal shared resources at all" can't be expressed (in a generic way
at least) by restricting to specific properties anyway. E.g. on many chips
changing the fb is only ok if you keep the same stride, pixel format and
modifier (~ tiling).
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch