[fritsch]

I started talking with the Intel folks:

09:57 < fritsch> vsyrjala: ping - you got another minute?
09:58 < fritsch> vsyrjala: https://bugs.freedesktop.org/show_bug.cgi?id=71769
09:58 < j4ni> fritsch: vsyrjala hasn't showed up at the office yet
09:58 < fritsch> j4ni: no hurry - it's for the backlog
09:58 < j4ni> yup
09:58 < fritsch> j4ni: you are also familiar with Limited vs Full Range?
09:59 < j4ni> fritsch: a little, but I'll happily defer that to vsyrjala
09:59 < fritsch> j4ni: vsyrjala use case: Kodi: Decode h264 to NV12 -> Limited RGB -> output on a Limited
Range TV with intel driver set to limited range
09:59 < fritsch> j4ni: vsyrjala problem: intel driver scales the colors again :-( so you end up with 24 ->
215
09:59 < fritsch> j4ni: vsyrjala workaround: Set intel to FULL range via xrandr and hope the TV does not read
the info frame and force it to Full Range
10:00 < fritsch> j4ni: vsyrjala Idea: "Limited 16:235" "Full" and "Passthrough" -> just let everything we
send go out as is, e.g. don't clamp / scale RGB ranges
10:00 < j4ni> oh I thought this was related to https://bugzilla.kernel.org/show_bug.cgi?id=105261
10:00 < fritsch> nope
10:00 < fritsch> no crash - just a question for best practice
10:01 < fritsch> how can we present Limited Range Video Data on a Limited Range screen without that this:
10:01 < fritsch> https://github.com/torvalds/linux/blob/m...ay.c#L8600
10:01 < danvet> airlied, ok I think I got them all
10:01 < fritsch> happens

So let's see.

Yeah - they exactly see the issue :-)

10:03 < daniels> fritsch: right, the problem is that intel narrows again, right? as there's no way to tell
it that the input data source is already clamped
10:04 < fritsch> daniels: exactly .-)
10:04 < daniels> fritsch: tbh i'd probably just put a modifier on the drm format
10:04 < fritsch> therefore I suggested this "passthrough" mode - cause new TVs actually read the info frame
10:04 < daniels> aye
10:05 < fritsch> and that means: for a "info frame" aware TV the only way to get out "a good gray ramp" is
to scale to 0..255 with dithering
10:05 < fritsch> from the kernel code - the passsthrough mode is "just" 20 lines, mainly if (! ...)
10:05 < fritsch> but "just" changes will degrade architecture :-)
10:05 < daniels> yeah, i know exactly the problem
10:05 < daniels> but it looks like slightly the wrong place to solve it
10:06 < fritsch> not sure - drm means: every video player needs to be adjusted
10:06 < daniels> really what you care about is the combination of the output mode (whether it claims limited
range), and the input _buffer_
10:06 < fritsch> but I admit: kernel would be a workaround
10:06 < daniels> every video player that uses drm directly, sure
10:06 < daniels> the ones that don't can rely on their wayland compositor or x11 driver to dtrt
10:06 < fritsch> kodi for example uses OpenGL for presentation
10:06 < daniels> gutted