lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Aug 2022 17:26:19 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Noralf Trønnes <noralf@...nnes.org>
Cc:     Jernej Skrabec <jernej.skrabec@...il.com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Jerome Brunet <jbrunet@...libre.com>,
        Samuel Holland <samuel@...lland.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>, Emma Anholt <emma@...olt.net>,
        David Airlie <airlied@...ux.ie>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Kevin Hilman <khilman@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
        Phil Elwell <phil@...pberrypi.com>,
        Mateusz Kwiatkowski <kfyatek+publicgit@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Dave Stevenson <dave.stevenson@...pberrypi.com>,
        linux-amlogic@...ts.infradead.org, dri-devel@...ts.freedesktop.org,
        Dom Cobley <dom@...pberrypi.com>
Subject: Re: [PATCH v1 23/35] drm/vc4: vec: Convert to the new TV mode
 property

Hi,

On Sat, Aug 20, 2022 at 07:22:48PM +0200, Noralf Trønnes wrote:
> Den 29.07.2022 18.35, skrev Maxime Ripard:
> > Now that the core can deal fine with analog TV modes, let's convert the vc4
> > VEC driver to leverage those new features.
> > 
> > We've added some backward compatibility to support the old TV mode property
> > and translate it into the new TV norm property.
> > 
> > Signed-off-by: Maxime Ripard <maxime@...no.tech>
> > 
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> 
> >  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.mode].mode);
> > +	mode = drm_mode_duplicate(connector->dev, &drm_mode_480i);
> > +	if (!mode) {
> > +		DRM_ERROR("Failed to create a new display mode\n");
> > +		return -ENOMEM;
> > +	}
> > +
> > +	drm_mode_probed_add(connector, mode);
> > +
> > +	mode = drm_mode_duplicate(connector->dev, &drm_mode_576i);
> 
> Maybe the mode that matches tv.norm should be marked as preferred so
> userspace knows which one to pick?

I'm not sure how realistic that would be. Doing this based on the driver
/ cmdline preference is going to be fairly easy, but then it's a
property, it's going to be updated, and we probably don't want to mess
around the mode flags based on new property values?

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists