linux-kernel - Re: [PATCH v10 00/19] drm: Analog TV Improvements

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] [day] [month] [year] [list]

Message-ID: <20221124114945.oqilsc7zjth4jwso@houat>
Date:   Thu, 24 Nov 2022 12:49:45 +0100
From:   Maxime Ripard <maxime@...no.tech>
To:     Samuel Holland <samuel@...lland.org>,
        Jernej Skrabec <jernej.skrabec@...il.com>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Ben Skeggs <bskeggs@...hat.com>, Chen-Yu Tsai <wens@...e.org>,
        David Airlie <airlied@...ux.ie>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
        Emma Anholt <emma@...olt.net>,
        Karol Herbst <kherbst@...hat.com>,
        Lyude Paul <lyude@...hat.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        Hans de Goede <hdegoede@...hat.com>,
        nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
        Noralf Trønnes <noralf@...nnes.org>,
        dri-devel@...ts.freedesktop.org,
        Mateusz Kwiatkowski <kfyatek+publicgit@...il.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-sunxi@...ts.linux.dev, Dom Cobley <dom@...pberrypi.com>,
        Phil Elwell <phil@...pberrypi.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH v10 00/19] drm: Analog TV Improvements

On Mon, Nov 21, 2022 at 03:51:26PM +0100, Daniel Vetter wrote:
> On Thu, Nov 17, 2022 at 10:28:43AM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > Here's a series aiming at improving the command line named modes support,
> > and more importantly how we deal with all the analog TV variants.
> > 
> > The named modes support were initially introduced to allow to specify the
> > analog TV mode to be used.
> > 
> > However, this was causing multiple issues:
> > 
> >   * The mode name parsed on the command line was passed directly to the
> >     driver, which had to figure out which mode it was suppose to match;
> > 
> >   * Figuring that out wasn't really easy, since the video= argument or what
> >     the userspace might not even have a name in the first place, but
> >     instead could have passed a mode with the same timings;
> > 
> >   * The fallback to matching on the timings was mostly working as long as
> >     we were supporting one 525 lines (most likely NSTC) and one 625 lines
> >     (PAL), but couldn't differentiate between two modes with the same
> >     timings (NTSC vs PAL-M vs NSTC-J for example);
> > 
> >   * There was also some overlap with the tv mode property registered by
> >     drm_mode_create_tv_properties(), but named modes weren't interacting
> >     with that property at all.
> > 
> >   * Even though that property was generic, its possible values were
> >     specific to each drivers, which made some generic support difficult.
> > 
> > Thus, I chose to tackle in multiple steps:
> > 
> >   * A new TV mode property was introduced, with generic values, each driver
> >     reporting through a bitmask what standard it supports to the userspace;
> > 
> >   * This option was added to the command line parsing code to be able to
> >     specify it on the kernel command line, and new atomic_check and reset
> >     helpers were created to integrate properly into atomic KMS;
> > 
> >   * The named mode parsing code is now creating a proper display mode for
> >     the given named mode, and the TV standard will thus be part of the
> >     connector state;
> > 
> >   * Two drivers were converted and tested for now (vc4 and sun4i), with
> >     some backward compatibility code to translate the old TV mode to the
> >     new TV mode;
> > 
> > Unit tests were created along the way.
> > 
> > One can switch from NTSC to PAL now using (on vc4)
> > 
> > modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> > modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
> > 
> > Let me know what you think,
> > Maxime
> 
> Maxime asked me to drop an Ack-in-principle on this, and I'm not sure I
> have any useful input here with my utter lack of understanding for TV
> things (I never even had one in my entire life, that's how much I don't
> care). But it seems to check all the design boxes around solving annoying
> uapi/kms-config issues properly, so
> 
> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@...ll.ch>

Thanks!

I jumped the gun a bit too fast and forgot to amend the TV property
commit message before pushing it out.

For the record though, that property is usable through xrandr, xorg.conf
or any equivalent compositor mechanism

Maxime

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