Cursors larger than some size (64×64, I believe) get corrupted. While I don't have cursor themes that large, GTK3's drag and drop supports setting drag images. When these drag images — composed with the dragging cursor icon — fit into the cursor size limit, the cursor is set to the composed image instead of creating a new window to display the image. I originally noticed this in Firefox' GTK3 port. I reproduced it using GTK3's testdnd test. --- To reproduce: Set cursor theme to Adwaita, with size at least 32. Size 24 is not enough to reproduce. Get https://git.gnome.org/browse/gtk+/plain/tests/testdnd.c . Remove the #include "config.h". Compile using "gcc -o testdnd $(pkg-config --libs --cflags gtk+-3.0) testdnd.c". Run testdnd. Start dragging from the "Drag Here" button. With cursor size at least 32: When dragging over the "Drag Here" button, the cursor is corrupted. With cursor size at least 48: When dragging over the "Drop Here" button, the cursor is corrupted. --- (For some reason, I had to restart gnome-shell for cursor size changes to apply to the dragging cursors.) gtk3 3.12.2 gnome-themes-standard 3.12.0 xf86-video-intel 2.99.914-22-g926631e xorg-server 1.16.0 linux 3.16 Thinkpad X220 (SNB)
testdnd didn't trigger the issue for me, but it does sound like you should be going from a large cursor to a small one, which does hit a bug: commit 52c1e64692e3e80826e526dd14aec4bee137a19b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Aug 7 11:34:26 2014 +0100 sna: Flush cursor width changes The kernel only sees changes in the cursor width when the cursor handle is updated. In the cases where we reuse larger bo for smaller cursors, make sure we then reset the cursor handle (even though it has not changed) so tht the kernel updates its width. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Much better now, although not perfect. There's occasional garbage to the right of the cursor. Is the buffer not getting cleared properly before it's reused?
Drat, I saw that whilst testing but was looking in the one place. I was looking through for a residual stride problem, but missed the effect of the stride change on the current dirty rectangle. commit 6f69188cb2959abfb2fcd3f81cd4146aa3876bb5 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 8 07:25:03 2014 +0100 sna: Clear old cursors when resizing When changing the stride on a cursor, we have to clear the whole area and not just the rectangle outside of our overwritten area. Reported-by: Jan Alexander Steffens <jan.steffens@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82273 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
While my SandyBridge laptop is fine now, my desktop using Haswell Iris Pro 5200 still suffers from the exact same issue.
Hmm, double check it has the fixed ddx - the ddx is common for all kernels, but the kernel needs to differentiate between snb and ivb(hsw). However, I haven't spotted an issue with ivb (which should be the same as hsw/gt3e).
Also does the corruption look the same as before?
(II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20080730 (II) intel(0): SNA compiled from 2.99.914-44-gb3138be (--) intel(0): Integrated Graphics Chipset: Intel(R) Iris(TM) Pro Graphics 5200 Yes, it looks the same as before. On the desktop, moving the corrupted cursor to another output makes it display properly. When the "fixed" cursor is then returned to the default (smaller) cursor, this one is then displayed corrupted (two half-height cursors side-by-side; looks like a stride issue). This cursor then displays correctly again when moved to another output.
And can you check whether you see the issue with xf86-video-intel/tests/cursor-test?
Yes, it does happen. Cursors with either width or height >64 are corrupted. With either >=72 and both <=128, the stride is half of what it should be. With either >=160, the stride is a quarter of what is should be.
To clarify, it seems that cursors >64x64 get a 128x128 texture with a 64 stride, and cursors >128x128 get a 256x256 texture with a 64 stride.
Please attach the Xorg.0.log (or equivalent) for the failing machine.
Created attachment 104486 [details] Xorg log
Please check that your 3.15.8 has commit 4b0e333ee1100e621c5530d368a3029d41131214 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 30 16:35:26 2014 +0300 drm/i915: Always apply cursor width changes it was marked for stable but only first applied to 3.16-rc1. Fyi, I can't see the patch in either 3.15.8 or 3.15.9.
If you can't find it in the stable releases, it's not in -zen, either.
Created attachment 104547 [details] [review] 3.15.y backport of always apply cursors Please can you quickly test this patch?
Seems to work properly, thanks.
Jani, my stable request fell on deaf ears, could you try shepherding this patch into 3.16?
It's for 3.15. And we are too late. :|
Sorry, not much I can do since 3.15.y is EOL. Fix is in 3.16 and later.
Closing resolved+fixed. commit ecb889e for 3.16 and later, patch for 3.15.x verified by reporter.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.