[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81936381-ae37-8c84-4681-9eff19f653b5@tronnes.org>
Date: Mon, 17 Oct 2022 12:31:31 +0200
From: Noralf Trønnes <noralf@...nnes.org>
To: kfyatek+publicgit@...il.com, Maxime Ripard <maxime@...no.tech>,
Karol Herbst <kherbst@...hat.com>,
Jani Nikula <jani.nikula@...ux.intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>,
Daniel Vetter <daniel@...ll.ch>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
David Airlie <airlied@...ux.ie>,
Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
Lyude Paul <lyude@...hat.com>,
Maxime Ripard <mripard@...nel.org>,
Emma Anholt <emma@...olt.net>, Chen-Yu Tsai <wens@...e.org>,
Samuel Holland <samuel@...lland.org>,
Ben Skeggs <bskeggs@...hat.com>,
Thomas Zimmermann <tzimmermann@...e.de>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Jernej Skrabec <jernej.skrabec@...il.com>
Cc: Dom Cobley <dom@...pberrypi.com>, linux-sunxi@...ts.linux.dev,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
nouveau@...ts.freedesktop.org,
Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-arm-kernel@...ts.infradead.org,
dri-devel@...ts.freedesktop.org,
Hans de Goede <hdegoede@...hat.com>,
Phil Elwell <phil@...pberrypi.com>,
Noralf Trønnes <noralf@...nnes.org>
Subject: Re: [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode
property
Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> Hi Maxime,
>
>> 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.
Noralf.
Powered by blists - more mailing lists