flickering KDE mouse cursor with background anomalies

English Applications
1

I have a system running Leap 15.4 with all current online updates. Until the most recent updates from a couple of days ago, the KDE/plasma/X11 desktop was working with no apparent problems. However, since these updates, the mouse cursor now flickers when moved over certain areas of the screen. It also sometimes shows a anomalous square background behind the cursor area, showing a different content and color than the actual background there, and that square also flickers. It’s not fatal but extremely annoying.

Here is a very short video illustrating the problem.
[video]http://www.tikan.org/ti/misc/cursor_flicker.mov[/video]

More background info about the system - based on a Asrock 970M Pro3 motherboard with an AMD FX6300 6-core 64bit processor. The motherboard has no onboard video, so a EVGA 02G-P3-1733-KR video card is installed (based on NVIDIA GeForce GT730), with a Acer G257HU 25" LCD monitor. The system has the latest NVIDIA legacy drivers 470.141.03 installed.

Interestingly, prior to the most recent updates, the screen resolution was 2560x1440. After the updates it definitely increased visually, but the “Configure Display Settings” window still shows 2560x1440, yet the “xdpyinfo” command shows 5120x1440, which is obviously not correct, because the resolution definitely did not become double in the horizontal direction, but it did increase in the vertical direction.

Anyway, any hints about what’s causing this behavior and how to fix it?

2

I’d start by switching composite on/off or other composite options (scale method, latency, etc.). You may be able to narrow down the problem reason this way.

3

Thanks, but I tried disabling compositing, logged out and back in again, and the problem persists.
Configure Display Settings > Compositor > Enable on Startup = unchecked.
Applied the setting, logged out and back in.

The flickering mouse cursor doesn’t happen everywhere, but when hovering over buttons and menus, desktop icons, etc., it will flicker. Also, when clicking on a menu entry (such as the KDE Application Menu), when the mouse cursor is over a submenu entry, a square area behind the cursor appears, usually white. Moving the cursor makes the square disappear, or appear again in a differnet place.

Any more ideas?

4

I am unable to reproduce:

# inxi -GSaz --vs
inxi 3.3.20-00 (2022-07-27)
System:
  Kernel: 5.14.21-150400.24.18-default arch: x86_64 bits: 64 compiler: gcc
    v: 7.5.0 parameters: root=LABEL=<filter> ipv6.disable=1 net.ifnames=0
    noresume mitigations=auto consoleblank=0
  **Desktop: KDE Plasma v: 5.24.4** tk: Qt v: 5.15.2 wm: kwin_x11 vt: 7 dm:
    1: TDM 2: XDM Distro: openSUSE **Leap 15.4**
Graphics:
  **Device**-1: NVIDIA GF108 **GeForce GT 630**] vendor: Gigabyte **driver: nouveau**
    v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022)
    arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1
    speed: 2.5 GT/s lanes: 16 ports: active: DVI-I-1,HDMI-A-1 empty: VGA-1
    bus-ID: 01:00.0 chip-ID: 10de:0f00 class-ID: 0300
  **Display: x11 server: X.Org** v: 1.20.3 compositor: kwin_x11 **driver: X:
    loaded: modesetting** unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
    gpu: nouveau display-ID: :0 screens: 1
  **Screen**-1: 0 s-res: **3600x1200** s-dpi: 120 s-size: 762x254mm (30.00x10.00")
    s-diag: 803mm (31.62")
  **Monitor-1**: DVI-I-1 pos: right model: Dell P2213 serial: <filter>
    built: 2013 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
    size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
    max: 1680x1050 min: 720x400
  **Monitor-2**: HDMI-A-1 mapped: HDMI-1 pos: primary,left model: NEC EA243WM
    serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
    size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
    max: 1920x1200 min: 640x480
  OpenGL: renderer: NVC1 v: 4.3 Mesa 21.2.4 direct render: Yes

Before starting Plasma, I removed most of its settings from ~/.config/, and the entirety of ~/.cache/. Most of what I did in the session involved changing default settings back to my own preferences, but opened Firefox ESR 102 briefly too.

What does inxi -Gaz report?

Slim possibility of helpfulness: if using SDDM, use update-alternatives --config default-displaymanager to switch to LightDM, or vice versa.

cf. this.

5

Works with nouveau? Then it could be a regression introduced with a newer kernel, or something similar. Maybe try to boot to the previous kernel.

6

I haven’t tried changing back to nouveau, but I did try booting the previous kernel, and the same problem occurred. So it doesn’t seem to be a kernel issue.

7

@mrmazda

$ inxi -GSaz
System:
Kernel: 5.14.21-150400.24.18-default x86_64 bits: 64 compiler: gcc
v: 7.5.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150400.24.18-default
root=UUID=d9e4017d-9c70-4e34-944c-ebfdc0805275
resume=/dev/disk/by-uuid/0876c0a3-e28c-479b-aa80-f69fb1572ccc showopts
splash=silent preempt=full quiet mitigations=auto security=apparmor
Desktop: KDE Plasma 5.24.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7
dm: GDM 41.3, SDDM Distro: openSUSE Leap 15.4
Graphics:
Device-1: NVIDIA GK208B [GeForce GT 730] vendor: eVga.com. driver: nvidia
v: 470.141.03 alternate: nouveau,nvidia_drm bus-ID: 01:00.0
chip-ID: 10de:1287 class-ID: 0300
Device-2: Logitech Webcam C600 type: USB driver: snd-usb-audio,uvcvideo
bus-ID: 1-3:4 chip-ID: 046d:0808 class-ID: 0102 serial: <filter>
Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver:
loaded: modesetting,nvidia display-ID: :0 screens: 1
Screen-1: 0 s-res: 5120x1440 s-dpi: 96 s-size: 1355x381mm (53.3x15.0")
s-diag: 1408mm (55.4")
Monitor-1: DVI-D-0 res: 2560x1440 hz: 60 dpi: 118
size: 552x311mm (21.7x12.2") diag: 634mm (24.9")
OpenGL: renderer: NVIDIA GeForce GT 730/PCIe/SSE2
v: 4.6.0 NVIDIA 470.141.03 direct render: Yes

8

Please visit this howto before pasting command output in the forum again.

Does removing preempt=full from your Grub linu line have any effect on the issue?

Are you able to reproduce the problem in an IceWM session (instead of Plasma)?

Did you try update-alternatives as suggested?

I don’t understand

the screen resolution was 2560x1440. After the updates it definitely increased visually
Visually increased how? Are circles now appearing as ovals? Are fonts appearing horizontally squished?

I suspect whatever is causing the horizontal display resolution report doubling by xdpyinfo and inxi is related to the cursor behavior, likely a bug in need of reporting.

9

Oops sorry.

Does removing preempt=full from your Grub linu line have any effect on the issue?

I don’t know yet, I’ll have to try this next time I reboot, currently the system is busy doing some number crunching so it’s not a good time to do that. But I believe preempt=full is about process scheduling, and shouldn’t affect the X11 display or mouse cursor.

Are you able to reproduce the problem in an IceWM session (instead of Plasma)?

Not yet, same reason as above, I’ll have to wait for a good opportunity to log out and restart the X11 session.

Did you try update-alternatives as suggested?

Not yet for the same reason. Also, my current setting is “gdm (auto mode)” not sddm.

I don’t understandVisually increased how? Are circles now appearing as ovals? Are fonts appearing horizontally squished?

Circles are perfectly round and text is not squished.

I have three gkrellm windows stacked vertically on the right side of the screen. Before the updates, those three windows just fit the entire top-to-bottom of the screen with no space between the bottom window and the task bar. Now, there is some space, so there are more pixels in the vertical direction. I believe there are also more pixels horizontally, because text now look smaller than before (for example, the icon titles and menu titles got smaller, such that I had to increase their font sizes to make them look like before.

Another new bit of information that might be useful: I ran x11vnc on that display, and then used vncviewer to connect to it from another system (also Leap 15.4 but different hardware, and does not exhibit the mouser cursor problem). The same mouse cursor flickering and background square anomaly happens in the vncviewer window (showing the original system’s X11 display content), but not elsewhere. Does this help identify where the problem may be? It seems that a VNC connection would “bypass” the original system’s video driver, so the problem isn’t in the nvidia proprietary driver?

10

Correction: Under VNC, the mouse cursor does NOT flicker. But the background square anomaly under the cursor DOES occur.

11

Update: I was able to schedule a system reboot, so I removed the kernel command line option preempt=full and restarted the system Guess what, that completey solved the problems! While still using gdm, the cursor no longer flickers anywhere. And there is no more transient garbage square under the cursor. I tested with the mouse cursor oing over various icons, menus, buttons, on web browser content (both Firefox an Chrome).

I tried changing the displaymanager from gdm to lightDM, and it made no difference. Should I even see anything different with lightdm rather than gdm? Anyway, there were no problems with the mouse cursor in this setting either.

I then switched back to gdm, and re-enabled compositing, then I logged out and back again. No problem with the mouse cursor!

At this point I guess I consider the problem “solved”, even though I don’t know why removing the preempt=full kernel command line made a difference. It seems Leap 15.4 adds this option by default, it’s on all four of the Leap 15.4 systems I have here. Yet preemmpt=full does not cause any apparent problems on all the other systems. Just this particular one.

Oh, and I “kind of” figured out why the X display resolution was listed as 5120x1440 but the physical screen resolution is 2560x1440. It seems that the X server allocated a much wider display than the screen itself. There is actually more display area beyond the right side edge. You can see this in the vncviewer, where tht right side is just a block area beyond 2560 pixels. It turns out that something caused the system to run nvidia-xconfig (maybe during an update), and generated a new /etc/X11/xorg.conf file. If I restore the old xorg.conf and restart the X session, then I get the following:

xdpyinfo output:

...
  screen #0:
  dimensions:    2560x1440 pixels (677x381 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
...

inxi -GSaz output:

System:
  Kernel: 5.14.21-150400.24.18-default x86_64 bits: 64 compiler: gcc
  v: 7.5.0
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.14.21-150400.24.18-default
  root=UUID=d9e4017d-9c70-4e34-944c-ebfdc0805275
  resume=/dev/disk/by-uuid/0876c0a3-e28c-479b-aa80-f69fb1572ccc showopts
  splash=silent quiet mitigations=auto security=apparmor
  Desktop: KDE Plasma 5.24.4 tk: Qt 5.15.2 wm: kwin_x11 vt: 7
  dm: GDM 41.3, SDDM Distro: openSUSE Leap 15.4
Graphics:
  Device-1: NVIDIA GK208B [GeForce GT 730] vendor: eVga.com. driver: nvidia
  v: 470.141.03 alternate: nouveau,nvidia_drm bus-ID: 01:00.0
  chip-ID: 10de:1287 class-ID: 0300
  Device-2: Logitech Webcam C600 type: USB driver: snd-usb-audio,uvcvideo
  bus-ID: 1-3:4 chip-ID: 046d:0808 class-ID: 0102 serial: <filter>
  Display: x11 server: X.Org 1.20.3 compositor: kwin_x11 driver:
  loaded: modesetting unloaded: fbdev,vesa,vmware alternate: vboxvideo
  display-ID: :0 screens: 1
  Screen-1: 0 s-res: 2560x1440 s-dpi: 96 s-size: 677x381mm (26.7x15.0")
  s-diag: 777mm (30.6")
  Monitor-1: DVI-D-1 res: 2560x1440 hz: 60 dpi: 118
  size: 552x311mm (21.7x12.2") diag: 634mm (24.9")
  OpenGL: renderer: llvmpipe (LLVM 11.0.1 256 bits) v: 4.5 Mesa 21.2.4
  compat-v: 3.1 direct render: Yes

Note that the line “Screen-1: 0 s-res: 2560x1440” rather than “Screen-1: 0 s-res: 5120x1440” shown before.

Any comments about these findings?

12

IMHO someone had added kernel parameter ‘preempt=full’ manually.
Nvidia proprietary drivers are not compatible with preempt kernel. Possibly someone can compile open Nvidia drivers manually with that support, but they’re available only for Turing GPUs and newer.

13

“Made no difference” and “no problems” contradict each other here; and no, you should not see anything different, unless possibly there’s a bug involved.

preemmpt=full does not cause any apparent problems on all the other systems. Just this particular one.
Are all the others using proprietary NVidia drivers too?

14

Hmm, interesting. I don’t know how the preempt=full got in there then.

Nvidia proprietary drivers are not compatible with preempt kernel.

Is this true of ALL nvidia proprietary drivers? I have another Leap 15.4 system (a Lenovo laptop) with a newer nvidia chip and running the nvidiaG06 proprietary drivers. It also has preempt=full on the kernel command line, but it exhibits no mouse cursor or other X display issues…

15

“Made no difference” means I didn’t see any change in looks or behavior when I switched from gdm to lightDM. Without preempt=full, no mouse cursor related issues were observed with either displaymanagers, therefore “no problems”.
See, they are not contradictory.

Are all the others using proprietary NVidia drivers too?

See my post above. I have another Leap 15.4 system running the nvidia proprietary driver (the nvidiaG06) and with preempt=full. No mouse cursor anomalies are observed on that machine.

16

Really IDK, it needs tests.
Someone had troubles with RT kernels.
I had troubles with preempt kernel and network card drivers.

17

I was assuming you didn’t keep preempt=full. The tests I suggested were meant to be tried independent of each other, not stacked after another already worked. So I assumed that’s what you meant you did.