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: Thu, 4 May 2017 11:13:46 +0300 Message-ID: <20170504111346.767f7501@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> <20170502103945.4b52445e@eldfell> <868tmfl3lm.fsf@hiro.keithp.com> <20170503100809.262906bb@eldfell> <86tw5174y1.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0123859093==" Return-path: In-Reply-To: <86tw5174y1.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 --===============0123859093== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/nJ9AfFfPwc6=8g/4WuSia9V"; protocol="application/pgp-signature" --Sig_/nJ9AfFfPwc6=8g/4WuSia9V Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 03 May 2017 19:04:38 -0700 Keith Packard wrote: > Pekka Paalanen writes: >=20 > > do you mean to list all kinds of display devices in the database? I was > > assuming it would list only HMDs, so not in database would imply it's a > > normal display and good for extending the desktop to. =20 >=20 > I intended for it to be a general database to which we could add almost > anything; you can imagine using this to replace broken EDID values, > configure alternate preferred modes or whatever. Ooh, a much much larger scope than I assumed. Nice. That means you need an explicit key to denote HMDs. More below. We could probably use it to recognize projectors and such, too.... which makes me think that there should probably be an easy way to add more entries: you plug in a projector, it's not recognized as such, you tell your DE it is a projector, the DE goes and saves the match in the database. Should be pretty easy with the directory full of files approach you had in mind, if there just is write access. > The 'desktop' boolean says whether the desktop should be expected to use > the device or not; that's all I need for the HMD case. >=20 > > Or did you mean it for exceptions? As in, define a range of HMDs, but > > the vendor put a few normal displays in the middle of the range, so one > > needs to be able to exclude those? =20 >=20 > Oh, that's a great thought; I hadn't considered what we would do with > conflicting entries that mapped the same device. I'd like to make that > invalid, and potentially spit out a warning message somewhere... I'm not sure... disfavouring overlapping entries at least would save us from inventing heuristics on which one of the overlapping entries should be picked for a device. And if those heuristics would need to be implemented in each display server, more room for inconsistent behaviour. I think your idea is the better one. > > The reason I mentioned "virtual 2D display" was that I recall hearing > > that actually exists in some HMD hardware. If you don't do anything to > > enable a 3D mode, the HMD will process the signal to produce a virtual > > 2D display in front the user. In such case, there is no need for a VR > > compositor, the plain old 2D image signal will be shown correctly on a > > plane in the virtual space by the HMD hardware itself. =20 >=20 > Oh, cool! That doesn't help as it means the user will want to pick if > this happens or not. Maybe just don't include it in the database and let > the VR application turn off the X output before creating a lease? Or, list it in the database as both "desktop" and "HMD" for the same effect? That way the desktop would extend there automatically, but it would also be advertised as a HMD to clients. If it's not listed at all, would it be possible to advertise it as a HMD and DRM-leased out etc.? At least for Wayland, I'd like to not advertise "everything" as possible HMDs but only those that really are. > > Mind the note towards the bottom: you don't actually need a PS4 to use > > it - so it must be something built into the HMD. However, reading more > > details from > > https://blog.us.playstation.com/2016/10/03/playstation-vr-the-ultimate-= faq/ > > reveals that there is actually a separate processor box providing the > > cinematic mode. Sounds like it's your VR compositor as a middle-man > > hardware device rather than just a program. :-) =20 >=20 > Interesting. I guess it's a way to make it work without hacking the > desktop environment at all? It seems it should be capable of displaying the desktop out of the box, but I don't think there is a separate HDMI-in for actual VR content, so you'd still need to cooperate with the display server to turn it to VR mode and feed the VR video stream. I also read some discussions about 3D TV modes, but couldn't really get a conclusion if they are supposed to render like if you were in a 3D cinema theatre or not. Apparently that was enabled in a firmware upgrade and maybe had some extra requirements. I would guess the real purpose behind the cinematic mode is to get more content workable on the HMD earlier, as it allows you to play almost all existing games and movies that were not made for VR/HMD to begin with. > Thanks for your suggestions; I hope we're getting closer to some kind of > prototype at least... >=20 Thanks, pq --Sig_/nJ9AfFfPwc6=8g/4WuSia9V Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlkK4roACgkQI1/ltBGq qqd+jRAAnKqJMlMEusK4MJAR0SPeYdct//aD3yzLcaocfSv4TxqU6cXcrSTO/Ns7 2k4JVH4Beg7GliVsiIs1lly2Tbf9zXsGrIkb+4xSej8pvVWCnsgyKKiNbJS6bK/6 dX1v0gWcIpogRQVjjnL5SCIm6JCk3PPcZatVCtvvnM/BHzuPwbNs18nf7RQyaEM7 ppAmawQK4dg5/jsn+XIbJtuBPaJ3JkwcW2j5857dBM9bJzyLevApfn9EDAeJ96wH K2dJb0qgZZwuQd2Qh1/n7htf86qHW3zSVL1zHO1yDHRU35OFxiH6+2rFXQkny4N+ AdfvLPkyM8V84s250gx9AqV3Ad9oT+GKpkcUtKOL7ty83eblLoVc7JzfmYdPx50L 1tLyPiezw7lPxD+S26TwAYOdCy8JOSeCskenRirZ1JjJNiQ2JiG3npDJZ67h7T/X BaaE8QkoyUFKSH3xRvyaCGkA0RHrY/hkx6gaJwnHTaAi5KkYQFOYiiVeXluVg9wM Qw0iZ9wuqsq8uPuxnOjfbTOX8Rws0Qet321ijgaQW11xRDD3cuJnru+Yl9McPHJr EGk+sOZJapYjmZkAtp7xUjQN0viXj7pV/iA0AkWjxWhpb0rt2/hk1eY7Xh4LEi+K qvsO8cTEY7sPHPN7FY1n1q3eUgUTphNMLn8aS0t4RBk559xFpmQ= =Y+an -----END PGP SIGNATURE----- --Sig_/nJ9AfFfPwc6=8g/4WuSia9V-- --===============0123859093== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============0123859093==--