[Intel-gfx] [PATCH v6 14/23] drm/modes: Properly generate a drm_display_mode from a named mode

[Maxime Ripard]

On Sat, Nov 05, 2022 at 06:50:30PM +0100, Noralf Trønnes wrote:
> Den 26.10.2022 17.33, skrev maxime at cerno.tech:
> > The framework will get the drm_display_mode from the drm_cmdline_mode it
> > got by parsing the video command line argument by calling
> > drm_connector_pick_cmdline_mode().
> > 
> > The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
> > function.
> > 
> > In the case of the named modes though, there's no real code to make that
> > translation and we rely on the drivers to guess which actual display mode
> > we meant.
> > 
> > Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
> > drm_display_mode we mean when passing a named mode.
> > 
> > Signed-off-by: Maxime Ripard <maxime at cerno.tech>
> > 
> > ---
> > Changes in v6:
> > - Fix get_modes to return 0 instead of an error code
> > - Rename the tests to follow the DRM test naming convention
> > 
> > Changes in v5:
> > - Switched to KUNIT_ASSERT_NOT_NULL
> > ---
> >  drivers/gpu/drm/drm_modes.c                     | 34 ++++++++++-
> >  drivers/gpu/drm/tests/drm_client_modeset_test.c | 77 ++++++++++++++++++++++++-
> >  2 files changed, 109 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index dc037f7ceb37..85aa9898c229 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -2497,6 +2497,36 @@ bool drm_mode_parse_command_line_for_connector(const char *mode_option,
> >  }
> >  EXPORT_SYMBOL(drm_mode_parse_command_line_for_connector);
> >  
> > +static struct drm_display_mode *drm_named_mode(struct drm_device *dev,
> > +					       struct drm_cmdline_mode *cmd)
> > +{
> > +	struct drm_display_mode *mode;
> > +	unsigned int i;
> > +
> > +	for (i = 0; i < ARRAY_SIZE(drm_named_modes); i++) {
> > +		const struct drm_named_mode *named_mode = &drm_named_modes[i];
> > +
> > +		if (strcmp(cmd->name, named_mode->name))
> > +			continue;
> > +
> > +		if (!named_mode->tv_mode)
> > +			continue;
> > +
> > +		mode = drm_analog_tv_mode(dev,
> > +					  named_mode->tv_mode,
> > +					  named_mode->pixel_clock_khz * 1000,
> > +					  named_mode->xres,
> > +					  named_mode->yres,
> > +					  named_mode->flags & DRM_MODE_FLAG_INTERLACE);
> > +		if (!mode)
> > +			return NULL;
> > +
> > +		return mode;
> > +	}
> > +
> > +	return NULL;
> > +}
> > +
> >  /**
> >   * drm_mode_create_from_cmdline_mode - convert a command line modeline into a DRM display mode
> >   * @dev: DRM device to create the new mode for
> > @@ -2514,7 +2544,9 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev,
> >  	if (cmd->xres == 0 || cmd->yres == 0)
> >  		return NULL;
> >  
> > -	if (cmd->cvt)
> > +	if (strlen(cmd->name))
> > +		mode = drm_named_mode(dev, cmd);
> 
> I'm trying to track how this generated mode fits into to it all and
> AFAICS if the connector already supports a mode with the same xres/yres
> as the named mode, the named mode will never be created because of the
> check at the beginning of drm_helper_probe_add_cmdline_mode(). It will
> just mark the existing mode with USERDEF and return.

Yep, you're right

> If the connector doesn't already support a mode with such a resolution
> it will be created, but should we do that? If the driver supported such
> a mode it would certainly already have added it to the mode list,
> wouldn't it? After all it's just 2 variants NTSC and PAL.

I wasn't so sure about this part. I think it's still benefitial because
some users (Geert at least has expressed that need) might want a smaller
mode than 480i/576i, whereas the driver is realistically only going to
register those two.

So creating that mode if it isn't declared seems to have value to some.

> We have this in drm_client_modeset.c:drm_connector_pick_cmdline_mode():
> 
> 	list_for_each_entry(mode, &connector->modes, head) {
> 		/* Check (optional) mode name first */
> 		if (!strcmp(mode->name, cmdline_mode->name))
> 			return mode;
> 
> Here it looks like the named mode thing is a way to choose a mode, not
> to add one.
> 
> I couldn't find any documentation on how named modes is supposed to
> work, have you seen any?

Eh, I guess I'm to blame for that :)

Named modes are really only about the command-line name. The way it was
initially introduced was pretty much to only pass down the name to
drivers for them to figure it out, like we've been doing in sun4i:

https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_tv.c#L292

It wasn't really working, especially because the userspace pretty much
ignores it. One of the point of this series is to create a proper mode
(and state, really) from the name passed on the command line so that
drivers don't have to behave any different from usual, and userspace can
be involved there too.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20221107/ca38a2fe/attachment.sig>