Pekka Paalanen <ppaalanen@gmail.com> 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. 

> 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.

-- 
-keith