Pekka Paalanen <ppaalanen@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
