On Sun, Jan 24, 2021 at 10:04:54PM +0100, Mario Kleiner wrote: > On Sun, Jan 24, 2021 at 9:24 PM Simon Ser <contact@xxxxxxxxxxx> wrote: > > > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner < > > mario.kleiner.de@xxxxxxxxx> wrote: > > > > > But it still needs to be fixed if we want working HDR. I thought > > > libdrm copies the definitions from the kernel periodically, so the > > > fix should propagate? > > > > There will always be user-space that sends 1 instead of 0. This > > shouldn't fail on more recent kernels or it will be a regression. > > > > Yes, i know, regressing user-space is bad, but in this very specific case a > "good" one, if ever. At the moment, it wouldn't regress userspace simply > because the kernel doesn't actually check for the correct value in its HDR > metadata handling. But the value itself is sent as HDMI HDR metadata to the > attached HDR display monitor, so if the monitors firmware checks, it will > classify the wrong value of 1 as invalid and disable HDR mode on the > display, which is certainly not what a HDR client application wants. And > future HDR standards which will actually allocate the value 1 to a > different mode of HDR operation will switch to the wrong mode / > misinterpret the sent HDR metadata with hillarious results, which is also > not in the interest of a HDR client application, or a HDR capable > compositor. > > Iow. if clients continue to use the wrong value 1 then HDR display will > break in various ways on correctly implemented HDR displays, but in a > mystifying and hard to debug way. The kernel rejecting a wrong setting > explicitly and forcing a bug fix in the client would be a blessing in this > case. > > I spent weeks last year, going in circles and hunting ghost bugs related to > HDR because much of the HDR stuff, both drivers and monitor firmware seems > to be in not a great shape. "Less wrong" would be a big step forward. > Especially with the cheaper HDR monitors it is difficult to see when things > go wrong, because we don't have good expectations on how proper HDR should > look and the lower end HDR displays don't help. This is not an uapi defintion anyway so fixing should be fine. I don't think we even check any of the client provided values, or do we? EOTF I think we do check, but IMO that check should probably just be nuked as well if we don't bother checking anything else. I was in fact going to suggest nuking this entire hdr_sink_metadata parsing as unused, but looks like amdgpu has started to use it for some backlight stuff of all things. -- Ville Syrjälä Intel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
