I got my case 2 weeks ago, and 99% of things went perfectly. This was the first time I’d rocked an RPi with an external hard-drive, so I mainly set about trying a bunch of different OS’s and seeing what the state of things were like, now.
One of my use cases for it was as a media centre, and a few different media apps, including Kodi.
Here, there two things that occurred. After I’d hacked a bog-standard bullseye RPiOS install to an alpha/beta buster version, I started hitting quite a few oddities where the system just wouldn’t use hardware acceleration, and anything I ran was at best in compatibility mode, with horrible performance, or just wouldn’t run at all. I put in some amount of time to resolve this, but given the situation, ended up just giving up, there’ll be an official release of it soon enough, and I can just wait - if anyone has insights into why that may have been occurring, I am however all ears.
The second bit is where I’d like to share a harsh bit of learning. I can’t remember exactly where, but I was advised to use the “first” HDMI slot of the Argon case, which was described as “the one closest to the power slot”. For 99% of my uses then, this all worked perfectly, but, for some situations? When I’d play particular videos (very HD mkv files, with VLC and Kodi), my HDMI would completely black out. But, this happened when I was running the correct driver, vc4-kms-v3d, but NOT when I was running the now deprecated vc4-fkms-v3d driver.
I checked many posts who’d suffered similar issues, but this No signal using vc4-kms-v3d dtoverlay on pi4 · Issue #5178 · raspberrypi/linux · GitHub seemed to be closest to my situation, so I attempted to follow the instructions there.
Long and the short of it, the instruction was to take the “auto choices” away from the Pi and instead manually tell it what display to use, etc. So, while using the deprecated vc4-fkms-v3d driver,
tvservice -d edid.dat
sudo cp edid.dat /lib/firmware
Add drm.edid_firmware=edid.dat video=HDMI-A-1:1920x1080@60D to cmdline.txt
Add the below to config.txt,
hdmi_edid_file=1
hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
And this… nearly worked, but didn’t.
Eventually what I learned was that the “first” HDMI port wasn’t being registered as the first port, it was being registered as the second one.
Problem here was running those commands between the two drivers. While running kmsprint and other tvservice commands using vc4-fkms-v3d, this was how it looked,
$ kmsprint
Connector 0 (89) HDMI-A-1 (connected)
Encoder 0 (88) TMDS
But, with vc4-kms-v3d, it looked like this,
$ kmsprint
Connector 0 (32) HDMI-A-1 (disconnected)
Encoder 0 (31) TMDS
Connector 1 (42) HDMI-A-2 (connected)
Encoder 1 (41) TMDS
So, when I made the above changes, given the weirdness, I was putting an edid of hdmi-2 in as hdmi-1 (which was disconnected), and also telling the Pi to “hotplug” hdmi-1, not hdmi-2.
When that was in, then it looked even weirder, and worse
$ kmsprint
Connector 0 (32) HDMI-A-1 (connected)
Encoder 0 (31) TMDS
Connector 1 (42) HDMI-A-2 (connected)
Encoder 1 (41) TMDS
In the end, what I realised from my mess was that some video apps were kinda doing the same thing. Sometimes, even though we were plugged into hdmi-2, it went and played, for some reason, on hdmi-1.
Eventually, what I learned, and what I’d like to share out to you guys is, if you’re using the “first” hdmi port, the one closest to the power plug, if that gets registered by your system as the second hdmi port, it can cause you weird display issues. I’ve tried to find a way to just completely disable, and hide the second hdmi port from the system, but I couldn’t figure a way how.
If you hit this issue, you can do what I did, which is now the ONLY change I have on my system from default, add hdmi_force_hotplug:1=1 to your config.txt.