On Mon, Jul 11, 2022 at 01:59:28PM +0200, Geert Uytterhoeven wrote: > Hi Maxime, > > On Mon, Jul 11, 2022 at 1:42 PM Maxime Ripard <maxime@xxxxxxxxxx> wrote: > > On Mon, Jul 11, 2022 at 01:11:14PM +0200, Thomas Zimmermann wrote: > > > Am 11.07.22 um 11:35 schrieb Maxime Ripard: > > > > 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 > > > > Yeah, and NTSC is missing :) > > And that diagram is about the "digital" variant of PAL. > If you go the analog route, the only fixed parts are vfreq/hfreq, > number of lines, and synchronization. Other parameters like overscan > can vary. The actual dot clock can vary wildly: while there is an > upper limit due to bandwidth limitations, you can come up with an > almost infinite number of video modes that can be called PAL, which > is one of the reasons why I don't want hardware-specific variants to > end up in a global video mode database. Do you have an example of what that would look like? Maxime
Attachment:
signature.asc
Description: PGP signature
