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

[Bill Hofmann]

Interesting. Thanks. Yeah, agree that it might not make general sense.
Will take a swing at it.

On Sat, Apr 23, 2022 at 11:47 AM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

> 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
> > >
> >
> >
>
>

-- 
Bill Hofmann
+1 510 387-0952
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220423/0c24278f/attachment-0001.htm>