Extra cursor appears after resume (Fedora 44 Beta, ThinkPad T480, Intel graphics)

Ask Fedora
,
1

Hi all,

I’m running Fedora 44 Beta on a Lenovo ThinkPad T480 with Intel graphics.

After resuming from suspend, an extra cursor appears in the top-left corner of the screen. That behavior is consistent, since it happens every single resuming. is It’s not just a visual artifact, since the cursor actually interacts with the UI. For example, it keeps the top-left elements in a “hovered” state and changes to a spinner along with the main cursor.

I’ve already disabled all GNOME Shell extensions to rule them out, but the issue persists. Given that the extra cursor is interactive, I’m not sure this is a Shell extension problem.

Has anyone encountered something similar or have suggestions on how to debug this further? I’d appreciate any pointers on logs, tools, or components to investigate.

cursors

On the screencast, the effect is only visible on the “obs” desktop, but actually the cursor is always on screen. Maybe that might help getting some relevant information about the issue.

This is my inxi -G output

Thanks in advance.

Graphics:
Device-1: Intel Kaby Lake-R GT2 [UHD Graphics 620] driver: i915 v: kernel
Device-2: Bison SunplusIT Integrated Camera driver: uvcvideo type: USB
Display: wayland server: X.Org v: 24.1.9 with: Xwayland v: 24.1.9
compositor: gnome-shell v: 50.0 driver: X: loaded: modesetting dri: iris
gpu: i915 resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: iris,swrast
platforms: gbm,wayland,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 26.0.3
renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
Info: Tools: api: eglinfo,glxinfo x11: xdriinfo, xdpyinfo, xprop, xrandr

3

Since its a ThinkPad, Is the active cursor controlled by both the touchpad and the trackpoint after resume? Or is one of them controlling the extra pointer?

4

Does it ONLY appear after resume?
Does it vanish after locking the screen and unlocking?
Does it vanish after changing desktop wallpaper?

Sounds like the i915 driver is not clearing all of the framebuffer upon resume. You could try its replacement, the Xe driver. It’s still in development so YMMV but it’s intended to be the replacement for i915.

5

If the cursor is being updated and interacts with the UI, then that pretty much rules out the framebuffer (and probably the graphics stack as a whole)

6

Ah - my bad - I missed that sentence in the description - distracted by the video. I assumed it was just a ghost sitting there constantly.

7

do you see any difference in output of sudo libinput list-devices collected before and after the suspend / resume cycle?

you could also run sudo libinput debug-events. It shows devices added and other events.

8

Hi!, thanks people!. @anotheruser, did it and figured out that the issue is related to a veikk pen tablet driver. It apears to only affect i915, since I also run f44 beta on a desktop with an AMD RX 570, and seems to be working just fine.