[Intel-gfx] [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property
maxime at cerno.tech
maxime at cerno.tech
Thu Oct 20 11:58:49 UTC 2022
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
-------------- 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/20221020/9ae39092/attachment.sig>
More information about the Intel-gfx
mailing list