From: Uwe Sauter <uwe.sauter.de@gmail.com>
To: nouveau@lists.freedesktop.org
Subject: Re: [Nouveau] [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace
Date: Sat, 27 Feb 2021 13:28:27 +0100 [thread overview]
Message-ID: <91687a59-dae6-199e-ca4a-35b49b6959ea@gmail.com> (raw)
In-Reply-To: <CAKb7UvjBQeb84sitYUTLOd6EJo_+_9hXjmT=8r5V1onxtUMh7g@mail.gmail.com>
Hi Ilia,
Am 24.02.21 um 18:47 schrieb Ilia Mirkin:
> 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.
I can also report that the modesetting ddx that comes with xorg-server 1.20.10-3 (Arch Linux package) shows this kind of
cursor-cut-into-horizontal-stripes behavior. Changing to xf86-video-nouveau 1.0.17-1 solves this issue. But nouveau has
issues with Mate 1.24 (as discussed earlier this month).
My hardware:
# lspci -s 3:0.0 -v
03:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 710] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT710-4H-SL-2GD5
Flags: bus master, fast devsel, latency 0, IRQ 36, IOMMU group 12
Memory at fb000000 (32-bit, non-prefetchable) [size=16M]
Memory at fff0000000 (64-bit, prefetchable) [size=128M]
Memory at fff8000000 (64-bit, prefetchable) [size=32M]
I/O ports at f000 [size=128]
Expansion ROM at fc000000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Legacy Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
Capabilities: [900] Secondary PCI Express
Kernel driver in use: nouveau
Kernel modules: nouveau
If I can help in any way please let me know.
Regards,
Uwe
> Cheers,
>
> -ilia
> _______________________________________________
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
next prev parent reply other threads:[~2021-02-27 12:28 UTC|newest]
Thread overview: 38+ 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
[not found] ` <20210119015415.2511028-1-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-01-19 1:54 ` [PATCH 2/3] drm/nouveau/kms/nv50-: Report max cursor size to userspace Lyude Paul
[not found] ` <20210119015415.2511028-2-lyude-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-01-19 10:22 ` Simon Ser
2021-02-23 14:15 ` [Nouveau] " Alex Riesen
2021-02-23 14:56 ` Ilia Mirkin
2021-02-23 15:36 ` Alex Riesen
2021-02-23 15:46 ` Ilia Mirkin
2021-02-23 15:51 ` Alex Riesen
2021-02-23 16:22 ` Alex Riesen
2021-02-23 18:13 ` Ilia Mirkin
2021-02-24 9:08 ` Alex Riesen
2021-02-24 15:10 ` Ilia Mirkin
2021-02-24 16:35 ` Alex Riesen
2021-02-24 16:48 ` Ilia Mirkin
2021-02-24 16:53 ` Alex Riesen
2021-02-24 16:57 ` Ilia Mirkin
2021-02-24 17:02 ` Alex Riesen
2021-02-24 17:47 ` Ilia Mirkin
2021-02-27 12:28 ` Uwe Sauter [this message]
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 10:18 ` [PATCH 1/3] drivers/nouveau/kms/nv50-: Reject format modifiers for cursor planes Simon Ser
2021-01-19 15:50 ` Ville Syrjälä
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=91687a59-dae6-199e-ca4a-35b49b6959ea@gmail.com \
--to=uwe.sauter.de@gmail.com \
--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: 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;
as well as URLs for NNTP newsgroup(s).