Mouse artifact introduced in 7/26 update

[GreyGeek]

Reported it as a bug this morning.
https://bugs.kde.org/show_bug.cgi?id=382812

Where ever the mouse is a block, about twice as wide and tall as the mouse and centered on it, appears. It blocks the content under the mouse. The mouse icon often disappears. The block is from a nearby part of the screen. This occurs on the desktop or any application. A snapshot of the mouse artifact is below:



I will wait for a few days to see if an update fixes it. If not I will be rolling back to my last snapshot.

[acheron]

I think there was an xorg update for Xenial. Could well be that?

[GreyGeek]

I think there was an xorg update for Xenial. Could well be that?

That's what Martin Floser at the bug site thinks, so I will experiment with rolling back each of the 16 xservers that were installed yesterday, rebooting, and seeing what happens.

[GreyGeek]

In checking around I found that although I have the i915 module loaded, as shown by lsmod, I found that the xserver-xorg-intel package which contains it is not installed, so I suspect one of the other 16 packages contains it. I also discovered a post by a person who had a similar problem earlier this month and he couldn't find a way to roll back. It used to be that package managers had the previous version, current version and any future version listed so that one could choose, but muon doesn't seem to have that feature. Anyway, he found a way to resolve his problem

sudo apt remove xserver-xorg-video-intel*
sudo apt install xserver-xorg-core
sudo apt install xserver-xorg-video-intel
sudo apt autoremove
sudo apt install sddm

but I doubt that I will try such an opaque solution, especially since I am running nvidia-378 and love its performance.
It's beginning to look like the best solution is to use btrfs to roll back to my 20170725 snapshots, and pin the xservvers. This box is 5 years old and this may be the beginning of age incompatibility.

[GreyGeek]

Perhaps the kernel? Muon didn't show a kernel being updated or installed since March 26th. Curious, I rebooted into my secondary kernel, 4.4.0-67-generic (my primary is 4.8.0-42-generic). Now my mouse works beautifully, and with the same updates from yesterday.

[GreyGeek]

I noticed that booting into the 4.4 kernel used the Plasma 5.10.2. I rebooted into my primary kernel, 4.8, which uses Plasma 5.10.4 and my mouse now works normally.

But, that was a warm boot from the 4.4. A cold boot may bring different results. Time will tell.


EDIT: 7/28/17
Cold booted into my primary kernel (4.8) and my mouse was misbehaving again. Warm reboot into my primary and the mouse was still misbehaving. I booted into my secondary kernel (4.4), which uses Plasma 5.10.2, and my moused worked beautifully. Then I warm booted into my primary kernel (4.8), which uses Plasma 10.4, and my mouse continued to work normally. It's only when I cold boot into my primary kernel that I get mouse problems.

[yossarianuk]

I have the exact same issue (nvidia 960M/intel hybrid GPU)

There is a simple workaround to fix this.

If you logout of Plasma, then re-login the issue goes away.

So for time being you can workaround by

- booting up neon (to sddm login)
- go to a tty (ctrl+alt+f2)
- login then use

# sudo systemctl restart sddm

- login
-> Issue has now gone until the next reboot...

I think its an Xserver issue rather than Nvidia as the older driver (which was fine is now having a same issue and the xorg version was bumped)

[acheron]

For what it's worth, I have no issue with Nvidia 381 and kernel 4.11 on artful with plasma 5.10.4, but my Neon Xenial laptop is intel only so can't test that.

[yossarianuk]

The issue seems to be with the latest xorg update or potentially sddm.

As you can see the corruption in sddm and logging into openbox also (until you restart sddm)

[GreyGeek]

The issue seems to be with the latest xorg update or potentially sddm.

As you can see the corruption in sddm and logging into openbox also (until you restart sddm)

I tracked it down to xserver-xorg-core-hwe-16.04, which was the only xserver I am running and it was updated the day the problem began. I am going to cold boot and try your work-around.

EDIT:
yossarianuk's workaround works beautifully. Thanks!

It is almost a tossup to do it manually or write a short bash script to restart sddm. One could also just use the up arrow to recall the "sudo systemctl restart sddm" command from the previous boot.

[GreyGeek]

It's been three months and this issue has not yet been resolved.
The tty tty work-a-round at the login screen
"sudo systemctl restart sddm"
continues to be the best solution, since I do not want to revert to the 4.4 kernel.