Message-ID: <43d75dce-988a-0a95-cb0a-0d0a7c81ca63@suse.de>
Date:   Mon, 11 Jul 2022 13:11:14 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Maxime Ripard <maxime@...no.tech>
Cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        dri-devel@...ts.freedesktop.org, linux-fbdev@...r.kernel.org,
        linux-m68k@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] drm/modes: Add support for driver-specific named
 modes

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

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists