On Wed, 21 Dec 2016 09:54:07 +1100 Graeme Gill <grae...@argyllcms.com> wrote:
> Pekka Paalanen wrote:
>
> > 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).
I suggest that compositors use the CMS you have spent so much time and
effort perfecting, and you start with the assumption that they will not
or cannot do so. Why?
> 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.
Are you implying that the CMS you worked on so hard is impossible to use
from a compositor?
No, I do not mean forking the CMS and shoving the code into a compositor
project.
I mean libraries, services, daemons... does your CMS really not have
any such interfaces?
Now that I think of the history, that's likely true due to X11 and
having a single display server implementation ever that even declined to
integrate with CMS.
> 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.
Yes! The CMS needs to provide the API that all compositors could use.
Even in the X11 case, simply shoving something into the CLUT directly
did not work. You can have multiple apps messing with the CLUT (e.g.
redshift, right?) without knowing about each other, leaving the user
clueless of the state of the display. I believe modern display hardware
start with a CLUT-matrix-CLUT pipeline and continuously invents more
ways, so "just set the CLUT" is already an outdated approach, not to
mention that each hardware plane might have its own pipeline setup
(Wayland compositors will use hardware planes at opportunity at their
own discretion, and completely transparently to any clients). The CMS
could control the X11 compositor or window manager only if that
compositor or WM actually listened, which requires explicit support
coded in it.
The situation on Wayland not that different. You still need the
{ display server, window manager, compositor } process to work *with*
CMS to produce best results, and it even offers significant benefits
like choosing a more appropriate blending space or automatic and
GPU-accelerated color mapping, plus preventing fighting over control.
You don't have X11 for communicating between the compositor and CMS,
now you need a library interface. It's not something one wants Wayland
for, because Wayland is IPC, implying the two parts are in separate
processes.
If you design the compositor-facing interface as a library ABI in your
CMS, then you have the power to design it right and tell compositor
developers how to do the right thing by using it.
Here, now, you have the opportunity to design how to integrate CMS with
Wayland compositors, in a mutually cooperative way between the two
software suites. You could aim for much much higher than just "I need
to control the hardware to begin with".
This, added with the power of adding implementation-specific Wayland
extensions at runtime(*) from within the CMS, should let you implement
much much more than you ever could if you stuck with the X11
architecture "I need to control hardware directly from a CMS tool that
is a Wayland client and the compositor has to stay out of the way".
Thanks,
pq
(*) Doing this requires a library ABI that the compositor will call into.
pgpHGMuIXclIx.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
