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: Tue, 04 Apr 2017 09:48:06 -0700 Message-ID: <864ly4glvd.fsf@hiro.keithp.com> References: <86fuhrka4t.fsf@hiro.keithp.com> <20170402154302.zd7nmqf7vtcvgssu@phenom.ffwll.local> <86y3viinti.fsf@hiro.keithp.com> <20170403074528.c7vwoi3mg7yeojdr@phenom.ffwll.local> <86d1ctigu9.fsf@hiro.keithp.com> <20170403220749.5ujhdzuy6dnikwry@phenom.ffwll.local> <86h925gl6u.fsf@hiro.keithp.com> <20170404070242.rphtgg4yopek2sf7@phenom.ffwll.local> <867f30gody.fsf@hiro.keithp.com> <20170404155923.wllkgop2fyj7wydt@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0389455323==" Return-path: In-Reply-To: <20170404155923.wllkgop2fyj7wydt-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" Cc: xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org --===============0389455323== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Daniel Vetter writes: > Yeah I think that's a pretty neat idea to reduce the lease complexity even > more. If the VR compositor is unhappy and wants a different mode, it can > simply nuke the lease and as for a new one. Forgot to say that :-) Not sure it changes the lease complexity, but it reduces the potential interference with the X server after the lease is created. Hrm. Thinking about the impact on X a bit more, this seems hard - you can't just display the root window in the HMD, so you need a frame buffer to use. The VR compositor can construct this knowing the planned X mode, but, we then have to wire it through the whole X mode set infrastructure, which is not exactly set up to do that. I'll go look at the code in more detail, but I suspect the easiest plan will be to have the VR compositor set its own mode. That may fail if X is consuming too many display resources, but that doesn't seem significantly different from having the lease fail. This doesn't change the kernel API at all, so we can figure out the X bits separately from the kernel bits. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAljjzkYACgkQ2yIaaQAA ABEluRAAsaXstzzNYhbl40sz7AcVAJZwjMEN8Ok+ZGdlwe27o7RZhd9kSs2vedEr 3dEfr9OpBQwSUSHjla/PS+OJ8NSLv3sNxvFWMSgKPjaRaACfhwtAQ+ENX0EAbLdF qrFR1AFSUCMff+deO8q2Cdcmp+ChWVe+cjVEpE6ivqwuqguephlBMg5ohRjyw+si sdpMJGOMiTc6ui5fghXteJf7826YY8JHyVi1rMM44Aja9vkpEtmh40iKIkAc7n7X eyrzh0OmBOYfPqB5Tai8SnbZIK9jHB1MSHcup2UOIijrrHYiLXPybnZxWxkN9A2b /mypo9O8WIs6BRPpeuVUB0f/1RpBSRyPV06IaK19vEML7FUIZG86kxcbbKz9sGm5 aF0f1JZVL/JhNUyaLtdXQ7cUuUsqzUvOPG984ww8Hv2ttewjQE0Ypp8lg5nPgjE6 50VJhglDLS6CLoXvE0/NXYaEHzsZq4AuCXv30CyxHDJohscfm3EGdnNA7uxIm8Gs jH63VeSjx9sWpifeu4KFOHiRheMDdLfVh92bOA/7TPifFUjeBGfm0RZdehcFrzz3 ygtqzyi7fsFlm9eHUw3BBDD5ZpJ0AjglewW04+q5PyVGOqjBb5c8zBl7wbPSKvF7 vqyM5Ch2GL6BLSDt7dtJFzYpNd1ZilO28mbOuxFZuSKdttU90VU= =pDnt -----END PGP SIGNATURE----- --=-=-=-- --===============0389455323== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============0389455323==--