fkms/pi4 not responding to VC4_BROADCAST_RGB_LIMITED connector property

[alanbork]

fkms has a connector property for setting HDMI pixel encoding to RGB limited or RGB full:

https://github.com/raspberrypi/linux/blob/7fb9d006d3ff3baf2e205e0c85c4e4fd0a64fcd0/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1586

if you set that connector property using proptest

./proptest 89 connector 94 1 # full
./proptest 89 connector 94 2 # limited

it does nothing (contrast this with setting the margin, which takes effect immediately).

Based on this code:

https://github.com/raspberrypi/linux/blob/7fb9d006d3ff3baf2e205e0c85c4e4fd0a64fcd0/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L951

it seems like the only time this property is referenced in the code is when a new mode is set - fine, it need not be immediate, even if that would be nice. BUT, even the next time a new video mode is initialized using kms/drm the limited/full property doesn't seem to have any effect on the pixel encoding actually sent over the HDMI cable.

if you go allllll the way back to a pi0 with the dispmanx firmawre and choose a dmt or cea mode using tvserice it works right there.

It's at least implied by #1579 (comment) that this should work for fkms (just not for regular kms), but it seems like it does not. Reading the code I don't see why it would fail, but maybe it's a subtle bug. Or maybe the bug is in the closed source firmware?

I realize fkms is on the back burner, but it's really unfortunate that there's no way at all to get the pi4 to output in broadcast (CEA) RGB rather than DMT with at least one of the kms or fkms driver sets.

[6by9]

There's a missing atomic_check function that sets the mode_changed flag in the drm_crtc_state should the broadcast_rgb property change. The equivalent of intel_digital_connector_atomic_check.
That'll then trigger a mode change whenever the broadcast_rgb property is changed.

This is why we really want this dealt with as a standard property rather than being hacked into every driver. It's far too easy to miss tiny parts of the detail.

Looking on an HDMI analyser, the AVI infoframe is changing to reflect the quantization range. It's decoded as "default - depends on video format" for limited mode, and as "full". That appears to be coming off Q1 and Q0 in byte PB3 which is set to 0x0 for limited range and 0x2 for full range. It currently never sets 0x1 for explicit limited range.
It is incorrect to explicitly signal limited mode when in a CEA mode (exception being mode 1 VGA which is defined as being full range).

The colour conversion matrices will have been updated to use limited mode appropriately.

There may be a further case that isn't considered. VIC=0 is effectively the flag for CEA vs DMT in the AVI infoframe. If VIC=0, then CEA rules go out the window, and it's reasonable to always set the range explicitly.

[alanbork]

Thanks for looking into this. Is there a usemode property to toggle the VIC? If I understand you correctly the flaw in the fkms code is that the limited range property change doesn't trigger a mode change immediately, but it does work otherwise? On my end it appears that I never get a limited range, but maybe what is really happening is the VIC is always set to indicate DMT. I can't measure raw HDMI pixel values directly, only the display's final conclusion about the signal, which is that it's a DMT encoded mode no mater what resolutions I choose or changes to VC4_BROADCAST_RGB_LIMITED. If I can set the VIC value either from the console or from usermode c, I'd like to try that.

…

On Wed, May 19, 2021, 2:45 AM 6by9 ***@***.***> wrote: There's a missing atomic_check function that sets the mode_changed flag in the drm_crtc_state should the broadcast_rgb property change. The equivalent of intel_digital_connector_atomic_check <https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_atomic.c#L147> . That'll then trigger a mode change whenever the broadcast_rgb property is changed. This is why we really want this dealt with as a standard property rather than being hacked into every driver. It's far too easy to miss tiny parts of the detail. Looking on an HDMI analyser, the AVI infoframe is changing to reflect the quantization range. It's decoded as "default - depends on video format" for limited mode, and as "full". That appears to be coming off Q1 and Q0 in byte PB3 which is set to 0x0 for limited range and 0x2 for full range. It currently never sets 0x1 for explicit limited range. It is incorrect to explicitly signal limited mode when in a CEA mode (exception being mode 1 VGA which is defined as being full range). The colour conversion matrices will have been updated to use limited mode appropriately. There may be a further case that isn't considered. VIC=0 is effectively the flag for CEA vs DMT in the AVI infoframe. If VIC=0, then CEA rules go out the window, and it's reasonable to always set the range explicitly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1580 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPGZ5LMSMOX6PNLN7FQO33TOOCDXANCNFSM445RQTZA> .

[alanbork]

All I can find about the VIC values is this rather old scanned document: https://archive.org/details/CEA-861-B/page/n71/mode/2up but that suggests it should be the entire CEA mode number. Is that what FKMS sends? I can imagine that the pi0 with dispmanx is sending the actual CEA code since that's how tvservice itself is initialized, but it seems like a significant bother to work backwards from the timing codes to the CEA mode number and perhaps fkms skips that? Or is that stored somewhere in the drm structure for the supported modes? This presentation on 4k ( https://events.static.linuxfound.org/sites/events/files/slides/elce2017.pdf) suggests that in practice the VIC values are somewhat haphazardly implemented... But perhaps samsung in particular has more stringent expectations for what is in that field, and that's why I'm getting strange behavior.

…

On Wed, May 19, 2021 at 7:28 AM AR ***@***.***> wrote: Thanks for looking into this. Is there a usemode property to toggle the VIC? If I understand you correctly the flaw in the fkms code is that the limited range property change doesn't trigger a mode change immediately, but it does work otherwise? On my end it appears that I never get a limited range, but maybe what is really happening is the VIC is always set to indicate DMT. I can't measure raw HDMI pixel values directly, only the display's final conclusion about the signal, which is that it's a DMT encoded mode no mater what resolutions I choose or changes to VC4_BROADCAST_RGB_LIMITED. If I can set the VIC value either from the console or from usermode c, I'd like to try that. On Wed, May 19, 2021, 2:45 AM 6by9 ***@***.***> wrote: > There's a missing atomic_check function that sets the mode_changed flag > in the drm_crtc_state should the broadcast_rgb property change. The > equivalent of intel_digital_connector_atomic_check > <https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/i915/display/intel_atomic.c#L147> > . > That'll then trigger a mode change whenever the broadcast_rgb property is > changed. > > This is why we really want this dealt with as a standard property rather > than being hacked into every driver. It's far too easy to miss tiny parts > of the detail. > > Looking on an HDMI analyser, the AVI infoframe is changing to reflect the > quantization range. It's decoded as "default - depends on video format" for > limited mode, and as "full". That appears to be coming off Q1 and Q0 in > byte PB3 which is set to 0x0 for limited range and 0x2 for full range. It > currently never sets 0x1 for explicit limited range. > It is incorrect to explicitly signal limited mode when in a CEA mode > (exception being mode 1 VGA which is defined as being full range). > > The colour conversion matrices will have been updated to use limited mode > appropriately. > > There may be a further case that isn't considered. VIC=0 is effectively > the flag for CEA vs DMT in the AVI infoframe. If VIC=0, then CEA rules go > out the window, and it's reasonable to always set the range explicitly. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#1580 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANPGZ5LMSMOX6PNLN7FQO33TOOCDXANCNFSM445RQTZA> > . >

[alanbork]

I can confirm that this is working properly. Sorry for the long delay, I didn't have access to hardware to test it properly again until now. Any chance of getting access to the VIC field so that it can also be set properly?

[alanbork]

Also, @mripard, what's the likelihood of this feature making it into the KMS driver anytime soon?