HDR support in Wayland/Weston

Pekka Paalanen ppaalanen at gmail.com
Fri Mar 1 10:10:18 UTC 2019

On Thu, 28 Feb 2019 18:28:33 -0700
Chris Murphy <lists at colorremedies.com> wrote:

> On Thu, Feb 28, 2019 at 2:35 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Wed, 27 Feb 2019 13:47:07 -0700
> > Chris Murphy <lists at colorremedies.com> wrote:
> >  
> > > On Wed, Feb 27, 2019 at 5:27 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:  
> > > >
> > > > there is a single, unambiguous answer on Wayland: the compositor owns
> > > > the pipeline. Therefore we won't have the kind of problems you describe
> > > > above.
> > > >
> > > > These are the very reasons I am against adding any kind of protocol
> > > > extension that would allow a client to directly touch the pipeline or
> > > > to bypass the compositor.  
> > >
> > > Well you need a client to do display calibration which necessarily
> > > means altering the video LUT (to linear) in order to do the
> > > measurements from which a correction curve is computed, and then that
> > > client needs to install that curve into the video LUT. Now, colord
> > > clearly has such capability, as it's applying vcgt tags in ICC
> > > profiles now. If colord can do it, then what prevents other clients
> > > from doing it?  
> >
> > Hi Chris,
> >
> > there is no need to expose hardware knobs like LUT etc. directly in
> > protocol even for measuring. We can have a special, privileged protocol
> > extension for measurement apps, where the measuring intent is explicit,
> > and the compositor can prepare the hardware correctly. This also avoids
> > updating the measurement apps to follow the latest hardware features
> > which the compositor might be using already. An old measurement app
> > could be getting wrong result because it didn't know how to reset a new
> > part in the pipeline that the compositor is using.
> >
> > Hence the compositor owns the pipeline at all times.
> >
> > Permanently setting the new pipeline parameters is compositor
> > configuration - you wouldn't want to have to run the measurement app on
> > every boot to just install the right parameters. Compositor
> > configuration is again compositor specific. The privileged protocol
> > extension could have a way to deliver the new output color profile to
> > the compositor, for the compositor to save and apply it with any
> > methods it happens to use. You cannot assume that the compositor will
> > actually program "the hardware LUT" to achieve that, since there are
> > many other ways to achieve the same and hardware capabilities vary.
> > Nowadays there is often much more than just one LUT. Furthermore, in my
> > recent reply to Niels' color management extension proposal I derived a
> > case from the proposal where a compositor would be forced to use an
> > identity LUT and instead do all transformation during rendering.
> >
> > Colord is not a client. Colord is currently called from a
> > weston plugin, the plugin has access to the compositor internal API to
> > set up a LUT. Colord cannot do it on its own.  
> That all seems reasonable.
> I'm curious how legacy applications including games used to manipulate
> actual hardware LUT in a video card, if the application asked the
> client to do it, in which case it still could do that?

Hi Chris,

right now, in no case.

It would probably be possible to enhance Xwayland (the X server) to
implement whatever X11 offers as protocol for LUT manipulation, and
forward that to a Wayland display server (compositor) using a new
Wayland protocol extension where Xwayland attached that LUT to all
Xwayland wl_surfaces. Then the Wayland compositor would apply the LUT
per wl_surface.

This would have nothing to do with the color management extensions now
being under discussion, unless Xwayland grew the capability of
manufacturing an ICC profile out of that game given LUT. I suspect that
could be inconvenient.

> Also I'm curious about the multiple display use case. I think it's
> quite a lot to ask a client to know about multiple transforms for
> multiple displays and which pixels to transform and how, based on
> which display those pixels are currently displayed on, and then
> somehow to intelligently cache this so it doesn't bog down the whole
> system. A use case in particular I'm thinking of is Firefox, where you
> really don't want to have to constantly do transforms of everything,
> every time a pixel scrolls away and vanishes, but when it reappears
> it's reappearing on a different display. And also you'd want the pixel
> to look correct from the very instant it appears on a different
> display and is correct upon appearing back on the original display or
> even looks correct in a split/mirrow window scenario, laptop display +
> projector.

The approach already suggested from my side and other people, that is
encoded in both of the two protocol proposals, is that the client
describes the image content, which allows the compositor to do whatever
the correct transformation is to each display. The client does not need
to do anything per-output (unless it very much wants to). This enables
not just what you mentioned, but also showing the same client pixel
correctly on multiple different outputs at the same time.

> At least on macOS and for the most part Windows, most applications
> aren't color management aware, and just assume deviceRGB color for
> everything; and at least on macOS by default, and Windows as an
> option, it's possible for the window manager to substitute what is
> really "legacy deviceRGB" for sRGB as an intermediate space and from
> there properly do display compensation for pixels on whatever display
> they appear on. Ergo, a display calibration app does need a way to
> announce its ability so that its test chart isn't being assumed to be
> sRGB (or whatever), and a smarter color managed application needs a
> way of saying one of two things:
> a. I've already done color management, I *really do* need deviceRGB
> b. display this, its color space is _________.

Case b) is already in both of the protocol proposals.

Case a) is in Niels' proposal, but I raised some issues with that. It is
a very problematic case to implement in general, too, because the
compositor is in some cases very likely to have to undo the color
transformations the application already did to go back to a common
blending space or to the spaces for other outputs.

> Both types of applications exist. It might very well be reasonable to
> say, yeah we're not going to support use case a.) Such smarter
> applications are going to have to do their color management however
> they want internally, and transform to a normalized color space like
> P3 or Rec.2020 or opRGB and follow use case b.) where they tag all
> content with that normalized color space.

Right. We'll see. And measurement/calibration/characterisation
applications are a third category completely different to the two
above, by window management requirements if nothing else.


> And all of this has an equivalent path and transform for printing, and
> how to get sane output whether displayed or printed for the same
> content.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190301/929c04ab/attachment-0001.sig>

More information about the wayland-devel mailing list