From: Daniel Thompson <daniel.thompson@linaro.org>
To: Lyude Paul <lyude@redhat.com>
Cc: nouveau@lists.freedesktop.org,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<dri-devel@lists.freedesktop.org>,
David Airlie <airlied@linux.ie>,
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>,
James Jones <jajones@nvidia.com>,
open list <linux-kernel@vger.kernel.org>,
stable@vger.kernel.org, Ben Skeggs <bskeggs@redhat.com>,
Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] drm/nouveau/kms/nve4-nv108: Limit cursors to 128x128
Date: Mon, 8 Mar 2021 16:50:50 +0000 [thread overview]
Message-ID: <20210308165050.qhhf5aqdcldet5p6@maple.lan> (raw)
In-Reply-To: <20210305015242.740590-1-lyude@redhat.com>
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@redhat.com>
> Fixes: d3b2f0f7921c ("drm/nouveau/kms/nv50-: Report max cursor size to userspace")
> Cc: <stable@vger.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@linaro.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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2021-03-08 16:51 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 1:52 Lyude Paul
2021-03-08 16:50 ` Daniel Thompson [this message]
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=20210308165050.qhhf5aqdcldet5p6@maple.lan \
--to=daniel.thompson@linaro.org \
--cc=airlied@linux.ie \
--cc=airlied@redhat.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jajones@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=nouveau@lists.freedesktop.org \
--cc=pankaj.laxminarayan.bharadiya@intel.com \
--cc=stable@vger.kernel.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®