Hi Maxime, On Mon, Jul 11, 2022 at 2:02 PM Maxime Ripard <max...@cerno.tech> wrote: > On Mon, Jul 11, 2022 at 01:59:28PM +0200, Geert Uytterhoeven wrote: > > On Mon, Jul 11, 2022 at 1:42 PM Maxime Ripard <max...@cerno.tech> 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?
You mean a PAL mode that does not use 768x576? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/amifb.c#n834 (TAG_HIRES is replaced by the actual dot clock at runtime, as it depends on the crystal present on the mainboard). Amifb also supports 320x256, by doubling the dot clock, but that mode is not part of the database. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
