linux-kernel - Re: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128

Open Source and information security mailing list archives

Message-ID: <20210308165050.qhhf5aqdcldet5p6@maple.lan>
Date:   Mon, 8 Mar 2021 16:50:50 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Lyude Paul <lyude@...hat.com>
Cc:     nouveau@...ts.freedesktop.org,
        "open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS" 
        <dri-devel@...ts.freedesktop.org>, David Airlie <airlied@...ux.ie>,
        Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@...el.com>,
        James Jones <jajones@...dia.com>,
        open list <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org, Ben Skeggs <bskeggs@...hat.com>,
        Dave Airlie <airlied@...hat.com>
Subject: Re: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128

On Thu, Mar 04, 2021 at 08:52:41PM -0500, Lyude Paul wrote:
> While Kepler does technically support 256x256 cursors, it turns out that
> Kepler actually has some additional requirements for scanout surfaces that
> we're not enforcing correctly, which aren't present on Maxwell and later.
> Cursor surfaces must always use small pages (4K), and overlay surfaces must
> always use large pages (128K).
> 
> Fixing this correctly though will take a bit more work: as we'll need to
> add some code in prepare_fb() to move cursor FBs in large pages to small
> pages, and vice-versa for overlay FBs. So until we have the time to do
> that, just limit cursor surfaces to 128x128 - a size small enough to always
> default to small pages.
> 
> This means small ovlys are still broken on Kepler, but it is extremely
> unlikely anyone cares about those anyway :).
> 
> Signed-off-by: Lyude Paul <lyude@...hat.com>
> Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to userspace")
> Cc: <stable@...r.kernel.org> # v5.11+

I was experiencing problems with the mouse cursor on my system in v5.11
and after a bisect to help me search the web I found my way to this
patch, which fixed the problem for me.

Mine is an Armv8 system but there is nothing particularly exotic from a
graphics card or software point of view: Debian bullseye/wayland
(gnome-shell 3.38.3, mesa-20.3.4) running on a GT-710.

However FWIW:
Tested-by: Daniel Thompson <daniel.thompson@...aro.org>

Daniel.

> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 196612addfd6..1c9c0cdf85db 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2693,9 +2693,20 @@ nv50_display_create(struct drm_device *dev)
>  	else
>  		nouveau_display(dev)->format_modifiers = disp50xx_modifiers;
>  
> -	if (disp->disp->object.oclass >= GK104_DISP) {
> +	/* FIXME: 256x256 cursors are supported on Kepler, however unlike Maxwell and later
> +	 * generations Kepler requires that we use small pages (4K) for cursor scanout surfaces. The
> +	 * proper fix for this is to teach nouveau to migrate fbs being used for the cursor plane to
> +	 * small page allocations in prepare_fb(). When this is implemented, we should also force
> +	 * large pages (128K) for ovly fbs in order to fix Kepler ovlys.
> +	 * But until then, just limit cursors to 128x128 - which is small enough to avoid ever using
> +	 * large pages.
> +	 */
> +	if (disp->disp->object.oclass >= GM107_DISP) {
>  		dev->mode_config.cursor_width = 256;
>  		dev->mode_config.cursor_height = 256;
> +	} else if (disp->disp->object.oclass >= GK104_DISP) {
> +		dev->mode_config.cursor_width = 128;
> +		dev->mode_config.cursor_height = 128;
>  	} else {
>  		dev->mode_config.cursor_width = 64;
>  		dev->mode_config.cursor_height = 64;
> -- 
> 2.29.2
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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