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, 08 May 2017 08:29:30 -0700 Message-ID: <86fugfxt7p.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> <86lgqkw5p6.fsf@hiro.keithp.com> <20170502103945.4b52445e@eldfell> <868tmfl3lm.fsf@hiro.keithp.com> <20170503100809.262906bb@eldfell> <86tw5174y1.fsf@hiro.keithp.com> <20170504111346.767f7501@eldfell> <86inlg7b5n.fsf@hiro.keithp.com> <20170505112023.46106d46@eldfell> <867f1v1iut.fsf@hiro.keithp.com> <20170508134755.4a34176b@eldfell> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0602604887==" Return-path: In-Reply-To: <20170508134755.4a34176b@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 --===============0602604887== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pekka Paalanen writes: > I forget if I mentioned this to you personally yet: > https://gist.github.com/ppaalanen/e0d2744ff71188e9a294726a37ca83c2 Thanks, that's a helpful bit of thinking. It looks like most of that is still relevant, the only piece we'd swap out is how the bits actually get to the screen, which is a technical detail. > Thinking again, I believe we have to have a way to override > database entries somehow. If we ship catch-all entries for, say, > all Sony TVs, we are bound to get some assignment wrong for > someone who then wants to make a correction without breaking > everyone else. I agree this would be useful, but it raises a pile of complications: 1) Obviously these overrides will conflict with the existing entries, which goes against the 'don't allow conflicting entries' clause we discussed earlier. 2) Where are these new entries stored? If in files, then the window system is going to need to read them. They are user-provided, and so the window system is going need to be pointed at them somehow. Handing data files to the window system (which may run as a different user) seems likely to introduce security concerns. 3) Would we provide a protocol mechanism to update them? Or would the window system be expected to scan for new entries automatically? Can we safely put this off to the future? > We are moving away from configuring outputs in a display server by the > connector name and towards configuring outputs based the actual output > device identity and type. That works where EDID is available; it's more complicated when the EDID data is missing or corrupted (as often happens in presentation environments). Fortunately, I think this is a problem entirely outside the scope of the current discussion :-) > The policy to deal with output categories and individual outputs would > be in the display server configuration. Something like: Oh, that's a cool idea.=20 > Heh, I wasn't even aware there actually was OutputClass already, with > only MatchDriver. Wouldn't that be a good fit for static policy > configuration in Xorg? I don't think so; we want it to be independent of the driver. I think, for now, we can have a static policy implemented in the X server code and plan on making that configurable when we figure out where we want to configure it. I'll go implement what we've agreed on so far and make the rest just hard-coded for now. That way we'll have a starting point at least. Anyone care if it's JSON or XML? I'm afraid I'm leaning to XML right now because the X server already loads an XML parser (for DRM config files), and I feel like introducing yet another configuration language is probably worse than extending the use of XML? I could be convinced either way as XML is pretty awful. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAlkQjtoACgkQ2yIaaQAA ABGQjA/8DKFPab2IJVO/OZffmrAZo1c2EL5mRTb7Zai2Yvmwh8R8a0ccJYdlSWWd eyDFb8W7Ddw6lUIRMqJ7nxmuQx9Iy7ZHDnL9gLXEJeDQgdpCPQmQz1zN/3V6npkE Q4y0OYMebvCXhpO//kuyTJDEvTLqCiqXw1zALuKOBLIUkAx3q0zaT+BG1Z/3Zjwx 1zZbYTcrZR0x3Uqbj/cx/vvzPbndLZ79A2UdaBuv5fimHhbfIWYAGS7HFBgn+qM+ kWZmgsCTgKfVlI6AUlfYGgikjOlp5l51ksTxdN9Mi7bikNOzf5irmM5jYIIXh7Js 5mgqFbRkb9nIyitvKILifEofZy0UI8Zno78bxkExoTULjJxH6WF9o5t+ivziqovA 38txXg0VnV1J5KlFNMchy1L6EDvIoA8wOjakfk8ZwdalaFPRKdSiX4h0u7XdwUhV +DLi1filB3daPOx8KlAQjuVr1muctl7bJSya90ej2K9RnDlipcjKZXAxoVAfS5qh kjGpj+IqI+1ZP9tfZuFIwQ0b+oVE4A/dTqWbNz3f1gMbomVvka+wYjcvtN9A932A 7IpVzJUW7zr5+VekDLMOLkfiIVyEikerd8ilBCUC1aWjdUhPry/xB4mRHatfVpR+ NVavaFh1fpocnlWnOyRERGBMb2ggbkdovzoRiEJecevw4/xh4Jo= =pVhM -----END PGP SIGNATURE----- --=-=-=-- --===============0602604887== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============0602604887==--