From: Maxime Ripard <maxime@cerno.tech>
To: "Noralf Trønnes" <noralf@tronnes.org>
Cc: kfyatek+publicgit@gmail.com, Karol Herbst <kherbst@redhat.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
Daniel Vetter <daniel@ffwll.ch>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
David Airlie <airlied@linux.ie>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Lyude Paul <lyude@redhat.com>, Emma Anholt <emma@anholt.net>,
Chen-Yu Tsai <wens@csie.org>,
Samuel Holland <samuel@sholland.org>,
Ben Skeggs <bskeggs@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Dom Cobley <dom@raspberrypi.com>,
linux-sunxi@lists.linux.dev,
Dave Stevenson <dave.stevenson@raspberrypi.com>,
intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
nouveau@lists.freedesktop.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
linux-arm-kernel@lists.infradead.org,
dri-devel@lists.freedesktop.org,
Hans de Goede <hdegoede@redhat.com>,
Phil Elwell <phil@raspberrypi.com>
Subject: Re: [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property
Date: Tue, 18 Oct 2022 12:00:33 +0200 [thread overview]
Message-ID: <20221018100033.d2sf7xagyycx5d4p@houat> (raw)
In-Reply-To: <81936381-ae37-8c84-4681-9eff19f653b5@tronnes.org>
[-- Attachment #1: Type: text/plain, Size: 3927 bytes --]
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.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-10-18 10:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220728-rpi-analog-tv-properties-v5-0-d841cc64fe4b@cerno.tech>
[not found] ` <20220728-rpi-analog-tv-properties-v5-22-d841cc64fe4b@cerno.tech>
2022-10-13 18:23 ` [PATCH v5 22/22] drm/sun4i: tv: " Jernej Škrabec
2022-10-14 7:38 ` Maxime Ripard
2022-10-15 8:59 ` Jernej Škrabec
[not found] ` <20220728-rpi-analog-tv-properties-v5-1-d841cc64fe4b@cerno.tech>
2022-10-15 15:06 ` [PATCH v5 01/22] drm/tests: Add Kunit Helpers Noralf Trønnes
[not found] ` <20220728-rpi-analog-tv-properties-v5-8-d841cc64fe4b@cerno.tech>
2022-10-16 16:11 ` [PATCH v5 08/22] drm/modes: Move named modes parsing to a separate function Noralf Trønnes
2022-10-18 7:57 ` Maxime Ripard
[not found] ` <20220728-rpi-analog-tv-properties-v5-6-d841cc64fe4b@cerno.tech>
2022-10-16 17:34 ` [PATCH v5 06/22] drm/modes: Add a function to generate analog display modes Mateusz Kwiatkowski
2022-10-18 8:08 ` Maxime Ripard
[not found] ` <20220728-rpi-analog-tv-properties-v5-13-d841cc64fe4b@cerno.tech>
2022-10-16 17:51 ` [PATCH v5 13/22] drm/modes: Introduce the tv_mode property as a command-line option Mateusz Kwiatkowski
2022-10-17 10:21 ` Noralf Trønnes
[not found] ` <20220728-rpi-analog-tv-properties-v5-19-d841cc64fe4b@cerno.tech>
2022-10-16 18:12 ` [PATCH v5 19/22] drm/vc4: vec: Check for VEC output constraints Mateusz Kwiatkowski
2022-10-16 18:16 ` Mateusz Kwiatkowski
2022-10-18 8:27 ` Maxime Ripard
[not found] ` <20220728-rpi-analog-tv-properties-v5-20-d841cc64fe4b@cerno.tech>
2022-10-16 18:52 ` [PATCH v5 20/22] drm/vc4: vec: Convert to the new TV mode property Mateusz Kwiatkowski
2022-10-16 18:56 ` Mateusz Kwiatkowski
2022-10-17 10:31 ` Noralf Trønnes
2022-10-18 10:00 ` Maxime Ripard [this message]
[not found] ` <da2b4cb4-5d12-3161-64e3-e87a8cc63e81@gmail.com>
2022-10-20 11:58 ` maxime
2022-10-17 11:39 ` Noralf Trønnes
[not found] ` <20220728-rpi-analog-tv-properties-v5-21-d841cc64fe4b@cerno.tech>
2022-10-16 19:02 ` [PATCH v5 21/22] drm/vc4: vec: Add support for more analog TV standards Mateusz Kwiatkowski
2022-10-16 19:46 ` [PATCH] drm/vc4: vec: Add support for PAL-60 Mateusz Kwiatkowski
2022-10-18 8:31 ` Maxime Ripard
2022-10-18 20:57 ` Mateusz Kwiatkowski
2022-10-20 15:34 ` maxime
[not found] ` <20220728-rpi-analog-tv-properties-v5-16-d841cc64fe4b@cerno.tech>
2022-10-17 10:36 ` [PATCH v5 16/22] drm/atomic-helper: Add a TV properties reset helper Noralf Trønnes
[not found] ` <20220728-rpi-analog-tv-properties-v5-12-d841cc64fe4b@cerno.tech>
2022-10-17 10:44 ` [PATCH v5 12/22] drm/connector: Add a function to lookup a TV mode by its name Noralf Trønnes
2022-10-18 9:33 ` Maxime Ripard
2022-10-18 12:29 ` Noralf Trønnes
2022-10-19 8:48 ` Maxime Ripard
2022-10-19 10:43 ` Noralf Trønnes
2022-10-20 11:29 ` maxime
[not found] ` <20220728-rpi-analog-tv-properties-v5-7-d841cc64fe4b@cerno.tech>
2022-10-15 16:58 ` [PATCH v5 07/22] drm/client: Add some tests for drm_connector_pick_cmdline_mode() Noralf Trønnes
2022-10-20 7:55 ` Michał Winiarski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221018100033.d2sf7xagyycx5d4p@houat \
--to=maxime@cerno.tech \
--cc=airlied@linux.ie \
--cc=bskeggs@redhat.com \
--cc=daniel@ffwll.ch \
--cc=dave.stevenson@raspberrypi.com \
--cc=dom@raspberrypi.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emma@anholt.net \
--cc=geert@linux-m68k.org \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jernej.skrabec@gmail.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kfyatek+publicgit@gmail.com \
--cc=kherbst@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=noralf@tronnes.org \
--cc=nouveau@lists.freedesktop.org \
--cc=phil@raspberrypi.com \
--cc=rodrigo.vivi@intel.com \
--cc=samuel@sholland.org \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®