On Fri, 8 Mar 2019 08:35:20 +1100 Graeme Gill <grae...@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. 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