On Mon, Jan 25, 2021 at 5:05 PM Simon Ser <contact@xxxxxxxxxxx> wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner <mario.kleiner.de@xxxxxxxxx> wrote:
> On Mon, Jan 25, 2021 at 1:14 PM Simon Ser <contact@xxxxxxxxxxx> wrote:
>
> > > This is not an uapi defintion anyway so fixing should be fine.
> >
> > Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah
> >
> > should be completely fine to fix it.
>
> Good! The beginning of the end of a sad story ;). So i guess i can
> get your r-b's for it?
Sorry, I haven't verified that this wouldn't break the world, so I'm
not comfortable giving a R-b.
Breaking the world is pretty unlikely for an unused #define, but I understand.
I guess Ville will have access to the relevant spec to verify: It is the CTA-861-G spec, table 44 in section 6.9 and also specifically section 6.9.1.
> Will this fix propagate into igt and libdrm? Or are separate fixup patches needed?
No, since this is not part of UAPI.
Ok. I'll submit patches once this one landed in the kernel.
> Simon, could you let the Kodi devs know in case you have a line to
> them? I didn't know that there is even one more real-world HDR client
> for Linux, apart from AMD's amdvlk Vulkan driver, which does things
> right and doesn't need fixing.
Seems like Kodi hardcodes the bad version:
https://github.com/xbmc/xbmc/blob/aa5c2e79c069ba7d0ab1d8ad930e4294bf554680/xbmc/cores/VideoPlayer/Buffers/VideoBufferDRMPRIME.h#L24
Thanks. I've filed an issue to them under:
Maybe we should add the good version in UAPI header?
I'm scared that future HDR definitions would be as carefully done and reviewed as this one, given how much harder it would be to fix them :/
But maybe that's just exhausted me who spent too many weeks dealing with HDR bugs everywhere.
-mario
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
