From: Ilia Mirkin <imirkin@alum.mit.edu> To: Alex Riesen <alexander.riesen@cetitec.com> Cc: Simon Ser <contact@emersion.fr>, dri-devel <dri-devel@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com>, nouveau <nouveau@lists.freedesktop.org>, Dave Airlie <airlied@redhat.com> Subject: Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace Date: Wed, 24 Feb 2021 12:47:58 -0500 [thread overview] Message-ID: <CAKb7UvjBQeb84sitYUTLOd6EJo_+_9hXjmT=8r5V1onxtUMh7g@mail.gmail.com> (raw) In-Reply-To: <YDaGtzRDUIbErYDY@pflmari> On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen <alexander.riesen@cetitec.com> wrote: > > Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100: > > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote: > > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100: > > > > Just to be crystal clear -- are you saying that 128x128 works or does > > > > not work? (You said "yes", which would imply it works OK, but then you > > > > said both cases, which would imply doesn't work since 256x256 doesn't > > > > work?) > > > > > > Modetest with 128x128 cursor works. Without damage to the cursor: modetest > > > shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in > > > vanilla v5.11 with the commit reverted. > > > > But modetest with 256x256 doesn't work (correctly) right? Or did I > > misunderstand? > > Right. That's why I was asking if I did everything right: it was just corrupted > in both kernels. OK. So 128x128 works, 256x256 does not. Interesting. > > > All the patch does is allow those large cursors to be used, which gets > > reported via drm APIs and modesetting picks the largest cursor > > available. (And actually I think it's even not required to use the > > large cursors, it just controls what's reported in the defaults to > > userspace.) > > Maybe something in X code is not prepared to handle the kernel reporting > large cursor support? Even though 128x128 is pretty large, and I don't think > I even use that large cursors in X configuration. How can I check? Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely to be an issue. I believe that AMD also exposes 256x256 cursors depending on the gen: display/dc/dce100/dce100_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce110/dce110_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce112/dce112_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce120/dce120_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dcn10/dcn10_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn20/dcn20_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn21/dcn21_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn30/dcn30_resource.c: dc->caps.max_cursor_size = 256; which should have the equivalent effect. But since you're seeing issues with modetest as well (which uses the ioctl's pretty directly), presumably Xorg is not to blame. It's easy enough to adjust the kernel to report a lower size (and reject the larger cursors), I just want to understand which gens are affected by this. Cheers, -ilia _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
WARNING: multiple messages have this Message-ID (diff)
From: Ilia Mirkin <imirkin@alum.mit.edu> To: Alex Riesen <alexander.riesen@cetitec.com> Cc: dri-devel <dri-devel@lists.freedesktop.org>, Ben Skeggs <bskeggs@redhat.com>, nouveau <nouveau@lists.freedesktop.org>, Dave Airlie <airlied@redhat.com> Subject: Re: [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace Date: Wed, 24 Feb 2021 12:47:58 -0500 [thread overview] Message-ID: <CAKb7UvjBQeb84sitYUTLOd6EJo_+_9hXjmT=8r5V1onxtUMh7g@mail.gmail.com> (raw) In-Reply-To: <YDaGtzRDUIbErYDY@pflmari> On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen <alexander.riesen@cetitec.com> wrote: > > Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100: > > On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen <alexander.riesen@cetitec.com> wrote: > > > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100: > > > > Just to be crystal clear -- are you saying that 128x128 works or does > > > > not work? (You said "yes", which would imply it works OK, but then you > > > > said both cases, which would imply doesn't work since 256x256 doesn't > > > > work?) > > > > > > Modetest with 128x128 cursor works. Without damage to the cursor: modetest > > > shows normal cursor in vanilla v5.11. Modetest also shows normal cursor in > > > vanilla v5.11 with the commit reverted. > > > > But modetest with 256x256 doesn't work (correctly) right? Or did I > > misunderstand? > > Right. That's why I was asking if I did everything right: it was just corrupted > in both kernels. OK. So 128x128 works, 256x256 does not. Interesting. > > > All the patch does is allow those large cursors to be used, which gets > > reported via drm APIs and modesetting picks the largest cursor > > available. (And actually I think it's even not required to use the > > large cursors, it just controls what's reported in the defaults to > > userspace.) > > Maybe something in X code is not prepared to handle the kernel reporting > large cursor support? Even though 128x128 is pretty large, and I don't think > I even use that large cursors in X configuration. How can I check? Yes, 64x64 is enough for anyone (or was it 640kb?) But it's unlikely to be an issue. I believe that AMD also exposes 256x256 cursors depending on the gen: display/dc/dce100/dce100_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce110/dce110_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce112/dce112_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce120/dce120_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce60/dce60_resource.c: dc->caps.max_cursor_size = 64; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dce80/dce80_resource.c: dc->caps.max_cursor_size = 128; display/dc/dcn10/dcn10_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn20/dcn20_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn21/dcn21_resource.c: dc->caps.max_cursor_size = 256; display/dc/dcn30/dcn30_resource.c: dc->caps.max_cursor_size = 256; which should have the equivalent effect. But since you're seeing issues with modetest as well (which uses the ioctl's pretty directly), presumably Xorg is not to blame. It's easy enough to adjust the kernel to report a lower size (and reject the larger cursors), I just want to understand which gens are affected by this. Cheers, -ilia _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-02-24 17:48 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-19 1:54 [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 1:54 ` [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 10:22 ` Simon Ser 2021-01-19 10:22 ` Simon Ser 2021-01-19 10:22 ` Simon Ser 2021-02-23 14:15 ` Alex Riesen 2021-02-23 14:15 ` Alex Riesen 2021-02-23 14:15 ` [Nouveau] " Alex Riesen 2021-02-23 14:56 ` Ilia Mirkin 2021-02-23 14:56 ` Ilia Mirkin 2021-02-23 14:56 ` [Nouveau] " Ilia Mirkin 2021-02-23 15:36 ` Alex Riesen 2021-02-23 15:36 ` Alex Riesen 2021-02-23 15:36 ` [Nouveau] " Alex Riesen 2021-02-23 15:46 ` Ilia Mirkin 2021-02-23 15:46 ` Ilia Mirkin 2021-02-23 15:46 ` [Nouveau] " Ilia Mirkin 2021-02-23 15:51 ` Alex Riesen 2021-02-23 15:51 ` Alex Riesen 2021-02-23 15:51 ` [Nouveau] " Alex Riesen 2021-02-23 16:22 ` Alex Riesen 2021-02-23 16:22 ` Alex Riesen 2021-02-23 16:22 ` [Nouveau] " Alex Riesen 2021-02-23 18:13 ` Ilia Mirkin 2021-02-23 18:13 ` Ilia Mirkin 2021-02-23 18:13 ` [Nouveau] " Ilia Mirkin 2021-02-24 9:08 ` Alex Riesen 2021-02-24 9:08 ` Alex Riesen 2021-02-24 9:08 ` [Nouveau] " Alex Riesen 2021-02-24 15:10 ` Ilia Mirkin 2021-02-24 15:10 ` Ilia Mirkin 2021-02-24 16:35 ` [Nouveau] " Alex Riesen 2021-02-24 16:35 ` Alex Riesen 2021-02-24 16:48 ` [Nouveau] " Ilia Mirkin 2021-02-24 16:48 ` Ilia Mirkin 2021-02-24 16:53 ` [Nouveau] " Alex Riesen 2021-02-24 16:53 ` Alex Riesen 2021-02-24 16:57 ` [Nouveau] " Ilia Mirkin 2021-02-24 16:57 ` Ilia Mirkin 2021-02-24 17:02 ` [Nouveau] " Alex Riesen 2021-02-24 17:02 ` Alex Riesen 2021-02-24 17:47 ` Ilia Mirkin [this message] 2021-02-24 17:47 ` Ilia Mirkin 2021-02-27 12:28 ` [Nouveau] " Uwe Sauter 2021-02-27 21:26 ` Ilia Mirkin 2021-02-28 15:10 ` Uwe Sauter 2021-02-28 17:02 ` Ilia Mirkin 2021-02-28 17:59 ` Uwe Sauter 2021-02-28 19:10 ` Ilia Mirkin 2021-02-28 19:24 ` Uwe Sauter 2021-02-28 20:38 ` Ilia Mirkin 2021-03-03 12:41 ` Alex Riesen 2021-03-03 13:12 ` Ilia Mirkin 2021-03-03 13:25 ` Uwe Sauter 2021-03-03 13:33 ` Ilia Mirkin 2021-03-03 17:02 ` Uwe Sauter 2021-03-03 17:11 ` Lyude Paul 2021-03-03 16:51 ` Lyude Paul 2021-03-03 17:05 ` James Jones 2021-01-19 1:54 ` [PATCH 3/3] drm/nouveau/kms/nve4-nv138: Fix > 64x64 cursors Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 1:54 ` Lyude Paul 2021-01-19 10:18 ` [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes Simon Ser 2021-01-19 10:18 ` Simon Ser 2021-01-19 10:18 ` Simon Ser 2021-01-19 15:50 ` Ville Syrjälä 2021-01-19 15:50 ` Ville Syrjälä 2021-01-19 15:50 ` Ville Syrjälä 2021-01-19 15:52 ` James Jones 2021-01-19 15:52 ` James Jones 2021-01-19 15:52 ` James Jones
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='CAKb7UvjBQeb84sitYUTLOd6EJo_+_9hXjmT=8r5V1onxtUMh7g@mail.gmail.com' \ --to=imirkin@alum.mit.edu \ --cc=airlied@redhat.com \ --cc=alexander.riesen@cetitec.com \ --cc=bskeggs@redhat.com \ --cc=contact@emersion.fr \ --cc=dri-devel@lists.freedesktop.org \ --cc=nouveau@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: linkBe 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.