On Fri, 8 Mar 2019 08:35:20 +1100
Graeme Gill 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.
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?):
- 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.
Thanks,
pq
pgpb2pXeD4zVX.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
