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: Tue, 2 May 2017 10:39:45 +0300 Message-ID: <20170502103945.4b52445e@eldfell> References: <86fuhrka4t.fsf@hiro.keithp.com> <4caa78af-7dc8-fbcf-d2ca-285d4554f5c9@daenzer.net> <86zifsyl6o.fsf@hiro.keithp.com> <20170407105618.200ad289@eldfell> <86lgr9xzi4.fsf@hiro.keithp.com> <20170410143531.09b84bd7@eldfell> <86lgqkw5p6.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2065244520==" Return-path: In-Reply-To: <86lgqkw5p6.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 --===============2065244520== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/h3z6zeqm3JlOP9ULoiUlxJc"; protocol="application/pgp-signature" --Sig_/h3z6zeqm3JlOP9ULoiUlxJc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 28 Apr 2017 15:03:17 -0700 Keith Packard wrote: > Pekka Paalanen writes: >=20 > > IMHO, if nothing is providing a picture intended for the HMD, the HMD > > should be off. There is no use in showing an arbitrary image that does > > not look right, is there? =20 >=20 > Well, if the HMD is being worn and the application crashes, then > what you want is something that keeps responding to your motion so you > can get the HMD off without falling or running into stuff... Hi, I was under the impression that if you have a VR application running on the HMD, it necessarily also implies that you have a VR compositor running, which means that there is always some process providing a valid image to the HMD. (At least in end-user setups.) Here the assumption is that the application may crash or stall, but the VR compositor never will. Obviously that's not exactly true, but if we design for also the VR compositor crashing or stalling, then we have a requirement for a tertiary process that is essentially just like the VR compositor. And so the turtles pile up... which is also why I don't think a backup plan for the VR compositor is necessary. Or did you have an idea of something extremely simple that could still provide a reasonable image for the HMD even when the compositors have crashed and the GPU is frozen? However, your original question was: > * What should we do with an HMD which is in the database but for which > no application is installed on the host? =20 I assumed that means there are no VR apps nor a VR compositor that could handle the HMD. In that case I think the HMD should be always off. > But, yeah, in general, if you don't have an HMD application running, the > HMD can't usefully show anything from a bare window system. The trick is > to make sure existing desktop applications don't try to use it by mistake. Sure. > > even if the database was just a bunch of files, you still need code to > > access it, and probably something to ensure the entries are > > well-formed, so that everyone will agree on how to parse them. One > > should probably decide whether the database will only answer the > > question "is it a HMD?" or can it provide other information as well. =20 >=20 > Yup, we need a spec for the files that is reasonably sane, and also > extensible so that if we want to add new data, we can. I discussed this > with Eric Anholt at breakfast this morning and we came up with a couple > of ideas: >=20 > 1) A directory full of files, each file can contain one or more monitor > entries >=20 > 2) Monitors should be identified (at a minimum) using the EDID > Manufacturer ID and Manufacturer product code. I can imagine > also allowing the use of a serial number and/or date code if we end > up using this for more stuff later. >=20 > 3) Window system independent. We obviously need this for X, but > other window systems should share the same data. >=20 > 4) Use an existing format. Both of us would rather use JSON, but > there's already XML in the DRM world, so that might make > sense. These are functionally equivalent, but XML syntax is rough on > the eyes. >=20 > 5) Allow multiple definitions in each file, but allow for multiple > files too. >=20 > Here's a JSON-formatted example: >=20 > { > "monitors": [ > { > "Manufacturer" : "LGD", > "Product" : 437, > "desktop" : true > } > ] > "copyright" : "Copyright =C2=A9 2017, Keith Packard", > "license" : "GPLv3" > } >=20 > One can imagine the same done in XML, but I'm too lazy to type that > here. In any case, as you can see above, I've added a "desktop" field; > if false, the monitor would be hidden to 'normal' desktop applications > and only made visible to others. I presume that if "desktop" is set to "true", it implies that the HMD is capable of showing a simple 2D canvas in stereo without any special rendering and with the default video mode. That is, creating a sort of a virtual 2D monitor. That would be nice. > Questions: >=20 > Q) Where should the directory live. >=20 > A) /usr/share/monitors for distribution-provided files, /etc/monitors > for application-provided files. >=20 > Q) How about RandR protocol. >=20 > A) I'm thinking of just creating a new randr request like > RRGetOutputInfo but which will return even "hidden" outputs with > non-spoofed 'connection' value. >=20 > Q) What file names should the entries use. >=20 > A) How about just the manufacturer and product of the first entry? >=20 > Q) Ranges of product ids? >=20 > A) Yeah, we might want this to avoid a lot of duplicate entries. >=20 FWIW, it all sounds good to me! I don't really have an opinion on XML vs. JSON, I'm just happy it's not another ad hoc format. Thanks, pq --Sig_/h3z6zeqm3JlOP9ULoiUlxJc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlkIN8EACgkQI1/ltBGq qqejuRAAoHs9ZYD0fFcc0WBKnz8BWRReSZHAenhRHWOfN8mksduxdSfBsdP4TPac 3B2cTPeAeHM2OOXv/piRn+jvJxv9l+lTbAX9fZlXLhvRzzKCjp0P8r6fIXBpZWWM bIO/EHb62RygTPMai3ujX+UO/vmFCD+P3eZKgLeVx8jBvzcVi66aYojt+u/19kM4 k/K8Npf5kmZvoqcCVPct3ySCPbkEFLup1hWgmEJuJxtVc+2RMBoVANz43W+FUCmP qmhFKLSbURUdtW+kxeLOElnqy46l3Ct8DsKLtBzfrcuqt3c1h6qgoze3HHo03+V8 5+DdqsoqZg4K6YnX93SmsLClwVHR/A0Bpxl+rSyVqqcePS0Vv0ab1wVvlGJL8BDO /GikRGFUAlPyr/cNzg2CZzTFoeIaOLgxIkfwOjMwvK+u1fBjtxkumBXstrkdwC8J 74QRkmDOyHwQNlJ4ARfowrgQtEgPplF6pJX9u7lcX8LsKSSJHiXTEcwEoA0bYJyu MGMT0Xjm4s8p8LcVCC/Q0qUs9y1UEGQSTKm3VJR4c3pEHCxoLB0rV5q8hOUFqa3K IcPpohNtYZ4tFv70bNgbm4P04AAdPwGVBKxbQ1/RCamONDfFdHpceLRXSxclStre pKxRy7szdOwOtBorvKQAospe3BhzFmit/XPo3ql15D4JiJfnZK4= =FBDm -----END PGP SIGNATURE----- --Sig_/h3z6zeqm3JlOP9ULoiUlxJc-- --===============2065244520== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============2065244520==--