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

[Maxime Ripard]

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@xxxxxxxx>

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

Attachment: signature.asc
Description: PGP signature