dividuum wrote: ↑
Wed Aug 21, 2019 1:02 pm
Yep. That works. I'm still trying to wrap my head around how the EDID provided values, the possible DMT/CEA settings (from tvservice -m) and now the DRM modes relate. Guess it's time for more code reading.
DRM merges CEA and DMT modes into a single table, and also parses all the detailed timings present in the EDID.
CEA vs DMT has limited implications if overscan isn't supported (CEA may be overscanned by the device, DMT won't be), and beyond the RGB range issue (CEA squashes the range to 16-235, DMT uses 0-255).
The behaviour from a timing perspective is identical, and the kernel DRM API has a magic function called drm_default_rgb_quant_range to deal with the RGB range (it compares the mode against the standard CEA modes, and returns HDMI_QUANTIZATION_RANGE_LIMITED if it matches and isn't VGA).
None of this is relevant to userspace, therefore it can largely be ignored.
EDID parsing is done via drm_add_edid_modes
, having read it and added it to the connector properties (https://github.com/raspberrypi/linux/bl ... ms.c#L1322
). It walks through the various sections of the EDID adding any modes that are defined within. Once all modes are added, it iterates through the list, removes duplicates, and checks with the driver whether they are supportable (eg 3D modes, YUV420, interlaced, max pixel frequency). The final result is what is advertised to userspace.
dividuum wrote:My confusion mainly stemmed from what I observed Raspbian doing: I forced a 720p mode using hdmi_group/hdmi_mode in /boot/config.txt. The Pi booted with that and then, I guess while doing some frame buffer initialization, it switched back to FullHD. Then switching back with tvservice resulted in the DRM/tvservice mismatch that I now understand.
This is the learning curve I've been working through for the last 4 months or so.
hdmi_group/hdmi_mode only tell the firmware which mode to select for the initial boot. The firmware EDID parsing differs from the kernel one, so can end up with a slightly different list of modes (I'd love to replace the firmware parser, but the risk of regressions is far too great to really entertain it).
The firmware will add to the kernel command line something like "video=HDMI-A-1:[email protected]
" (or whatever the firmware has chosen as a mode) in an attempt to make the kernel choose the same mode.
That works fine if that mode is found and active within the EDID. If it isn't, then the kernel ADDS it as a supported mode, but using the VESA Generalized Timing Formula (GTF)
. Most displays actually want the Coordinated Video Timings (CVT)
, therefore we get a weird mode that may not even be acceptable to the Pi, let alone the display (GTF typically has a higher pixel clock vs CVT for the same resolution).
This is one of the headaches I'm trying to resolve at the moment, but it's all in common DRM code, therefore it's a case of needing to understand it, make sure it isn't changing with upcoming kernels or being discussed, and making changes in a maintainable manner. (The short term fix is likely to be a way of skipping the firmware adding to the command line at all in the hope that the EDID parsing comes up with something plausible).
Having done all of that, the further fun is that X decides to be independent of any resolution that the firmware may have passed up to the kernel command line, and it parses the DRM modes list and chooses what it wants (generally the highest res). So much of the above is a waste of time for the majority who boot into X
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.