Thread (151 messages) 151 messages, 9 authors, 2022-08-30

Re: [PATCH v1 35/35] drm/modes: Introduce more named modes

From: Maxime Ripard <hidden>
Date: 2022-08-25 14:22:46
Also in: dri-devel, linux-amlogic, linux-sunxi, lkml

On Sun, Aug 21, 2022 at 06:16:15PM +0200, Noralf Trønnes wrote:

Den 29.07.2022 18.35, skrev Maxime Ripard:
quoted
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.

Signed-off-by: Maxime Ripard <redacted>
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3634ac9f787d..09ed5ce7746d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1853,7 +1853,9 @@ struct drm_named_mode {
 
 static const struct drm_named_mode drm_named_modes[] = {
 	{ "NTSC", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_M, },
+	{ "NTSC_J", &drm_mode_480i, DRM_MODE_TV_NORM_NTSC_J, },
 	{ "PAL", &drm_mode_576i, DRM_MODE_TV_NORM_PAL_B, },
+	{ "PAL_M", &drm_mode_480i, DRM_MODE_TV_NORM_PAL_M, },
Please use a dash instead of an underscore to keep it consistent with
what's used elsewhere.
Yeah, I tried not to use it since I didn't want to cripple the parser
with bad heuristics, but Geert has done a much better job than my
attempts here:
https://lore.kernel.org/dri-devel/2eb205da88c3cb19ddf04d167ece4e16a330948b.1657788997.git.geert@linux-m68k.org/ (local)

I've taken that patch in, renamed the modes and we already have unit
tests in other patches to cover that part of the parser.
I tried to use PAL and set the connector as connected, but that didn't
work: video=Composite-1:PALe

Is this a bug and it should work or should it be phrased differently?
I'm not sure. We never supported something like that so far, because the
expectation is that if it starts with a letter, it's a named mode. Thus
the named mode is PALe in your case, which doesn't match.

I'm not even sure what would be a good heuristic to support it, since
interpreting any e, E, or D as the last letter seems like a recipe for
disaster when some modes might legitimately end with e or d.
It would have been nice to get a warning in the log if the parser fails
to understand.

This very verbose version did work:
video=Composite-1:720x576@50ie,tv_mode=PAL-B
I think that's what we should be using in that case.

Maxime
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help