Pekka Paalanen wrote: > On Tue, 20 Dec 2016 15:17:31 +1100 > Graeme Gill <grae...@argyllcms.com> wrote:
> When I was talking about configuration, your reply talks about content > delivery. We are continuously talking past each other. I talk about one > thing, you deliberately interpret me talking about the other thing, so > that you can make me look silly. I'm tired of correcting that in every > turn. You weren't talking about configuration, you were talking about control. They are not the same thing. An application determines (i.e. is in control of) the content it wants presented to the user. That is its role. If it isn't in control of that, it can't do the job the user expects of it. [ And yes, I too am finding it rather tiring to be explaining color management fundamentals over and over again. ] > Clients control what they send to the compositor: that is content > delivery. Exactly. Part of that content is color. To control that particular content, the color values depend on the display they are being presented on, i.e. which Output. So at some level the application needs to know what outputs it's content will be delivered to, in order to provide the correct content. > Configuration controls compositor's global settings, like CRTC CLUT > values. Yes. But certain aspects of a display are both operational elements _and_ configuration. To a color calibration application, the VideoLUT is an operational display element, just like the pixels values are to other kinds of graphical applications. It's not configuration. Once it's done, it becomes configuration for other applications using the display. So I'll agree that you can classify such an aspect as either content (in the sense that it is a graphic output element an application needs to manipulate to function), or configuration. I'm sure you will say this is more configuration that content - fine. But from the the calibration application writers point of view, to write such an application it's very highly desirable (i.e. may make the difference between such an application existing or not) that there be a standard API to operate this graphics system element, that is common and supported by the graphics display system that it is intended to "configure". What's the path for that, if it's not a Wayland protocol extension. Is there a standard Wayland configuration protocol that can be extended ? (And no, color calibration and profiling is not a "do it at the factory and pre-install it" type of thing. It's something some users want to do regularly.) > Why would you not let compositors use the CMS libraries people have > developed? Nothing stopping them inventing their own color calibration and profiling system. But can they afford the development effort ? (My own color software has been developed over about 20 years). There may be source code available to them under licensing conditions that allow them to include it in the compositor, but do they want to maintain such a port, and is it really a good idea to want to include a full blown application of considerable size and complexity, within a compositor ? (All that color measurement instrument support!) Do users want to be locked into a single choice of such a built in application ? Is it really expected that the compositor has to be updated every time there is a bug or new feature in the color management code ? Maybe they can include a very stripped down version of color management applications (as Richard has done in Gnome), but that isn't going to satisfy color critical users, and seems rather contrary to open source philosophy to deny users any way of using something else instead. Answer - this seems rather unlikely to be a viable path. It's not reasonable - color management applications need to be independent applications to be practical, and the alternative is fairly simply by comparison :- provide the API's needed as standard. > This is where we disagree, and that prevents us from making any > progress. It's up to you. I've laid out some sketches based on existing working systems of how color management could be supported in Wayland, but there are lots of variations of how to do it, as long as they acknowledge the logical realities of how color management works, and the practical realities of how the associated applications work. Suggest some approaches that take it forward. Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
