Messages in this thread | | | Date | Mon, 11 Jul 2022 13:11:14 +0200 | Subject | Re: [PATCH 4/5] drm/modes: Add support for driver-specific named modes | From | Thomas Zimmermann <> |
| |
Hi Maxime
Am 11.07.22 um 11:35 schrieb Maxime Ripard: > 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
That sun code already looks like sometihng the DRM core/helpers should be doing. And if we want to support named modes well, there's a long list of modes in Wikipedia.
https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:Vector_Video_Standards2.svg
Best regards Thomas
> > Maxime
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev [unhandled content-type:application/pgp-signature] | |