linux-kernel - Re: [PATCH 4/5] drm/modes: Add support for driver-specific named modes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Jul 2022 13:03:57 +0200
From:   Thomas Zimmermann <tzimmermann@...e.de>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Hans de Goede <hdegoede@...hat.com>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Fbdev development list <linux-fbdev@...r.kernel.org>,
        Linux/m68k <linux-m68k@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/5] drm/modes: Add support for driver-specific named
 modes

Hi

Am 11.07.22 um 11:35 schrieb Geert Uytterhoeven:
> Hi Thomas,
> 
> On Mon, Jul 11, 2022 at 11:03 AM Thomas Zimmermann <tzimmermann@...e.de> 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?
> 
> I guess Maxime knows, as he added the whitelist?

Yeah, I saw his reply already.

> Reading the description of commit 3764137906a5acec ("drm/modes:
> Introduce a whitelist for the named modes"), it looks like this is
> more about preventing the parser from taking any string as a random
> mode, than about adding support for "PAL" or "NTSC"?
> 
> Note that drivers/gpu/drm/i915/display/intel_tv.c defines an array of
> tv_modes[], including "PAL", so perhaps these end up as named modes?
> 
>> 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.
> 
> For standard modes, I agree.  And these are usually specified by
> resolution and refresh rate (e.g. "640x480@60", instead of "480p").
> 
> But legacy hardware may have very limited support for programmable
> pixel clocks (e.g. Amiga is limited to pixel clocks of 7, 14, or 28
> MHz), so the standard modes are a bad match, or may not work at all.
> Hence drivers may need to provide their own modes, but it seems wrong
> to me to make these non-standard modes global, and possibly pollute
> the experience for everyone.
I don't really have a strong opinion, but having all modes in one global 
list is quite user-friendly. It's all there for everyone. Otherwise 
users would somehow have to know which hardware supports which modes. 
That's actually the job of each driver's mode_valid and atomic_check 
functions.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-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

-- 
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)