All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: Jyri Sarha <jyri.sarha@iki.fi>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Sam Ravnborg <sam@ravnborg.org>,
	Devarsh Thakkar <devarsht@ti.com>,
	Aradhya Bhatia <a-bhatia1@ti.com>,
	Francesco Dolcini <francesco@dolcini.it>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	"wayland-devel@lists.freedesktop.org"
	<wayland-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/tidss: Fix initial plane zpos values
Date: Tue, 13 Feb 2024 11:04:40 +0200	[thread overview]
Message-ID: <20240213110440.13af335a@eldfell> (raw)
In-Reply-To: <20240213-tidss-fixes-v1-1-d709e8dfa505@ideasonboard.com>

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

On Tue, 13 Feb 2024 10:16:36 +0200
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:

> When the driver sets up the zpos property it sets the default zpos value
> to the HW id of the plane. That is fine as such, but as on many DSS
> versions the driver arranges the DRM planes in a different order than
> the HW planes (to keep the non-scalable planes first), this leads to odd
> initial zpos values. An example is J721e, where the initial zpos values
> for DRM planes are 1, 3, 0, 2.
> 
> In theory the userspace should configure the zpos values properly when
> using multiple planes, and in that sense the initial zpos values
> shouldn't matter, but there's really no reason not to fix this and help
> the userspace apps which don't handle zpos perfectly. In particular,
> Weston seems to have issues dealing with the planes with the current
> default zpos values.
> 
> So let's change the zpos values for the DRM planes to 0, 1, 2, 3.
> 
> Another option would be to configure the planes marked as primary planes
> to zpos 0. On a two display system this would give us plane zpos values
> of 0, 0, 1, 2. The end result and behavior would be very similar in this
> option, and I'm not aware that this would actually help us in any way.
> So, to keep the code simple, I opted for the 0, 1, 2, 3 values.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem")

Hi Tomi,

have you reported this to Weston? What exactly is the problem?

It doesn't seem like a good idea to work around userspace bugs
(non-regression, I presume?) with kernel changes.


Thanks,
pq

> ---
>  drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
> index e1c0ef0c3894..68fed531f6a7 100644
> --- a/drivers/gpu/drm/tidss/tidss_plane.c
> +++ b/drivers/gpu/drm/tidss/tidss_plane.c
> @@ -213,7 +213,7 @@ struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
>  
>  	drm_plane_helper_add(&tplane->plane, &tidss_plane_helper_funcs);
>  
> -	drm_plane_create_zpos_property(&tplane->plane, hw_plane_id, 0,
> +	drm_plane_create_zpos_property(&tplane->plane, tidss->num_planes, 0,
>  				       num_planes - 1);
>  
>  	ret = drm_plane_create_color_properties(&tplane->plane,
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-02-13  9:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13  8:16 [PATCH 0/2] drm/tidss: Fixes for zpos and multi-display Tomi Valkeinen
2024-02-13  8:16 ` [PATCH 1/2] drm/tidss: Fix initial plane zpos values Tomi Valkeinen
2024-02-13  9:04   ` Pekka Paalanen [this message]
2024-02-13  9:57     ` Tomi Valkeinen
2024-02-13 10:18       ` Marius Vlad
2024-02-13 11:39         ` Daniel Stone
2024-02-16  9:00           ` Tomi Valkeinen
2024-02-16 14:02             ` Daniel Stone
2024-02-15 12:12   ` Aradhya Bhatia
2024-02-13  8:16 ` [PATCH 2/2] drm/tidss: Fix sync-lost issue with two displays Tomi Valkeinen
2024-02-15 12:12   ` Aradhya Bhatia

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=20240213110440.13af335a@eldfell \
    --to=pekka.paalanen@haloniitty.fi \
    --cc=a-bhatia1@ti.com \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=devarsht@ti.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francesco@dolcini.it \
    --cc=jyri.sarha@iki.fi \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=tomi.valkeinen@ti.com \
    --cc=tzimmermann@suse.de \
    --cc=wayland-devel@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.