KMS to multiple displays, was Re: Building a graph for HDR10 output - stumped at sink

[Nicolas Dufresne]

Le samedi 23 avril 2022 à 10:20 -0700, Bill Hofmann a écrit :
> Nicolas:
> 
> Thanks for the details. I understand the enormity of the challenge for a
> general desktop environment when you have to mix SDR and PQ-HDR (having worked
> on HDR support on the Windows desktop and in the Xbox while at Dolby). It's a
> nasty problem.  My goal is to *JUST* display HDR10 full screen via HDMI to an
> HDR-capable TV, never displaying anything else, no tonemapping, etc.  The
> additional (OPTIONAL, so prepared to punt) challenge is to drive multiple
> displays with different HDR10 content. (The alternative being having multiple
> SBCs/NUCs, 1 per screen, and figure out sync one of several ways)
> 
> So, it looks like while the "correct" solution is to wait on Wayland
> compositor, the two plausible approaches to a solution short term seem to be:
> 
> 1. Punt on 1..n computer..HDR display, just bump up the system cost a bit with
> 1..1 computer..display
> 2. Build something by hand (not using gstreamer) where the part that uses
> KMS/DRM handles all n streams and displays
> 
> If that seems correct, then alas I think I know what my choice will be. :(

You can also add a device-fd property to kmssink, open /dev/dri/cardX in your
app and set that property. if all kmssink are using the same fd the permission
error will go away. Though it is then up to the caller to make sure each kmssink
element don't walk over each other. I'm not certain if such a feature would have
its place upstream, but its one way.

Nicolas

> 
> -Bill
> 
> On Sat, Apr 23, 2022 at 5:49 AM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
> > Le samedi 23 avril 2022 à 16:24 +0530, Nirbheek Chauhan a écrit :
> > > On Sat, Apr 23, 2022 at 3:30 AM Nicolas Dufresne via gstreamer-devel
> > > <gstreamer-devel at lists.freedesktop.org> wrote:
> > > > Though, to get out of the toy land, kmssink would need perhap to be
> > > > ported to
> > > > use atomic API, which notably allow trying calls without affecting other
> > > > surfaces. That would build up to the need for a shared display manager
> > > > (also
> > > > known as a compositor), specially to coordinate mode setting. Which
> > > > mostly boils
> > > > down to, why not use a proper compositor ?
> > > > 
> > > 
> > > Presumably the HDR10 requirement precludes the use of a compositor? Or
> > > do we now have a Linux compositor that correctly implements HDR
> > > features?
> > 
> > "correctly" is a vast requirement. Wayland protocol for HDR10 (and up) is
> > still
> > under development. Here's some lecture:
> > 
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
> > https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/124
> > https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/
> > 
> > > 
> > > Cheers,
> > > Nirbheek
> > 
> 
>