Daniel Stone wrote: Hi Daniel,
Niels Ole Salscheider wrote: > My working view at the moment is that whatever is doing calibration > should be directly in charge of the full insane complexity of the > display hardware, and that even enumerating this, let alone offering > control over it, is not tractable. Which leaves us with two options: > the compositor runs calibration, or external calibration apps do not > run under a Wayland session and just drive DRM/KMS directly. Really unattractive (i.e. a big obstacle) from a color management calibration/profiling application writers point of view. I certainly don't want to have to figure out any insane complexity of display hardware - that's not my applications job - I just want the access to the abstracted common color pipeline functionality that has always been available in every desktop operating system, so that these applications, and all the color sensitive applications can work. > This didn't make any sense when all display drivers were Xorg > components, but hey, we do have a universal API in DRM/KMS that you > can write applications directly towards, so I don't see why we should > bend over backwards making these compromises for special-purpose > clients which by definition do not interoperate with a regular desktop > environment. Sorry, but from my perspective this is completely insane. I think that adding a couple of well understood API's doesn't compare to modifying a desktop application to have to, on the fly switch from a normal application context into configuring and then driving a (basically) raw frame buffer, convey all it's user interface to the frame buffer to run test patches, and then switch back again. And I don't know what you mean by "do not interoperate with a regular desktop environment". These are perfectly regular desktop applications that happen to have a special purpose. Casting them adrift from the normal desktop environment raises their difficulty into the "requires heroic effort" territory, due to huge breakage of cross platform application compatibility alone, and is directly contrary to the very idea of what a display server and the overlaying application UI toolkits are meant to provide! I'm also thinking it would really help a lot if you and others contributing to this thread were able to procure something like a X-Rite i1 display Pro, run up the manufacturer provided software on MSWindows or OS X to get a feel for what it does, then fire up DisplayCAL+ArgyllCMS on Linux/X11 and take it for a spin. (Another path would be to obtain one of Richard's ColorHug's, but I think seeing how the commercial software operates as well, would add a broader perspective.) I can keep writing a lot of words, but they don't seem to be conveying much meaning without some common context. Cheers, Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel