actually mouse doesn't die but the mouse arrow disappear and working is difficult

on devel@ mailing list, reporter confirmed that downgrading to a 5.1 kernel fixes the problem. So, though the "only over application windows" thing is odd to me, presumably this is some issue with the cursor-sprite / overlay plan support in the Intel driver?

Johan - can you look at this and see what further debugging steps, or disposition for this bug is indicated?

Can I assume this is using the Wayland session? Do you use any HiDPI scaling, or non-default themes? Can you attach the journal from when the issue reproduces?

(In reply to Jonas Ådahl from comment #3)
> Can I assume this is using the Wayland session? Do you use any HiDPI
> scaling, or non-default themes? Can you attach the journal from when the
> issue reproduces?

Yes: wayland session
No: No Hdpi scaling or non default theme
I have to switch to latest kernel to get the journalctl thing

Created attachment 1602205 [details]
journalctl output

joornalctl output when mouse disappears

The journal didn't contain anything useful, suggesting that we either set an empty sprite (unlikely, since it works on other kernels), or the kernel does something funny.

Can you, as root run (enables drm debug logging)

 # echo 0xfe > /sys/module/drm/parameters/debug

Reproduce the issue

then, again as root, run (disables drm debug logging)

 # echo 0 > /sys/module/drm/parameters/debug

Then attach the *kernel* journal from when you reproduced the issue?

I'm seeing this issue on Fedora 30 with Gnome Wayland session with Intel graphics and two displays connected via Display Port since upgrading to kernel-5.2.6-200.fc30.x86_64. Sometimes if I move the mouse pointer outside of an application window, or invoke the GNOME Shell Overview it vanishes. Clicking on an application window makes the pointer visible again.

I think the issue *may* be time related in some way. The only way I have worked out to reproduce the issue is to not interact with the mouse for a minute or so. I can't find any other action which triggers the issue. Once the mouse pointer appears again it remains visible outside of application windows and in Overview for a while.

I've enabled debugging as described in comment 6  and will attach output. It is very big though and I can't point at anything significant point in the 87454 lines. I think the issue manifested during 16:58, but maybe earlier in 16:59. I disabled debugging once I got the mouse pointer visible again.

"lspci | grep VGA" output is:

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)

I also have a machine with Intel CPU but using discreet AMD graphics card and single display that I'm not seeing this issue on.

Created attachment 1602247 [details]
kernel journal from before during and shortly after the bug manifests

Actually clicking a window doesn't always make the mouse pointer visible again. Clicking on a window titlebar always make it visible, I think.

no improvement with 5.2.7 kernel

no improvement with 5.2.8 kernel

on latest 5.2.9 kernel performance is poorer, mouse disappears more often than in previous kernel, any other think??

See also: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1165
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1739832

Can confirm that disappearing mouse pointer in non application windows is caused by bug in kernel 5.2. After downgrading to kernel 5.1 (kernel-5.1.20-300.fc30.x86_64) and testing all weekend, mouse pointer functions properly.

I've reported https://bugs.freedesktop.org/show_bug.cgi?id=111541 for the bug that reproduces only with kernel version 5.2 and higher. As I have only seen this bug momentarily once after 1.5 weeks on 5.2, I'd appreciate if anyone who sees it more often can provide more debug information there.

5.2.11-200.fc30 kernel makes no difference

are these issues not the same:
https://bugzilla.redhat.com/show_bug.cgi?id=1739832
https://bugzilla.redhat.com/show_bug.cgi?id=1738614
https://bugzilla.redhat.com/show_bug.cgi?id=1739169
for me this issue is still occurring in Fedora 30. I have it for a month now on 3 machines and definitely started experiencing this after an update in begin August. I am updating all my machines daily. the workaround of opening a new application in Activities is the best for me. my question is if these bugs should not be merged and the priority raised, since it is basic functionality for the GUI/desktop and a regress

There have been reports that this is caused by recent kernel changes; and from other reports it seems that this is fixed by the 5.3 kernels.

If you have this bug, please try installing a 5.3 kernel and report back to us if that helps. I suggest trying this kernel:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1375052

Yes this is a F31 kernel, but those work fine on F30. For instructions for installing a kernel directly from koji (our build system) see:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

*** Bug 1739169 has been marked as a duplicate of this bug. ***

*** Bug 1739832 has been marked as a duplicate of this bug. ***

(In reply to Hans de Goede from comment #18)
> There have been reports that this is caused by recent kernel changes; and
> from other reports it seems that this is fixed by the 5.3 kernels.
> 
> If you have this bug, please try installing a 5.3 kernel and report back to
> us if that helps. I suggest trying this kernel:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1375052
> 
> Yes this is a F31 kernel, but those work fine on F30. For instructions for
> installing a kernel directly from koji (our build system) see:
> https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

I reported the bug, my position is that kernel should work also in F30, the regression must be solved in F30 and not jumping to a F31-series kernel. Quite surprised that this issue was known long before I reported in bugzilla.

My two cents...

please check if latest 5.2.14 kernel solves the issue (in my case it seems that issue has been solved). Please confirm

Still happening here on 5.2.14-200.fc30.x86_64

(In reply to Dimitris from comment #23)
> Still happening here on 5.2.14-200.fc30.x86_64

unfortunately it happened again but it was triggered after a longer time. Waiting for solution

I have 3 machines on the latest regular F30 with gnome desktop. my gsettings are all on "focus follows the mouse"

I use all 3 machines all the time and this is my experience from first week of August:

*the bug happens more or less every 1 hour on a 64-bit laptop that is almost never rebooted (just suspended)
*the bug happens once every 1 week or so on a 32-bit laptop that is almost never rebooted (just suspended)
*the bug happens once every 2 week or so on a 64-bit desktop that I am rebooting every day some times several times per day

I will start rebooting the 64-bit laptop one time per day and see if that makes a difference

(In reply to frog from comment #25)
> I have 3 machines on the latest regular F30 with gnome desktop. my gsettings
> are all on "focus follows the mouse"
> 
> I use all 3 machines all the time and this is my experience from first week
> of August:
> 
> *the bug happens more or less every 1 hour on a 64-bit laptop that is almost
> never rebooted (just suspended)
> *the bug happens once every 1 week or so on a 32-bit laptop that is almost
> never rebooted (just suspended)
> *the bug happens once every 2 week or so on a 64-bit desktop that I am
> rebooting every day some times several times per day
> 
> I will start rebooting the 64-bit laptop one time per day and see if that
> makes a difference

*after rebooting both laptops started to see the issue very regularly on both machines (several times per hour)
*just the past day saw it several times on the desktop
*have NOT experienced a single occurrence (yet) on a Rawhide (F32) virtual machine that I am running on the desktop, will test that further

*** Bug 1753741 has been marked as a duplicate of this bug. ***

(In reply to antonio montagnani from comment #21)
> (In reply to Hans de Goede from comment #18)
> > There have been reports that this is caused by recent kernel changes; and
> > from other reports it seems that this is fixed by the 5.3 kernels.
> > 
> > If you have this bug, please try installing a 5.3 kernel and report back to
> > us if that helps. I suggest trying this kernel:
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1375052
> > 
> > Yes this is a F31 kernel, but those work fine on F30. For instructions for
> > installing a kernel directly from koji (our build system) see:
> > https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt
> 
> I reported the bug, my position is that kernel should work also in F30, the
> regression must be solved in F30 and not jumping to a F31-series kernel.
> Quite surprised that this issue was known long before I reported in bugzilla.
> 
> My two cents...

I have tried this on my daily driver laptop and it does cure the problem.

(In reply to antonio montagnani from comment #21)
> I reported the bug, my position is that kernel should work also in F30, the
> regression must be solved in F30 and not jumping to a F31-series kernel.
> Quite surprised that this issue was known long before I reported in bugzilla.
> 
> My two cents...

I do not disagree with you that this should also work with F30. But other then that the 5.2 kernel breaks things and that the 5.3 kernel fixes things again, clearly making this a kernel issue, we do not know exactly what is going on.

I've looked thrgough the 5.3 changelog for drivers/gpu/drm/i915 hoping to find a fix to backport, but nothing stands out. 5.3 should become available as an update for F30 in a couple of weeks. Until then I'm afraid that sticking with a 5.1 kernel or jumping to 5.3 early by using my instructions, is the best workaround for people who are impacted by this bug.

Note the 5.3 final kernel is now also available for people who want to jump to it early:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1377932

(In reply to David Haras from comment #28)
> I have tried this on my daily driver laptop and it does cure the problem.

Thank you for trying the 5.3 kernel and for reporting back that it fixes things.

Here is a kernel build (5.2.17) with the patch that aims to solve the bug: https://koji.fedoraproject.org/koji/taskinfo?taskID=37849332

I think it'd probably be a good idea to backport it to F30 once it has received some more testing.

Running said kernel, I can no longer reproduce.

(In reply to Hans de Goede from comment #29)

(In reply to David Haras from comment #28)
> > I have tried this on my daily driver laptop and it does cure the problem.
> 
> Thank you for trying the 5.3 kernel and for reporting back that it fixes
> things.

with me it is different: 

I installed the kernel 5.3.0-1.fc31.x86_64 following Hans' instructions on my 64-bit laptop (otherwise running the lastest standard Fedora 30) and still experience the issue on that machine after installing the new kernel

on my 64-bit desktop I am running the latest standard Fedora 30 and I have installed Fedora 32 (Rawhide) and Fedora 31 (Beta) as virtual machines. in those virtual machines I did so far not have the issue - but if this means anything - I am not sure - and i need to do more testing. I do have it on the Fedora 30 desktop itself to be sure. I have not tried upgrading the kernel on this machine

for my 32-bit laptop on the latest standard Fedora 30 I think there is no other forward solution than to install another OS (for example Debian 10) which I will try next since Fedora seems to discontinue support for 32-bit starting from Fedora 31 (which will leave me stranded with the issue on that machine even if it should be fixed in Fedora 31)

(In reply to frog from comment #31)

been running the 5.3.0-1.fc31.x86_64 for hours on the 64-bit laptop without issue, so I probably saw it wrong in the beginning
installed the same on my 64-bit desktop, so far no issue
removed fedora from my 32-bit laptop and replaced with debian 10, so far so good

if it stays like this then for me the issue is closed

I have a question though. so I have now the newer kernel. what will happen if I run sudo dnf upgrade --refresh as usual on a daily basis. will that leave the new kernel in place

*** Bug 1754335 has been marked as a duplicate of this bug. ***

(In reply to Jonas Ådahl from comment #30)
> Here is a kernel build (5.2.17) with the patch that aims to solve the bug:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=37849332
> 
> I think it'd probably be a good idea to backport it to F30 once it has
> received some more testing.
> 
> Running said kernel, I can no longer reproduce.

Is this patch in the normal Fedora 5.2.17 kernel and/or will it be in the normal 5.2.18? Great work on figuring it out!

I installed 5.3.1-300 kernel and It seems that bug has been cured.

Minor issue: 
1)I have used the rpm -i command for installation of downloaded files and now I have 4 kernel instead of four. I guess that at next dnf update command two oldest kernel will be delet when installing a new kernel
2) I didn' find a kernel headers update rpm

tnx for help and work

I can conform that after updating the kernel to 5.3.0-1.fc31.x86_64 I haven't had the problem anymore.

I installed the kernel package manually with dnf. Only small problem is that if a new 5.2 kernel is published dnf update will downloaded and mark it as the default one. Just need to check when running dnf update that no new kernel is downloaded and if it is just change the GRUB default kernel back to 5.3.

(In reply to Sebastian Dato from comment #36)
> I can conform that after updating the kernel to 5.3.0-1.fc31.x86_64 I
> haven't had the problem anymore.
> 
> I installed the kernel package manually with dnf. Only small problem is that
> if a new 5.2 kernel is published dnf update will downloaded and mark it as
> the default one. Just need to check when running dnf update that no new
> kernel is downloaded and if it is just change the GRUB default kernel back
> to 5.3.

It should not the case, as in koji I assume that there will be no other 5.2.x series kernel

(In reply to antonio montagnani from comment #37)
> (In reply to Sebastian Dato from comment #36)
> > I can conform that after updating the kernel to 5.3.0-1.fc31.x86_64 I
> > haven't had the problem anymore.
> > 
> > I installed the kernel package manually with dnf. Only small problem is that
> > if a new 5.2 kernel is published dnf update will downloaded and mark it as
> > the default one. Just need to check when running dnf update that no new
> > kernel is downloaded and if it is just change the GRUB default kernel back
> > to 5.3.
> 
> It should not the case, as in koji I assume that there will be no otherkernel-5.3.1-300.fc30
> 5.2.x series kernel

Kernel 5.2.17-200.fc30.x86_64 was released a a couple of days ago and DNF will try to install it if dnf update is run, even if 5.3.0 is installed. I can see in koji that kernel kernel-5.3.1-300.fc30 is ready (I did a manual install today and so far no problems) and I assume it should be pushed shortly.

(In reply to Sebastian Dato from comment #38)
> 
> Kernel 5.2.17-200.fc30.x86_64 was released a a couple of days ago and DNF
> will try to install it if dnf update is run, even if 5.3.0 is installed. I
> can see in koji that kernel kernel-5.3.1-300.fc30 is ready (I did a manual
> install today and so far no problems) and I assume it should be pushed
> shortly.

the proof of the pudding. I was surprised to see the issue again today. then I checked and sure enough I was running 5.2.17-200.fc30.x86_64
so more evidence that 5.2 is causing it

The bug is still present on kernel-5.2.18-200.fc30.x86_64.

I used with satisfaction kernel 5.3.1 but when I use 5.3.2 bug is still here. Very important as 5.3.x kerenls will be used on 31 release

Note that there is a patch that fixes it linked to in the upstream bug report. Without that patch, it's likely not actually solved, it just happens less often.

(In reply to Jonas Ådahl from comment #42)
> Note that there is a patch that fixes it linked to in the upstream bug
> report. Without that patch, it's likely not actually solved, it just happens
> less often.

I do not think the upstream bugreport you mention has been linked to here yet (or I have read over it). I believe that you are talking about this bug report:

https://bugs.freedesktop.org/show_bug.cgi?id=111541

And specifically that this patch, which is linked from that report, should fix it:

https://patchwork.freedesktop.org/series/67000/

(In reply to Hans de Goede from comment #43)
> (In reply to Jonas Ådahl from comment #42)
> > Note that there is a patch that fixes it linked to in the upstream bug
> > report. Without that patch, it's likely not actually solved, it just happens
> > less often.
> 
> I do not think the upstream bugreport you mention has been linked to here
> yet (or I have read over it). I believe that you are talking about this bug
> report:
>

See comment 15, which was posted directly after reporting said bug.

(In reply to antonio montagnani from comment #41)
> I used with satisfaction kernel 5.3.1 but when I use 5.3.2 bug is still
> here. Very important as 5.3.x kerenls will be used on 31 release

do you know if the issue can be tested on virtual machine? because I have meanwhile both F31(Beta) and F32(Rawhide) on virtual machine running almost daily for about 2 weeks and so far no reproduction of the issue. I am stepping up the testing though. the host system is F30 on 5.3.0 (and using 5.3.0 I do not have the issue on that system)

(In reply to frog from comment #45)
> (In reply to antonio montagnani from comment #41)
> > I used with satisfaction kernel 5.3.1 but when I use 5.3.2 bug is still
> > here. Very important as 5.3.x kerenls will be used on 31 release
> 
> do you know if the issue can be tested on virtual machine? because I have
> meanwhile both F31(Beta) and F32(Rawhide) on virtual machine running almost
> daily for about 2 weeks and so far no reproduction of the issue. I am
> stepping up the testing though. the host system is F30 on 5.3.0 (and using
> 5.3.0 I do not have the issue on that system)

I have only seen the bug on a laptop, running F30 with latest updates. The hardware is an intel video card and using Wayland. If I use a different video card (anothe machine) or X.org on the same laptop, the issue does not seem to happen so I'd say it is not reproducible on a VM.

I think these issues are the same as ours:
https://bugzilla.redhat.com/show_bug.cgi?id=1747985
https://bugzilla.redhat.com/show_bug.cgi?id=1749514
so far as I can tell nobody reported it using F31 or F32. it may still be an F30/gnome/kernel combination issue

I have installed F31(Beta) on 64-bit laptop. if the issue occurs on that system I will report it here

I updated Fedora 30 today and this problem seems to be gone.

I have also an updated fedora 30 and the issue occurs again.

To test this issue, as mentioned by Chris Wilson in comment https://bugs.freedesktop.org/show_bug.cgi?id=111541#c21 , just do (as root):

echo 80 > /proc/sys/kernel/sysrq ; echo f > /proc/sysrq-trigger

in a gnome-terminal and when you move the cursor outside the window (and outside any other window) the cursor is invisible.

The issue is back today. Disregard my previous message.

(In reply to frog from comment #48)
> I have installed F31(Beta) on 64-bit laptop. if the issue occurs on that
> system I will report it here

the issue is occurring on F31(Beta) running 5.3.5-300.fc31.x86_64
I propose it should get high priority to solve it. it is basic functionality for the Fedora/Gnome/GUI and it is a regress
on F30 running 5.3.0-1.fc31.x86_64 the issue is not occurring

The patch is included in kernel release 5.4-rc3 and the upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=111541 has been closed.

See also:
* https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b925708f28c2b7a3a362d709bd7f77bc75c1daac
* https://github.com/torvalds/linux/commit/b925708f28c2b7a3a362d709bd7f77bc75c1daac

FEDORA-2019-038d78eaa5 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-038d78eaa5

FEDORA-2019-057d691fd4 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-057d691fd4

kernel-5.3.6-300.fc31, kernel-headers-5.3.6-300.fc31, kernel-tools-5.3.6-300.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-038d78eaa5

I installed 5.3.6-300.fc30 on my laptop yesterday and bug seems gone. Waiting for other confirms

kernel-5.3.6-200.fc30, kernel-headers-5.3.6-200.fc30, kernel-tools-5.3.6-200.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-057d691fd4

kernel-5.3.6-300.fc31, kernel-headers-5.3.6-300.fc31, kernel-tools-5.3.6-300.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

kernel-5.3.6-200.fc30, kernel-headers-5.3.6-200.fc30, kernel-tools-5.3.6-200.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

It looks like kernel 5.3.6-100.fc29.x86_64 fixes the problem in fedora29 too.