Hi Thomas,
On Mon, Jul 11, 2022 at 11:03:38AM +0200, Thomas Zimmermann wrote:
Am 08.07.22 um 20:21 schrieb Geert Uytterhoeven:
The mode parsing code recognizes named modes only if they are explicitly
listed in the internal whitelist, which is currently limited to "NTSC"
and "PAL".
Provide a mechanism for drivers to override this list to support custom
mode names.
Ideally, this list should just come from the driver's actual list of
modes, but connector->probed_modes is not yet populated at the time of
parsing.
I've looked for code that uses these names, couldn't find any. How is this
being used in practice? For example, if I say "PAL" on the command line, is
there DRM code that fills in the PAL mode parameters?
We have some code to deal with this in sun4i:
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_tv.c#L292
It's a bit off topic, but for TV standards, I'm still not sure what the
best course of action is. There's several interactions that make this a
bit troublesome:
* Some TV standards differ by their mode (ie, PAL vs NSTC), but some
other differ by parameters that are not part of drm_display_mode
(NTSC vs NSTC-J where the only difference is the black and blanking
signal levels for example).
* The mode names allow to provide a fairly convenient way to add that
extra information, but the userspace is free to create its own mode
and might omit the mode name entirely.
So in the code above, if the name has been preserved we match by name,
but we fall back to matching by mode if it hasn't been, which in this
case means that we have no way to differentiate between NTSC, NTSC-J,
PAL-M in this case.
We have some patches downstream for the RaspberryPi that has the TV
standard as a property. There's a few extra logic required for the
userspace (like setting the PAL property, with the NTSC mode) so I'm not
sure it's preferable.
Or we could do something like a property to try that standard, and
another that reports the one we actually chose.
And another question I have is whether this whitelist belongs into the
driver at all. Standard modes exist independent from drivers or hardware.
Shouldn't there simply be a global list of all possible mode names? Drivers
would filter out the unsupported modes anyway.
We should totally do something like that, yeah
Maxime
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature