vc4/hdmi: Always enable GCP with AVMUTE cleared #5317
Conversation
|
I checked with an analyser what my dell xps laptop (intel graphics) does, and it always outputs a gpc with: which matches this PR's behaviour. |
|
As discussed on LibreELEC Slack the vc5/RPi4 change makes my HDFury Vrroom very unhappy - when kms takes over I get a flickering display (switching between black screen and signal at fast, irregular intervals). It seems to be some issue at RPi4 output/HDfury input, the OSD of the HDFury is shown fine (only the RPi4 input signal flickers). However after switching to another mode (eg with modetest) the display is fine - also after modetest switches back to the initial mode. vc4/RPi3B+ seem to work fine with this change, I haven't seen the flickering issue with it |
See: https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0 Issue is some displays go blank at the point of firmware to kms handover. Plugging/unplugging hdmi cable, power cycling display, or switching standby off/on typically resolve this case. Finally managed to find a display that suffers from this, and track down the issue. The firmware uses AVMUTE in normal operation. It will set AVMUTE before disabling hdmi clocks and phy. It will clear AVMUTE after clocks and phy are set up for a new hdmi mode. But with the hdmi handover from firmware to kms, AVMUTE will be set by firmware. kms driver typically has no GCP packet (except for deep colour modes). The spec isn't clear on whether to consider the AVMUTE as continuing indefinitely in the absense of a GCP packet, or to consider that state to have ended. Most displays behave as we want, but there are a number (from mutiple manufacturers) which need to see AVMUTE cleared before displaying a picture. Lets just always enable GCP packet with AVMUTE cleared. That resolves the issue on problematic displays. From HDMI 1.4 spec: A CD field of zero (Color Depth not indicated) shall be used whenever the Sink does not indicate support for Deep Color. This value may also be used in Deep Color mode to transmit a GCP indicating only non-Deep Color information (e.g. AVMUTE). So use CD=0 where we were previously not enabling a GCP. Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
force-pushed
the
clearavmute
branch
from
62c91cc
to
2861c2d
Compare
|
I've dropped the vc4 support as it's makes the PR more complicated and so far we haven't had a report of failure. There has been a positive report on LE forum: vc4 can be added later. |
|
Testing with my HD Fury Vrroom (hooked up to a 1920x1200p60 monitor) and my LG 55C8 4k OLED TV (which didn't suffer from any problems though) looks fine so far 👍 |
See: raspberrypi/linux#5327 kernel: vc4/hdmi: Always enable GCP with AVMUTE cleared See: raspberrypi/linux#5317 kernel: media: bcm2835-v4l2-codec: Enable selection ioctl for ISP See: raspberrypi/linux#5328 userland: tvservice: Update unsupported message to recommend kmsprint See: https://forums.raspberrypi.com/viewtopic.php?t=346202
See: raspberrypi/linux#5327 kernel: vc4/hdmi: Always enable GCP with AVMUTE cleared See: raspberrypi/linux#5317 kernel: media: bcm2835-v4l2-codec: Enable selection ioctl for ISP See: raspberrypi/linux#5328 userland: tvservice: Update unsupported message to recommend kmsprint See: https://forums.raspberrypi.com/viewtopic.php?t=346202
See: https://forum.libreelec.tv/thread/24780-le-10-0-1-rpi4-no-picture-after-update-from-le-10-0-0
Issue is some displays go blank at the point of firmware to kms handover.
Plugging/unplugging hdmi cable, power cycling display, or switching standby off/on
typically resolve this case.
Finally managed to find a display that suffers from this, and track down the issue.
The firmware uses AVMUTE in normal operation. It will set AVMUTE before disabling hdmi
clocks and phy. It will clear AVMUTE after clocks and phy are set up for a new hdmi mode.
But with the hdmi handover from firmware to kms, AVMUTE will be set by firmware.
kms driver typically has no GCP packet (except for deep colour modes).
The spec isn't clear on whether to consider the AVMUTE as continuing indefinitely
in the absense of a GCP packet, or to consider that state to have ended.
Most displays behave as we want, but there are a number (from mutiple manufacturers)
which need to see AVMUTE cleared before displaying a picture.
Lets just always enable GCP packet with AVMUTE cleared. That resolves the issue on
problematic displays.
From HDMI 1.4 spec:
A CD field of zero (Color Depth not indicated) shall be used whenever the Sink does
not indicate support for Deep Color. This value may also be used in Deep Color mode
to transmit a GCP indicating only non-Deep Color information (e.g. AVMUTE).
So use CD=0 where we were previously not enabling a GCP.
Signed-off-by: Dom Cobley popcornmix@gmail.com