It's not the cable or the cheapo OLED monitor I got recently, connected to District (my old Intel i7 3770k system with an AMD 5500 XT 8GB GDDR6 video card in it) blacks are real blacks both in the GUI and in the VTs. Same when connecting via USB-C to my Steam Deck or Pinebook Pro.
Description
Event Timeline
I tried kmscon, which instantly gave me colors in the normally colorless default shell sessions on ubuntu-server, but didn't solve this.
Maybe a la https://forum.up-community.org/discussion/703/on-hdmi-output-black-is-grey it's an incomplete colorspace problem? Related links: https://www.onetransistor.eu/2021/08/hdmi-picture-quantization-range-linux.html. Both links are for GUI sessions, though . . . and the GUI isn't loading on my Pi 3b anyways. Which is a separate problem! But that means that GUI solutions, or CLI color changes a la https://opensource.com/article/19/9/linux-terminal-colors, won't save me.
https://forums.raspberrypi.com/viewtopic.php?p=873637&sid=de67bcdd0f258544c54f0d83add391e8#p873637 may be the ticket:
According to http://elinux.org/RPiconfig hdmi_pixel_encoding could be the gremlin-in-the-stockyard.
hdmi_pixel_encoding Force the pixel encoding mode. By default it will use the mode requested from edid so shouldn't need changing.hdmi_pixel_encoding=0 default (limited for CEA, full for DMT)
hdmi_pixel_encoding=1 RGB limited (16-235)
hdmi_pixel_encoding=2 RGB full ( 0-255)
hdmi_pixel_encoding=3 YCbCr limited (16-235)
hdmi_pixel_encoding=4 YCbCr full ( 0-255)
HDMI EDID is finicky as fuck so maybe it's doing that wrong and ending up in one of the limited colourspaces?
Haha yup that was it! This solved things:
[all] hdmi_pixel_encoding=2
May as well collect some options for *setting* the colors:
- https://askubuntu.com/a/153493 and https://archive.ph/QSYHd set within bash
- Using setvtrgb: https://lists.altlinux.org/pipermail/kbd/2011-March/000287.html
- I gather tput can do this and also could be fun for scripting fancy CLI displays http://linuxcommand.org/lc3_adv_tput.php