Linux 6.3 To Bring Analog TV Support Improvements
With the Linux 6.2 merge window behind us, feature work for the Direct Rendering Manager (DRM) changes targeting now the Linux 6.3 kernel have begun queuing with DRM-Next.
Sent in today was an initial batch of drm-misc-next material from over the holidays. There isn't too much among the core and small DRM driver changes in this pull considering that many developers took time off during Christmas and New Year's.
Standing out though is the DRM code seeing some analog TV support improvements for 2023. Longtime open-source developer Maxime Ripard has worked on adding a "Analog-TV" mode property to the DRM connector user-space API and making other DRM core improvements around analog TV support.
From this big patch series that has been in-development for several months now, Maxime Ripard explains:
As noted initially benefiting from these analog TV support improvements is the VC4 DRM driver most notably used by the Raspberry Pi single board computers and then the Sun4i DRM driver for the various Allwinner SoCs using that display driver.
That analog TV work is the most interesting changes among today's drm-misc-next pull. Expect more interesting DRM driver changes to queue over the coming weeks ahead of the Linux 6.3 merge window coming up in the later part of February.
Sent in today was an initial batch of drm-misc-next material from over the holidays. There isn't too much among the core and small DRM driver changes in this pull considering that many developers took time off during Christmas and New Year's.
Standing out though is the DRM code seeing some analog TV support improvements for 2023. Longtime open-source developer Maxime Ripard has worked on adding a "Analog-TV" mode property to the DRM connector user-space API and making other DRM core improvements around analog TV support.
From this big patch series that has been in-development for several months now, Maxime Ripard explains:
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 norm 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;
As noted initially benefiting from these analog TV support improvements is the VC4 DRM driver most notably used by the Raspberry Pi single board computers and then the Sun4i DRM driver for the various Allwinner SoCs using that display driver.
That analog TV work is the most interesting changes among today's drm-misc-next pull. Expect more interesting DRM driver changes to queue over the coming weeks ahead of the Linux 6.3 merge window coming up in the later part of February.
10 Comments