From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keith Packard Subject: Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs Date: Sun, 02 Apr 2017 12:58:33 -0700 Message-ID: <86y3viinti.fsf@hiro.keithp.com> References: <86fuhrka4t.fsf@hiro.keithp.com> <20170402154302.zd7nmqf7vtcvgssu@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0537176131==" Return-path: In-Reply-To: <20170402154302.zd7nmqf7vtcvgssu-dv86pmgwkMBes7Z6vYuT8azUEOm+Xw19@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: xorg-devel-bounces-go0+a7rfsptAfugRpC6u6w@public.gmane.org Sender: "xorg-devel" To: Daniel Vetter Cc: xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: dri-devel@lists.freedesktop.org --===============0537176131== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Vetter 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 :-) =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAljhV+kACgkQ2yIaaQAA ABHrxA/8D4qjC3cnM0vM447130yVbYuw4VE+cqEppfZx6Hg0xayHqoUU6X+Sz2kh /zalVfe9ssTHFjQK87zQ4GdnU/GwBUQNbCRLXg2xB+f+aFPDP6T8S8TY7p99XUjG ybq/SbUcTb91f2uGIk+HNGHcSuGktYu9Cpxg25/w9d2M8XfD7PUKT0tO7xFVaRVh JOnEaruadXD89/GpkYXoHNoxL5InWKXPq8+5eASLZ1am74IW+B5kDnuklktEp/in 55asl2VTtFkxdAftZTm1xQbiZcl3AHRLRPZALJk9EN3OQ3DK3ldZlrdTJ8hVa7zG 6Y4qn30KnV8//Z88r10tX4j9rWQ6rnBTr3KmqyYqSTpW7rvkR03mnJlQvXQbMYIA OIIqB4iKHGu0XQrcMmayS5GFNEhZpRPPScpiqE0FzIjubSDvuAXWzKSrRj8NeNXc su6l4uWW0MlVvDs/PCZ2swMhAaJVa2a4iylFkP8n6K6/SPXmFIpd5bN2vjih3Fqv cIoCAjxYMoYQEbAh5FZw9oL2QJwP5zUpv2wzld/0t2Os/mD/iti1OAwALqG5Cefq YSBJzgLgxt6SDp/THA3zBrkF/MpBF29NJC2iKNNMx8N50bGI2tUMqK5fz1WAzO8P qT8sZGbpBzPp/PsfEqeF8mRzF9vSzSH31cPedz1OR0cI8hsel5w= =qCck -----END PGP SIGNATURE----- --=-=-=-- --===============0537176131== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============0537176131==--