Re: [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property

[maxime@cerno.tech]

[-- Attachment #1: Type: text/plain, Size: 6201 bytes --]

Hi,

On Tue, Oct 18, 2022 at 11:28:35PM +0200, Mateusz Kwiatkowski wrote:
> W dniu 18.10.2022 o 12:00, Maxime Ripard pisze:
> > On Mon, Oct 17, 2022 at 12:31:31PM +0200, Noralf Trønnes wrote:
> >> Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> >>>>  static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> >>>>  {
> >>>> -	struct drm_connector_state *state = connector->state;
> >>>>  	struct drm_display_mode *mode;
> >>>>  
> >>>> -	mode = drm_mode_duplicate(connector->dev,
> >>>> -				  vc4_vec_tv_modes[state->tv.legacy_mode].mode);
> >>>> +	mode = drm_mode_analog_ntsc_480i(connector->dev);
> >>>>  	if (!mode) {
> >>>>  		DRM_ERROR("Failed to create a new display mode\n");
> >>>>  		return -ENOMEM;
> >>>>  	}
> >>>>  
> >>>> +	mode->type |= DRM_MODE_TYPE_PREFERRED;
> >>>>  	drm_mode_probed_add(connector, mode);
> >>>>  
> >>>> -	return 1;
> >>>> +	mode = drm_mode_analog_pal_576i(connector->dev);
> >>>> +	if (!mode) {
> >>>> +		DRM_ERROR("Failed to create a new display mode\n");
> >>>> +		return -ENOMEM;
> >>>> +	}
> >>>> +
> >>>> +	drm_mode_probed_add(connector, mode);
> >>>> +
> >>>> +	return 2;
> >>>> +}
> >>>
> >>> Referencing those previous discussions:
> >>> - https://lore.kernel.org/dri-devel/0255f7c6-0484-6456-350d-cf24f3fee5d6@tronnes.org/
> >>> - https://lore.kernel.org/dri-devel/c8f8015a-75da-afa8-ca7f-b2b134cacd16@gmail.com/
> >>>
> >>> Unconditionally setting the 480i mode as DRM_MODE_TYPE_PREFERRED causes Xorg
> >>> (at least on current Raspberry Pi OS) to display garbage when
> >>> video=Composite1:PAL is specified on the command line, so I'm afraid this won't
> >>> do.
> >>>
> >>> As I see it, there are three viable solutions for this issue:
> >>>
> >>> a) Somehow query the video= command line option from this function, and set
> >>>    DRM_MODE_TYPE_PREFERRED appropriately. This would break the abstraction
> >>>    provided by global DRM code, but should work fine.
> >>>
> >>> b) Modify drm_helper_probe_add_cmdline_mode() so that it sets
> >>>    DRM_MODE_TYPE_PREFERRED in addition to DRM_MODE_TYPE_USERDEF. This seems
> >>>    pretty robust, but affects the entire DRM subsystem, which may break
> >>>    userspace in different ways.
> >>>
> >>>    - Maybe this could be mitigated by adding some additional conditions, e.g.
> >>>      setting the PREFERRED flag only if no modes are already flagged as such
> >>>      and/or only if the cmdline mode is a named one (~= analog TV mode)
> >>>
> >>> c) Forcing userspace (Xorg / Raspberry Pi OS) to get fixed and honor the USERDEF
> >>>    flag.
> >>>
> >>> Either way, hardcoding 480i as PREFERRED does not seem right.
> >>>
> >>
> >> My solution for this is to look at tv.mode to know which mode to mark as
> >> preferred. Maxime didn't like this since it changes things behind
> >> userspace's back. I don't see how that can cause any problems for userspace.
> >>
> >> If userspace uses atomic and sets tv_mode, it has to know which mode to
> >> use before hand, so it doesn't look at the preferreded flag.
> >>
> >> If it uses legacy and sets tv_mode, it can end up with a stale preferred
> >> flag, but no worse than not having the flag or that ntsc is always
> >> preferred.
> >>
> >> If it doesn't change tv_mode, there's no problem, the preferred flag
> >> doesn't change.
> >
> > I don't like it because I just see no way to make this reliable. When we
> > set tv_mode, we're not only going to change the preferred flag, but also
> > the order of the modes to make the preferred mode first.
> >
> > Since we just changed the mode lists, we also want to send a hotplug
> > event to userspace so that it gets notified of it. It will pick up the
> > new preferred mode, great.
> >
> > But what if it doesn't? There's no requirement for userspace to handle
> > hotplug events, and Kodi won't for example. So we just changed the TV
> > mode but not the actual mode, and that's it. It's just as broken for
> > Kodi as it is for X11 right now.
> >
> > If we can't get a bullet-proof solution, then I'm not convinced it's
> > worth addressing. Especially since it's already the current state, and
> > it doesn't seem to bother a lot of people.
> 
> I wouldn't rely on the "doesn't seem to bother a lot of people" bit too much.
> Here's why:
> 
> - Analog TV output is a relatively obscure feature in this day and age in the
>   first place.
> 
> - Out of the people interested in using it with VC4/VEC, many are actually using
>   the downstream kernel from https://github.com/raspberrypi/linux instead of the
>   upstream kernel, and/or firmware mode-switching instead of proper KMS.
> 
>   - The downstream kernel only reports modes that match the TV mode set at boot
>     either via vc4.tv_norm=, or implied by the resolution set via video=; note
>     that video= is also set appropriately at boot by Pi firmware, based on the
>     value of sdtv_mode set in config.txt. See also the
>     vc4_vec_connector_get_modes() and vc4_vec_get_default_mode() functions in
>     https://github.com/raspberrypi/linux/blob/dbd073e4028580a09b6ee507e0c137441cb52650/drivers/gpu/drm/vc4/vc4_vec.c
> 
>   - When firmware mode-switching is used, it sets the appropriate TV mode and
>     resolution based on the sdtv_mode set in config.txt.
> 
> So, all in all, the number of people who would use 1. analog TV out with VC4,
> 2. the upstream kernel, 3. full KMS (and thus the vc4_vec.c code) is rather
> small, so the fact that you're not hearing too many complaints doesn't mean that
> the current behavior is OK. If anybody ran into problems and was bothered by
> that, they likely migrated to the downstream kernel and/or firmware
> mode-switching.
>
> That being said, I completely forgot that there's a cmdline_mode field in
> struct drm_connector, even though I actually added code that examines it inside
> vc4_vec_connector_get_modes() that's in the downstream kernel. So... what do
> you think about just examining connector->cmdline_mode.tv_mode there? It seems
> to solve all the problems.

It's a very good idea, I'll work on it, thanks :)

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]