On Wed, 14 Dec 2016 18:49:14 +1100 Graeme Gill <grae...@argyllcms.com> wrote:
> Carsten Haitzler (The Rasterman) wrote: > > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <grae...@argyllcms.com> > > said: > > >> Right. So a protocol for querying the profile of each output for its > >> surface > >> is a base requirement. > > > > i totally disagree. the compositor should simply provide available > > colorspaces > > (and generally only provide those that hardware can do). what screen they > > apply > > to is unimportant. > > Please read my earlier posts. No (sane) compositor can implement CMM > capabilities to a color critical applications requirements, > so color management without any participation of a compositor > is a core requirement. Hi, that is a very strange requirement, and architecturally it is a big step backwards. Applications are never in direct control of the display hardware. If they need to be, they need to be written directly on DRM/KMS, not Wayland. That way you truly get what you want: no compositor to mess with your colors, and no fighting between different apps demanding different display confgurations. If you really have applications this color critical, then you'd better do exactly this or provide/audit the compositor yourself. In every other case, there is a display server *with a compositor* between the application and the display. The compositor will necessarily copy and translate pixel values from one format to another, if not from color space to another. The compositor is also in control of the display hardware: color lookup tables, color transformation matrices, hardware overlays and direct scanout of client buffers at opportunity. Scanout hardware can often do color transformations on its own, with a method that might be unknown to anyone but the vendor. All of these depend on the hardware whether and which of them are available. What you are proposing necessarily leads to moving the control of all of these into Wayland clients. It may have been so with X11 where any client can change any display setting any time it wants, but I cannot see that happening on Wayland. If the pixels go through a display server, you have no choice but to trust the display server to do the right thing. So the real question is: "How do you let the compositor do the right thing?" Not: "How do I bypass the compositor?" You cannot take the compositor out of the equation unless you don't have a compositor at all. Here are some other points: - Blending will only be an issue if a color-managed window has non-opaque pixels. If the application cares about the end result, it should not have non-opaque pixels, because not only it cannot know *how* they will be blended, it also cannot know *what* they will be blended with. - You do not know which parts of a window are shown on which outputs. Some parts may be shown on multiple outputs at the same time. There is no provision for clients to provide a buffer separately for each output (you could add that as an extension). Therefore the same buffer content must be applicable to any and all outputs in the system. Unless all outputs have identical color profiles, this necessarily means the compositor must convert while compositing. - Different compositors will always have different levels of color management support. You might want the color management protocol extension(s) to implicitly or explicitly indicate the level, perhaps even validation/auditing certificates. (Think about, say, professionally calibrated workstations where all the hardware, the drivers, the compositor and settings have been verified and locked down.) - Calibration (i.e. modifying compositor configuration) must necessarily be a separate interface from the ones used by applications that only want to present color-managed content. Conflating it all into a single interface will cause problems with privilege separation and encourage usage patterns where different applications cannot work at the same time because they will be fighting over who gets to set the current configuration. Thanks, pq
pgpkfvlXjzgEN.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel