Daniel Vetter <daniel@xxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
