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: Mon, 10 Apr 2017 13:39:26 -0600 Message-ID: <86tw5wvyq9.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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1100709530==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Alex Deucher , Daniel Vetter Cc: "X.Org Devel List" , Maling list - DRI developers List-Id: dri-devel@lists.freedesktop.org --===============1100709530== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Alex Deucher writes: > I think there is a definite use case there. I agree. What we're missing right now is someone interested in driving an implementation of that use case to help define the right interfaces. Lacking that, we're not likely to come up with a good solution on our own. I think that's what Daniel is concerned about -- specifying something in the absence of an implementation using it. I took a stab at this and added the ability to change leases on the fly, and to create 'sub-leases' from an existing lease. He's pushing back on those features, and I think his reasons are sound. > Why do we need to make X aware of the lease stuff? What about having > some pre-X configuration that decides how to split up the display > resources. For multi-user, this makes a lot of sense; you'd want the system to allocate resources between users to allow them to operate fairly independently. For single-user with a hot-plugged HMD, I'd suggest that having X involved makes a lot of sense -- you may have to interact with the user to reduce resource consumption so that the HMD can be driven successfully, and that will involve poking at the X configuration. > It could be user defined static or dynamic based on what is attached. > You can just start X on the device nodes with whatever resources they > are assigned. In the multi-user case, you can statically assign > resources to each node; in the VR case, you can detect the HMD and > automatically assign it's resources to a separate node or override if > necessary. I don't think we've precluded this for a multi-user environment, and I think it's a good plan in the abstract. I will, however, suggest that asking for VR applications to wait for the desktop environment to be re-architected so that display resources can be centrally allocated by a new 'display resource manager' seems like a rather steep requirement. What I do want to ensure is that these two use cases can both be supported by the kernel interfaces we define, and that we can work in user space on either design going forward. If you'd like to start exploring the design of such a central service, that'd be awesome. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAljr328ACgkQ2yIaaQAA ABFq9A//XNHL1VdPGu92cc2zENciuCRVcNuPelsiG7iUduqS894i4Th6dVcDnyj6 oiK389y4P664DV4ivZ9bHItOrjxbqABaeEl87NV2Ceu2DQ7ofZG0gSvUV69EFCFQ NmahZSgRRY7UFeMUemQb4sJEtezbpH22OWAmKbnqTVpeMm8PPPrBNOTwADrAT8Hi i8HUcABmLddcvxRf0KYQzANqGeudd8XuyEYKARfVozV0+hcIkO5Sp1pRqN+g0cWV UPx9FdWYU7o7Ryb2YmWy34KYxmuTGWoMTwZqKfTLUkeY/TK0LvMWfnuH3HsK77JL I0a7hNRljKrzxd1GkIqcymr+9QBHh5JYatK4Eten6lTyMzBOKn5SmOJ4DbXb1KBs UviAnvTs1G4gSQZe6/hmtOefHzJP6tsdgtUX0UB/PHYLcXrtmV3nTtHXRL+FPRA5 e4bSgUucl00dSXKcS5ZwjJ5Q7/4a9jLkehMY/0Amzju+hejSkt65aCnGnYHQbrkc I2JdNeTh5e7LAnM4ZFZtEBkpA2dZekMabfEb7EBVTMwx39RsWjowVjLtZoVMLiOc s9nBKSTRKQDtT24DRmMY4MPUmAQm8xGPT+AVUCP75gqUhrTiZVtup6mVjNVYJhmC GbHf5OVzI1hEzqwQWbGV1xJw3dZGZ646U8x7+Mm+WtxBrcdnGfY= =VyFN -----END PGP SIGNATURE----- --=-=-=-- --===============1100709530== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1100709530==--