[RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Fri, 13 Jan 2017 15:56:50 +0100
Florian Höch <lists+wayland-devel at hoech.org> wrote:

> [ Bunch of replies to different posts crammed into one, apologies in
> advance. ]
> 
> Pekka Paalanen wrote:
> > Would it not be simpler to just say "I'm doing calibration now, make
> > sure nothing interferes"?  
> 
> Sure, I just hope that "I'm doing calibration now, make sure nothing
> interferes" still allows conventional application UI (e.g. using UI
> frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
> effectively block users from interacting with said UI (going by your
> comment "I also forgot to mention that surfaces with the
> cms_calibration_surface role, when actually presented, would also
> guarantee that nothing else will be shown on that specific output"
> somehow sounds like it would not, but maybe I'm misunderstanding what
> you mean by "output". I would certainly not be enthused if I had to
> low-level re-implement parts of the UI I currently have - in fact I can
> tell you right now that it would never, ever happen if it's not as
> simple as writing for any of the common UI frameworks).

Hi,

my idea for a user story would be something like this:

- user starts a calibration app and clicks "profile output HDMI 2"

- optional: the compositor shows a dialog: "Application Foo wants to
  profile output HDMI 2. Allow / Deny ? You can press Esc to abort
  profiling after it starts."

- The output HDMI 2 gets filled with the profiling pattern according
  the application requests, and literally nothing else will show up on
  that output.

- If the user wants to abort the profiling run before it completes, he
  presses Esc, which the compositor grabs and restores HDMI 2 to normal.

- If the profiling finishes by itself, HDMI 2 is restored to normal
  automatically.

- The profiling application will know what happened in all cases.

How's that sound? I'm running blind here, because I've never used a
profiling app.

Would you really need the user to interact with the UI while the
profiling pattern is shown?

If you show any UI bits on the profiled output, how do you avoid the UI
affecting the profiling results? Keep in mind the window positioning
limitations in Wayland desktop.

Other outputs should remain normal during profiling, but of course
there might be only one output connected.

> Put bluntly, but I agree as well. A "calibration/profiling/measurement"
> application is not more of a "special-purpose client" than, say, a CAD
> application, a code editor, or an application that lets you create 3D
> scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.

Graeme just managed to explain to me why the profiling app needs access
to the VideoLUT (see [1]) which is a global resource. That makes the
profiling app a very special case on Wayland, because on Wayland we
very very carefully avoid unconditional access to such global
resources, so that apps cannot take the user or the desktop hostage or
mess it up even if they tried to(*). Changing the VideoLUT will mess up
all other windows on that output, and the profiling app will not even
tolerate any other windows on that output at the same time.

Any application you listed does not require similar access to a global
resource. A profiling app OTOH cannot use the normal content delivery
paths because as Graeme explained they often do not reach the full
precision without changing the VideoLUT.

Another example of where Wayland denies access to global resources is
that an application cannot make an input grab at will. Input grabs are
always conditional, and breakable. We should have similar behaviour
also with "screen grabs" like these.

[1] https://lists.freedesktop.org/archives/wayland-devel/2017-January/032616.html

(*) The classic example of messing up the user's desktop is games
changing the X server video mode, and for one reason or another (don't
care, bug, broken, crashed) never restores it to original, or even if
it does restore, all your icons on the desktop get squashed in the
top-left corner. That is one reason why Wayland does not have a RandR
interface.


> Graeme Gill wrote:
> > 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.)  
> 
> Even watching some videos of a typical calibration/profiling workflow on
> YouTube may already help.

That's an excellent idea! Could you recommend some, so I don't pick a
random "oh, but they're doing it wrong" video?


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170113/e29ea348/attachment.sig>