Hi Ilia,
Am 24.02.21 um 18:47 schrieb Ilia Mirkin:
On Wed, Feb 24, 2021 at 12:03 PM Alex Riesen
<alexander.rie...@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.rie...@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
