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: Fri, 28 Apr 2017 15:03:17 -0700 Message-ID: <86lgqkw5p6.fsf@hiro.keithp.com> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0393061555==" Return-path: In-Reply-To: <20170410143531.09b84bd7@eldfell> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Pekka Paalanen Cc: xorg-devel@lists.freedesktop.org, Michel =?utf-8?Q?D=C3=A4nzer?= , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============0393061555== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Pekka Paalanen writes: > 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? 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... 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. > 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. 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: 1) A directory full of files, each file can contain one or more monitor entries 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. 3) Window system independent. We obviously need this for X, but other window systems should share the same data. 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. 5) Allow multiple definitions in each file, but allow for multiple files too. Here's a JSON-formatted example: { "monitors": [ { "Manufacturer" : "LGD", "Product" : 437, "desktop" : true } ] "copyright" : "Copyright =C2=A9 2017, Keith Packard", "license" : "GPLv3" } 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. Questions: Q) Where should the directory live. A) /usr/share/monitors for distribution-provided files, /etc/monitors for application-provided files. Q) How about RandR protocol. 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. Q) What file names should the entries use. A) How about just the manufacturer and product of the first entry? Q) Ranges of product ids? A) Yeah, we might want this to avoid a lot of duplicate entries. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlkDvCYACgkQ2yIaaQAA ABFi7A//ferjdsqiTxQjhBylXasiKX4JOGXCEI8wwHnN9gD8hzR5zZw7YvbGY7RK 1tlFTrciWirrEMcGrxv8nuFGXjENNMBdYHRrlRdyUDCflJmtmei7V6k+8Xp2woTS QlIMs7xKvxhpb788ESdAQkC9N7QggVLbdfQxp4AnRWLp+FteKYBfTl2Vw7LMQsb7 JIcUhIY6O+XXckuX0axhJk93ZC+E09co41SN+izcER8PW9Os/50UDEwxTWGtFkIq jjv/MPCdkq43lAR8mp6LkZn/L/NSMUWOd3Kq2J6lF9r2CZjeLYoajLkL0+ce8M9L RrbIiwtdjGjwr6zqCOkZnSqvt71HlEUJsKw7Qtx5wcsdRC3vV0bW9kVXhMYnF9Ij 9hxTJfGMt6FGriwcKsdsFLq7ncr3zJiXytNijrXPoF1x3ROgRzp5ZODjKcvDjUEa SoSVj3IlEefkNVfCQxVVKfAltjiOc0wUZFZedzKbBdR5TaGbzCgyNMscH+igDqA9 2E2aO3dJ7S7rs9Q7cOR4ZMsD3eTkw1OUgbnLenvB8L+LWceZ/S/vNI5rMvQuchNO hc0+PIQJlzoKg+jFuEAay7OFGi5Poks+RRWAYxqEYs94/ibzw6Rircoad3gZ3okg MZtNL7+5qe6CXzgiPo3DwccE+0WRoQ+/8HAG3ehG42MNyb8qplA= =AcXg -----END PGP SIGNATURE----- --=-=-=-- --===============0393061555== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0393061555==--