From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs Date: Fri, 7 Apr 2017 10:56:18 +0300 Message-ID: <20170407105618.200ad289@eldfell> References: <86fuhrka4t.fsf@hiro.keithp.com> <4caa78af-7dc8-fbcf-d2ca-285d4554f5c9@daenzer.net> <86zifsyl6o.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1010886774==" Return-path: In-Reply-To: <86zifsyl6o.fsf-6d7jPg3SX/+z9DMzp4kqnw@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: Keith Packard Cc: xorg-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, Michel =?UTF-8?B?RMOkbnplcg==?= , dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org List-Id: dri-devel@lists.freedesktop.org --===============1010886774== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/49yD.C.MEQVRn.Vz/gvwyog"; protocol="application/pgp-signature" --Sig_/49yD.C.MEQVRn.Vz/gvwyog Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 06 Apr 2017 20:02:23 -0700 Keith Packard wrote: > Michel D=C3=A4nzer writes: >=20 > > When no such special client (Steam?) is running, the desktop environment > > will try to use the HMD anyway, right? So the expected use case would be > > for the user to start a special client first and only plug in the HMD > > afterwards? That seems a bit inconvenient. =20 >=20 > I'd love a better alternative, but this is the best I've come up > with. >=20 > Of course, it needn't be the actual VR client, it could be a stub > application that popped open a 'which app would you like to run on the > HMD' chooser of some kind, or even hooks in the desktop system that > managed that. >=20 > Suggestions very much encouraged. Hi, we need some kind of a database to recognize HMDs in any case, right? It would be best if the database was shared, so that everyone could recognize all HMDs, at least as far as one can do that based on EDID. If we had such a database, perhaps interfaced with a library, when how about Xorg using that library to automatically recognize and hide HMDs? That library would of course be also used by all HMD-supporting Wayland servers. If there was such a library, maybe it could also handle EDID parsing once and for all... a libinput for outputs? Btw. I was also told at #openhmd that some HMDs do not appear as connected outputs until you specifically turn it on via USB. So there is going to be a hotplug, and you'd want to avoid sending that to normal X11 clients so that they won't race with the special VR client grabbing it. Thanks, pq --Sig_/49yD.C.MEQVRn.Vz/gvwyog Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAljnRiIACgkQI1/ltBGq qqf2yhAAr4ByvSfaYJdTzBuptna8XstyD5rqrtsD1hnP8q3vw4pnvAMdejWeZU6A dmIgIvhBjPBtPsbetA3CAUIKzc2vvL5nRejaV1K7rGFpOsqI1RStEfkFmfUCAZdy zLw3lWSmSQ5SFMtivjBmRzyLOVfau2V/E+ViAzsQThLnObrVx+k4fPHNLtrbJs2e p9XwyHjFmzsRJItbIFGQO7EvvLAYIGrfrKA7g8bJQ5DYi2fgzTa8wYf6qLliJ9Gf 0CB6MBPIApUcRH36eJkkBW6qV1WC78YiKxopwPD7AlZDcuc32ayjjbbygsqhkQHx /HhVuGb58Mcl3lIe5MAvfBzi3ohpQF2Um5eX4raBylQZzD1RcsEr2+7S7CKvfXbw 5eXXnO1N4oo0YNe0+wOv7ntTB5ASvMBTb6P9pQ019jBfURHU79e3qqpDUU6Vj7SG qBrMCYjBwKe/EYtpLrrdLyP/0Mk5cghyOEAwts4RCXmgd/Dii9FgxmuqpJsxi6SM +VhSTJ8sGSk0VLLMuVh13ZiFTpl5EdaLK6UbLOFlotiQvJZu3XlCenzLfw5O9E39 YXj12I/ftDvpX42dcmEDIPFQ3LKY1VUtAHXzU2L9OuPpmZnsjpA6lohgn5/eJIn7 l8fnNzTScRGn4PAulPjCMMV8AOp99k+H7mhiF40V9frEXLeWK8A= =yEEm -----END PGP SIGNATURE----- --Sig_/49yD.C.MEQVRn.Vz/gvwyog-- --===============1010886774== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============1010886774==--