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, 9 May 2017 10:08:12 +0300 Message-ID: <20170509100812.7458f43b@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> <20170504111346.767f7501@eldfell> <86inlg7b5n.fsf@hiro.keithp.com> <20170505112023.46106d46@eldfell> <867f1v1iut.fsf@hiro.keithp.com> <20170508134755.4a34176b@eldfell> <86fugfxt7p.fsf@hiro.keithp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0407561045==" Return-path: In-Reply-To: <86fugfxt7p.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 --===============0407561045== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Eiy1Vg=M3+4Fqbm0BTuQ3WU"; protocol="application/pgp-signature" --Sig_/Eiy1Vg=M3+4Fqbm0BTuQ3WU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 08 May 2017 08:29:30 -0700 Keith Packard wrote: > Pekka Paalanen writes: >=20 > > 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. =20 >=20 > I agree this would be useful, but it raises a pile of complications: >=20 > 1) Obviously these overrides will conflict with the existing entries, > which goes against the 'don't allow conflicting entries' clause we > discussed earlier. >=20 > 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. Hi Keith, I suppose a sysadmin could add files to the system location... in /etc, to supplement the distributed files somewhere in /usr/share or something? For user-friendly settings, maybe those would need to be specific to the display server or the DE, and we should just not spec any per-user things. Oh, but you need Xorg use them before the DE is up... umm... erk. :-/ > 3) Would we provide a protocol mechanism to update them? Or would the > window system be expected to scan for new entries automatically? *shrug* > Can we safely put this off to the future? Unsure about "safely", but I think it would be the best. We have acknowledged the issue and that's fine for now. > > The policy to deal with output categories and individual outputs would > > be in the display server configuration. Something like: =20 >=20 > Oh, that's a cool idea.=20 >=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? =20 >=20 > 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 later thought about another mismatch with the current usage of OutputClass. Since the only thing it can be used for (according to the manual) is matching against the kernel driver and assigning the Xorg driver, it is matching to card devices, not individual (RandR) outputs. Right? So it's matching on the wrong level. That means we probably cannot use the otherwise perfect name OutputClass for, well, output classes. > 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. Awesome. Thanks, pq --Sig_/Eiy1Vg=M3+4Fqbm0BTuQ3WU Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlkRatwACgkQI1/ltBGq qqflLA//d8yCB6/w0ZsmYob2F+9uxi1dJURyBM2KzNsmIpSRZlD8II+l7Mmj3/Dk nlLzCdUZNfIi2sYPTT5Ulx/v/uGcGo2dt8TsEQN6RbdFS2BLBZDnGObtKLnPLhVx CA9oSXSsuTpR/OtiAFyyLYysJM5t6HkkYMHk1APMKZyz2V3/OTeYMBdiFUdUcc3D I2c5gNBJ3yKHcfg8NmN9ae64NOP9gvurnN8KjfLssqVDpqlBawhUMU5DI3P+7R2F oRjjrCfOc1Umt4GbHfVTM1GpUXGNJFQWVV/pdKxh0FsaXpfbqLXAy7SfzeJmPjI6 9cCB4cUlhkbXXxNj2iYS/ILGcWyiF4YKbjOwVIkh3C1uzZ9mDwyCin9s0az4f/p6 rA8fDnRB0d7nTbn8eDaj5ICZuja3UIuwbLZKY8PgvtDr7I+YsEAelTJUfdltc6YV WM3QTTUW64AmVzXRBQraHxaV16A6QVobWJ6pGfVLjtxNpUJo9Bm1mEMaLL+3PfPx FPmERCrGhkPsaOESwSbRwoSS8vb4emHWuVmaxxYxRD3cQlpaTfkyEm5N2Eim4Gv2 tzS9sIDCKzbbLiRFvz+zQe7ZRJYw2eAMCzwOgCIrI7GUSVZfU9sIFdIR6evSSFvo YCng5CBXoFFnoUmrQeC974+5mhrJWWR0evmV4ckyZgL2+suI+ao= =3W54 -----END PGP SIGNATURE----- --Sig_/Eiy1Vg=M3+4Fqbm0BTuQ3WU-- --===============0407561045== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG9yZy1kZXZl bEBsaXN0cy54Lm9yZzogWC5PcmcgZGV2ZWxvcG1lbnQKQXJjaGl2ZXM6IGh0dHA6Ly9saXN0cy54 Lm9yZy9hcmNoaXZlcy94b3JnLWRldmVsCkluZm86IGh0dHBzOi8vbGlzdHMueC5vcmcvbWFpbG1h bi9saXN0aW5mby94b3JnLWRldmVs --===============0407561045==--