Re: [Intel-gfx] [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 > 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 signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v10 00/19] drm: Analog TV Improvements
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 Cheers, Daniel > > To: David Airlie > To: Daniel Vetter > To: Maarten Lankhorst > To: Maxime Ripard > To: Thomas Zimmermann > To: Emma Anholt > To: Jani Nikula > To: Joonas Lahtinen > To: Rodrigo Vivi > To: Tvrtko Ursulin > To: Ben Skeggs > To: Karol Herbst > To: Lyude Paul > To: Chen-Yu Tsai > To: Jernej Skrabec > To: Samuel Holland > Cc: Geert Uytterhoeven > Cc: Mateusz Kwiatkowski > Cc: "Noralf Trønnes" > Cc: Dave Stevenson > Cc: Dom Cobley > Cc: Phil Elwell > Cc: > Cc: linux-ker...@vger.kernel.org > Cc: intel-gfx@lists.freedesktop.org > Cc: nouv...@lists.freedesktop.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-su...@lists.linux.dev > Cc: Hans de Goede > Signed-off-by: Maxime Ripard > > --- > Changes in v10: > - Rebase on top of drm-misc-next-2022-11-17 > - Fix checkpatch issues > - Add missing MODULE_* macros > - Link to v9: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-0-24b168e5b...@cerno.tech > > Changes in v9: > - Rename some tests, switch to kunit_test_suite and parameterized tests where > relevant > - Document the valid named modes > - Link to v8: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v8-0-09ce14669...@cerno.tech > > Changes in v8: > - Changed slightly the helper API to pass in the features > - Removed unused tv_mode_support function > - Removed mode name match in _pick_cmdline_mode > - Added unit tests to the get_modes helper > - Collected Noralf and Mateusz tags > - Rebased on drm-misc-next-2022-11-10 > - Link to v7: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v7-0-7072a478c...@cerno.tech > > Changes in v7: > - Switch to another implementation of get_modes from Noralf > - Made more checks in VEC's atomic_check > - Fixed typo in a commit log > - Checked for tv_mode_specified in drm_mode_parse_command_line_for_connector > - Rebased on drm-misc-next-2022-11-03 > - Link to v6: > https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech > > Changes in v6: > - Add and convert to a new get_modes helper to create the PAL and NTSC modes > in > the proper order, with the right preferred mode flag, depending on the > driver >
[Intel-gfx] [PATCH v10 00/19] drm: Analog TV Improvements
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 To: David Airlie To: Daniel Vetter To: Maarten Lankhorst To: Maxime Ripard To: Thomas Zimmermann To: Emma Anholt To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin To: Ben Skeggs To: Karol Herbst To: Lyude Paul To: Chen-Yu Tsai To: Jernej Skrabec To: Samuel Holland Cc: Geert Uytterhoeven Cc: Mateusz Kwiatkowski Cc: "Noralf Trønnes" Cc: Dave Stevenson Cc: Dom Cobley Cc: Phil Elwell Cc: Cc: linux-ker...@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-su...@lists.linux.dev Cc: Hans de Goede Signed-off-by: Maxime Ripard --- Changes in v10: - Rebase on top of drm-misc-next-2022-11-17 - Fix checkpatch issues - Add missing MODULE_* macros - Link to v9: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-0-24b168e5b...@cerno.tech Changes in v9: - Rename some tests, switch to kunit_test_suite and parameterized tests where relevant - Document the valid named modes - Link to v8: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v8-0-09ce14669...@cerno.tech Changes in v8: - Changed slightly the helper API to pass in the features - Removed unused tv_mode_support function - Removed mode name match in _pick_cmdline_mode - Added unit tests to the get_modes helper - Collected Noralf and Mateusz tags - Rebased on drm-misc-next-2022-11-10 - Link to v7: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v7-0-7072a478c...@cerno.tech Changes in v7: - Switch to another implementation of get_modes from Noralf - Made more checks in VEC's atomic_check - Fixed typo in a commit log - Checked for tv_mode_specified in drm_mode_parse_command_line_for_connector - Rebased on drm-misc-next-2022-11-03 - Link to v6: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech Changes in v6: - Add and convert to a new get_modes helper to create the PAL and NTSC modes in the proper order, with the right preferred mode flag, depending on the driver capabilities and defaults. - Support PAL60 - Renamed tests to be consistent with DRM tests naming convention - Simplified a bit the named mode parsing code - Add a tv_mode_specified field - Return 0 in get_modes implementations instead of error codes - Link to v5: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v5-0-d841cc64f...@cerno.tech Changes in v5: - Dropped TV Standard documentation removal - Switched the TV Mode documentation from CSV to actual documentation - Switched to kunit assertions where possible - Switched to KUNIT_ASSERT_NOT_NULL instead of KUNIT_ASSERT_PTR_NE(..., NULL) - Shuffled a bit the introduction of drm_client_modeset_connector_get_modes between patches - Renamed tv_mode_names to
