linux-kernel - Re: [PATCH v2 19/41] drm/modes: Introduce the tv

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]

Message-ID: <20220905142842.c3rvtupggdmavq7z@houat>
Date:   Mon, 5 Sep 2022 16:28:42 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Mateusz Kwiatkowski <kfyatek@...il.com>
Cc:     Ben Skeggs <bskeggs@...hat.com>, David Airlie <airlied@...ux.ie>,
        Chen-Yu Tsai <wens@...e.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Lyude Paul <lyude@...hat.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Samuel Holland <samuel@...lland.org>,
        Karol Herbst <kherbst@...hat.com>,
        Noralf Trønnes <noralf@...nnes.org>,
        Emma Anholt <emma@...olt.net>, Daniel Vetter <daniel@...ll.ch>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Hans de Goede <hdegoede@...hat.com>,
        linux-arm-kernel@...ts.infradead.org,
        Phil Elwell <phil@...pberrypi.com>,
        intel-gfx@...ts.freedesktop.org,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        dri-devel@...ts.freedesktop.org, Dom Cobley <dom@...pberrypi.com>,
        linux-kernel@...r.kernel.org, nouveau@...ts.freedesktop.org,
        linux-sunxi@...ts.linux.dev,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v2 19/41] drm/modes: Introduce the tv_mode property as a
 command-line option

On Fri, Sep 02, 2022 at 12:46:29AM +0200, Mateusz Kwiatkowski wrote:
> > @@ -2212,20 +2239,22 @@ struct drm_named_mode {
> >      unsigned int xres;
> >      unsigned int yres;
> >      unsigned int flags;
> > +    unsigned int tv_mode;
> >  };
> 
> Are _all_ named modes supposed to be about analog TV?
>
> If so, then probably this structure should be renamed drm_named_analog_tv_mode
> or something.

I don't think they need to, but it's the only use case we've had so far.
We could also imagine using UHD for 3840x2160 for example, so I wouldn't
say it's limited to analog tv.

> If not, then including tv_mode in all of them sounds almost dangrous. 0 is a
> valid value for enum drm_connector_tv_mode, corresponding to
> DRM_MODE_TV_MODE_NTSC_443. This is a very weird default (maybe it shouldn't be
> the one that has a numeric value of 0?) and if there ever is a named mode that
> is not related to analog TV, it looks that it will refer to NTSC-443.
> 
> Not sure where could that actually propagate, and maybe what I'm saying can't
> happen, but I'm imagining weird scenarios where a GPU that has both a
> VGA/HDMI/whatever output, and a composite output, switches to NTSC-443 on the
> composite output by default because a named mode for the modern output is
> selected.

So, named modes are per-connector so the fact that there's another
output doesn't really matter. Then, the answer is quite simple actually,
the HDMI driver wouldn't register and use the TV mode property at all,
so it would completely ignore it, no matter what value it has.

So it's not really a concern.

> Maybe something like DRM_MODE_TV_MODE_NONE = 0 would make sense?

But I guess we can add it still.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)