Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Pekka Paalanen]

On Mon, 08 May 2017 08:29:30 -0700
Keith Packard <keithp at keithp.com> wrote:

> Pekka Paalanen <ppaalanen at gmail.com> writes:
> 
> > 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.

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:  
> 
> Oh, that's a cool idea. 
> 
> > 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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170509/6b1c5be6/attachment.sig>