HDR support in Wayland/Weston

[Pekka Paalanen]

On Fri, 1 Mar 2019 12:47:05 -0700
Chris Murphy <lists at colorremedies.com> wrote:

> On Fri, Mar 1, 2019 at 3:10 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > On Thu, 28 Feb 2019 18:28:33 -0700
> > Chris Murphy <lists at colorremedies.com> wrote:
> >  
> > > 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.  
> 
> I made a typo.
> s/client/kernel
> 
> Or has LUT manipulation only ever been done via X11?

Hi Chris,

X11 apps have (hopefully) done hardware LUT manipulation only through
X11. There was no other way AFAIK, unless the app started essentially
hacking the system via root privileges.

The current DRM KMS kernel design has always had a "lock" (the DRM
master concept) so that if one process (e.g. the X server) is in
control of the display, then no other process can touch the display
hardware at the same time.

Before DRM KMS, the video mode programming was in the Xorg video
drivers, so if an app wanted to bypass the X server, it would have had
to poke the hardware "directly" bypassing any drivers, which is even
more horrible that it might sound.

Non-X11 apps, such as fbdev, svgalib, DirectFB, etc., would be
something different that I'm not too familiar with. Fbdev was a
standard'ish kernel ABI, while the rest more or less poked the hardware
directly bypassing any kernel drivers, if not using fbdev under the
hood. These I would just ignore, they were running without a window
system to begin with.


> > > 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.  
> 
> Case a) is a subset of the calibration/characterization application's
> requirement.
> 
> Even if it turns out the application tags its content with displayRGB,
> thereby in effect getting a null transform, (or a null transform with
> whatever quantization happens through 32bpc float intermediate color
> image encoding), that's functionally a do not color manage deviceRGB
> path.

What is "displayRGB"? Does it essentially mean "write these pixel
values to any monitor as is"? What if the channel value's data type
does not match?

I suppose if a compositor receives content with "displayRGB" profile,
assuming my guess above is correct, it would have to apply the inverse
of the blending space to output space transform first, so that the
total result would be a null transform for pixels that were not blended
with anything else.

> > > 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.  
> 
> It is fair to keep track of, and distinguish a display path with:
> 
> 1. no calibration and no/null transform;
> 2. calibration applied, but no/null transform;
> 3. calibration and transform applied.
> 
> The calibration application does need a means of ensuring explicitly
> getting each of those. 1, is needed to figure out the uncorrected
> state and hopefully give the user some guidance on knob settings via
> OSD, and then to take meausurements to compute a corrective curve
> typically going in the video card LUT or equivalent wherever else that
> would go; 2, is needed to build an ICC profile for the display; and 3,
> is needed for verifying the path.
> 
> An application doing color management internally only really needs
> path 2. Nevertheless, that app's need is a subset of what's already
> needed by an application that does display calibration and profiling.

Yes, this is very much why I would prefer
measurement/calibration/characterization applications to use another
protocol extension that is explicitly designed for these needs instead
of or in addition to a generic "color management" extension that is
designed for all apps for general content delivery purposes.

I presume the measurement or calibration use case always involves
"owning" the whole monitor, and the very specific monitor at that. That
is, making the monitor temporarily exclusive to the app, so that
nothing else can interfere (e.g. instant messaging notification popping
up just under the measurement sensor). That would also give an
opportunity, if wanted(!), to bypass compositor color conversions and
do or not do anything else special.

IOW, measurement/calibration/characterization is off the scope of the
currently on-going discussions.

As a precedent, Weston has a separate protocol extension for
calibrating touchscreen touch points. There was a calibration app that
was using just the normal input interfaces all apps can use, but the
shortcomings of that made it very painful to use correctly and there
were no guarantees it produced the correct result. It also could not
load the new calibration into the compositor at all, and was not able
to compute it in the coordinate system libinput needs it. With a new
protocol extension designed specifically for calibration all these
problems went away:
https://lists.freedesktop.org/archives/wayland-devel/2018-March/037610.html


Thanks,
pq
-------------- 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/20190304/a89f588f/attachment-0001.sig>