HDR support in Wayland/Weston

[Carsten Haitzler]

On Wed, 6 Mar 2019 16:37:55 +1100 Graeme Gill <graeme2 at argyllcms.com> said:

> Carsten Haitzler (The Rasterman) wrote:
> > apps should not have exclusive access. we're re-doing the whole horrid
> > "install colormap" thing from the x days of 256 color (or
> > paletted/colormapped displays).
> 
> It's not quite the same thing in all cases.

it involves a screen or set of screens "flashing" between different
colorspaces. it's much the same kind of effect of ye olde colormap installs.
not as extreme, but still the entire screen content changing appearance as one
client is taking control.

> A game doing this - yes, it's setting it up just for its
> private use.

a game should not either. it's a window (surface) within a larger ecosystem and
doesn't own the display. the compositor's job is to ensure that everyone plays
nice together and to ensure the user has as seamless an experience as possible.

the client can provide colorspace info/lut's alongside a surface/buffer and
then leave it up to the compositor to implement it or not (alongside perhaps
the ability to query for such extended features if they exist in the
compsitor at all - this is a question though of what is the baseline
featureset we expect from compositors)

but it shouldn't CONTROL the output (via any explicit or implicit protocol and
specs). if the compositor chooses to remap everything on screen so that the
appearance remains constant based on the focused surface (surface A with
colorspace X and other surfaces with colorspace Y it can transform to a single
colrospace based on what the screen is configured to display at the time to
provide visually a constant experience if possible).

for the purposes of calibration, imho a calibration tool should just use
drm/kms directly and run in a console outside of wayland. it then owns the
display. it's not like it's a commonly used tool (likely once on purchase of a
gpu and/or a monitor). it shouldn't even be needed for pre-calibrated monitors.
it can calibrate alongside appropriate colorimeter tools and work out some
profile screen by screen to be given to the compositor in a standard well
documented format. the compositor then can use that profile to know the true
color output of that screen and can appropriately adjust content.

> Color calibration or "blue light filter" not really - they
> are using it as a mechanism for deliberately altering
> the color of the whole display so that it affects the appearance
> of all other applications.

blue light filter is a "compositor problem". it may or may not farm it off to a
client but it's not something that should be allowed by clients in general -
these are at best speciality clients that work closely with a compositor, or
more likely something compositor specific via whatever extension mechanisms
that compositor supports.

implementing any such protocol for clients is just going back in time to
clients messing with key repeat and users wondering why their key repeat is now
broken as the client doesn't do it right or colormap installs forcibly being
done by clients, or clients messing  with screensaver params to try force it
to turn off then users complaining that screen blanking is broken and it ends up
being some random client they didn't know about, or the screen resolution
changing and multi-monitor config being nuked because some dumb client decided
to use xf86vidmode to change screen res not knowing that people might have
multiple screens configured via xinerama or xrandr and then not even bothering
to restore things afterwards either. i've seen many of the outcomes and
problems of giving clients direct control over the screen over my decades in
x11, and it's a bad thing. we shouldn't repeat the same mistakes. once you open
up these doors, they are impossible to close because you now need them for
compatibility.

> Whether the latter two are in conflict is an interesting question.
> 
> For the purposes of getting a known color behavior they are
> in conflict. But then they could also co-operate :- the
> "blue light filter" could make use of color management
> to implement a specific transform, and do it in such a way
> that the white point relative color behavior remains unchanged.
> 
> Cheers,
> 	Graeme Gill.
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com