HDR support in Wayland/Weston

[Chris Murphy]

On Fri, Mar 8, 2019 at 3:31 AM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Fri, 8 Mar 2019 08:35:20 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:
>
> > Michel Dänzer wrote:
> >
> > > It sounds like KMS leases could be a pretty good fit for a calibration
> > > application. It can lease each output individually from the Wayland
> > > compositor and fully control it using KMS APIs, while the Wayland
> > > compositor continues running normally on other outputs.
> >
> > There seems to be this idea that has got a hold amongst many commentators
> > on this topic here, that somehow the display calibration and profiling
> > application NEEDs raw and direct access to the a display to operate.
>
> Hi Graeme,
>
> that very idea stems from the early Wayland color management
> discussions where it was strictly demanded that the application must be
> able to completely bypass the compositor and own the hardware to do its
> job correctly, because there is no trusting that a compositor could get
> color management right. That is how it essentially was on X11 since the
> X server did not second-guess or mangle application commands or images
> and it did more or less expose the hardware of its time as is, letting
> all the applications fight among each other for control.
>
> I'm happy to see the original demand been mostly replaced, but
> apparently it was so strongly underlined that understanding how much of
> it is actually necessary is hard.

It is an anti-historical demand that the compositor must be bypassed
for calibration and characterization. Since the first such
applications appeared on System 7 with color QuickDraw, there was the
exact same compositor in place for the "display profiling application"
(the application that does calibration+characterization+verification
and builds an ICC profile from the characterization and then installs
and registers it with the OS) as any other application. This is the
same today on Windows, with the DWM compositor, and macOS with the
Quartz compositor, and they can't be disabled.

> DRM leases are the modern idea for completely bypassing the compositor /
> display server, and taking full control of the relevant part of the
> display hardware yourself. DRM leases are driven by virtual reality
> (VR) use cases for head-mounted displays (HMD), where the VR
> application (or a VR compositor that is separate from the desktop
> compositor due to hard realtime requirements) will be driving the HMD
> directly by kernel UAPI (KMS) and it makes no sense to share the HMD
> with anything else at the same time.
>
> If we look at APIs, DRM KMS API is universal on Linux. DRM KMS is more
> universal on Linux than Wayland, X11, or others, or any toolkit API,
> because DRM KMS is *the* way to control displays at the lowest level
> userspace can have access. KMS is hardware agnostic, but it does expose
> hardware-specific features through a common API.



> That said, personally I do think there is a good place for a Wayland
> protocol extension designed for color
> measurement/characterisation/calibration applications (is there a
> shorter term I could use for all those apps?):

display profiling app *shrug*


>
> - It keeps the Wayland compositor in the loop, meaning that you are
>   sure to reset the hardware state correctly for measurement, instead
>   of the measurement application having to be updated to know how to
>   reset everything the compositor might have been using, e.g. setting
>   just one LUT vs. two LUTs and a matrix in the hardware.
>
> - It allows a measurement app to cooperate with other apps without
>   being stomped on or having to shut down everything else while it runs.
>
> - It could allow uploading a new color profile to the compositor, if
>   various compositor projects can agree on how to do that. Given that
>   ICC spec exists, I guess there are good chances of succeeding. OTOH,
>   desktop projects do tend to dislike any interfaces that attempt to
>   bypass their own settings apps.
>
> - It does offer some amount of API abstraction
>
> However, the extension will be specific to Wayland so you still have a
> whole new platform to support in your color tool(kit)s.
>

Call me crazy but I'd like to think GTK or Qt could provide, if they
so chose, this abstraction such that a display profiling app could run
on any platform with any compositor, and calibrate or profile. These
higher level APIs should detect the compositor being used, and tell
the compositor to do the right thing for the task at hand.

Windows and macOS have one display pipeline and compositor. There are
many on Linux. Even multiple wayland compositors. And they're
potentially used in combination on top of each other. I'm thinking of
Qubes OS where each application runs in a VM. What about flatpaks and
snap applications? The idea each net pipeline is different and would
need to be characterized, doesn't sound workable.


-- 
Chris Murphy