I’m trying to prepare a Raspberry Pi 3 to be a Christmas present for my brother and I’d really like to not sour the occasion with yet another sign that he needs to buy a new TV without broken EDID. (His Nintendo Switch only offers 480p on it because of the broken EDID.)
The unit works perfectly well at 1080p on my monitor, but I can’t get the bad EDID workaround from https://wiki.batocera.org/display_issues to work in a useful fashion.
Specifically, it does get me the static boot splash at the correct resolution, but then, instead of the splash video, I get the TV’s “No Signal” message.
I started with just this…
hdmi_ignore_edid=0xa5000080
hdmi_group=1
hdmi_mode=16
…and then incrementally tried enabling more overrides, testing after each one, until I had this, added in the order I’ve sorted them here…
hdmi_ignore_edid=0xa5000080
hdmi_group=1
hdmi_mode=16
hdmi_force_mode=1
hdmi_force_hotplug=1
hdmi_drive=2
edid_content_type=0
disable_fw_kms_setup=1
…but still the same problem.
I also tried marching down that list again with hdmi_mode=5 (1080i@60Hz instead of 1080p@60Hz) and got the same result.
I tried switching to hdmi_safe=1 but that only got me a very pixellated boot splash before it shut down with the “Invalid Mode” error from the TV that I was getting before I started changing parameters.
batocera-resolution seems to indicate that it doesn’t consider it a valid output at all:
[root@BATOCERA /userdata/system]# batocera-resolution listOutputs
[root@BATOCERA /userdata/system]# batocera-resolution listModes
max-1920x1080:maximum 1920x1080
max-640x480:maximum 640x480
I know it can work because, aside from the boot splash displaying fine and the TV reporting the expected resolution and refresh rate, my notes say I was also using this successfully to feed that same TV from another device which used X.org for output:
# Current 1080p modeline
# Source: http://www.mythtv.org/wiki/Modeline_Database#ATSC_Standard_Modes
ModeLine "1920x1080_60.00" 148.5 1920 1960 2016 2200 1080 1082 1088 1125
Option "DPMS"
Linux itself does seem to be picking up the mode in some sense, but, since I have no experience with non-X11 video output, I’m not sure if it’s correct or not:
[root@BATOCERA /userdata/system]# for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done
HDMI-A-1: connected
Writeback-1: unknown
[root@BATOCERA /userdata/system]# cat /sys/class/graphics/fb0/modes
U:1920x1080p-0
[root@BATOCERA /userdata/system]# fbset
mode "1920x1080-0"
# D: 0.000 MHz, H: 0.000 kHz, V: 0.000 Hz
geometry 1920 1080 1920 1080 16
timings 0 0 0 0 0 0 0
accel true
rgba 5/11,6/5,5/0,0/0
endmode
I tried waking up the output with the following commands, adapted from analogues to what I’ve done in the past with xrandr, but no such luck:
[root@BATOCERA /userdata/system]# fbset -fb /dev/fb0 -g 1920 1080 1920 1080 16
[root@BATOCERA /userdata/system]# cat /sys/class/graphics/fb0/modes
U:1920x1080p-0
[root@BATOCERA /userdata/system]# echo 'U:1920x1080p-0' > /sys/class/graphics/fb0/mode
I finally managed to force the video to stay active by adding these kernel command-line parameters from this blog post to cmdline.txt:
drm_kms_helper.edid_firmware=edid/1920x1080.bin video=HDMI-A-1:1920x1080@60e
…but it silenced the audio output even though the GUI is still allowing and set to explicitly use the HDMI as the desired output and more searching indicates that loss of HDMI audio output is a common problem when using drm_kms_helper.edid_firmware.
Based on those links and resources they reference, it looks like the problem may be that, somewhere in the driver stack, the EDID override isn’t providing the ELD data needed to pack the audio data into the HDMI stream.
Again, I really don’t want to give my brother a reminder of what a pain that TV can be, so I don’t want to be forced to choose between hacking up something with the analog audio out, learning kernel hacking by diagnosing and writing a patch when I barely even have any experience with C, or doubling the cost of my gift for him by gambling that something like the DrHDMI will fix the issue in a way invisible to the Pi. (All of the inexpensive EDID Emulators I found cost at least as much as the DrHDMI once a shipping option that can get them here by Christmas is selected.)
Please tell me I’ve missed something simple but insufficiently documented.
