Giant, inaccurate mouse cursor on Wayland when using high DPI

Issue Type: Bug

This issue has happened occasionally in the past, but I could just close and reopen Code and it would go away. Now it is happening 99% of the time. I have seen other people mention the same issue in the comments on other issues, but I could not find an issue that was specifically created for it.

The mouse cursor appears to be double its normal size, and the point where a click operation actually occurs is inconsistent and often far off from where one would expect it to be in relation to the cursor. For example, when you click with the cursor between two characters, the caret might jump to the line above and 2 characters to the left of where you clicked - or maybe it’s on the right line and just 1 character off; it’s very inconsistent.

Every once in a while, there are certain areas where the cursor will return to its normal size while I am hovering over them. I’ve noticed this happen occasionally while hovering over the explorer pane or the open tabs bar, but it is rare that it happens at all.

I also noticed that sometimes when I open a second window, the cursor goes to the correct size in both windows, but when I close the second window it reverts to double-size in the original window. Very strange.

This occurs on Arch Linux. I am using Gnome, but I had the exact same issue in a Plasma environment as well. I have tried the latest versions of the open source build, the Microsoft branded release, and Insiders. The problem exists on all of them. It also does not make any difference which cursor theme I am using.

I have multiple monitors and only one of them is high DPI. If I drag the window to a normal DPI monitor, the cursor appears normal. The issue occurs on the high DPI monitor regardless of the amount of scaling (except at 100% of course) - I have tested at 125%, 150%, and 200% and had the same problem on all, so it doesn’t appear to be related to fractional scaling. It is also worth noting that the scaling of the cursor doesn’t seem to match the display scaling - it looks like it’s always double size.

As a workaround, I can fiddle with the --force-device-scale-factor argument and the zoom setting, and get a combination that works OK. But that only takes care of the cursor size, not the accuracy issue, and in that 1% of the time that the cursor renders correctly, it becomes tiny when using the workaround.

These issues do not occur if I don’t start Code with the ozone options, but then of course it uses raster scaling resulting in blurry text.

VS Code version: Code - Insiders 1.62.0-insider (b3318bc0524af3d74034b8bb8a64df0ccf35549a, 2021-11-03T13:18:48.802Z) OS version: Linux x64 5.14.15-arch1-1 Restricted Mode: No

System Info

Item	Value
CPUs	AMD Ryzen 7 2700X Eight-Core Processor (16 x 3200)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	0, 0, 1
Memory (System)	31.28GB (15.66GB free)
Process Argv	–enable-features=UseOzonePlatform --ozone-platform=wayland --crash-reporter-id 60cb16e3-b07c-417c-9de0-aab704011725
Screen Reader	no
VM	0%
DESKTOP_SESSION	gnome
XDG_CURRENT_DESKTOP	GNOME
XDG_SESSION_DESKTOP	gnome
XDG_SESSION_TYPE	wayland

[xsrvmy]

I have an interesting observation actually: I am using sway, and there is some glitch with my cursor that makes it sometimes use my cursor theme set in KDE (breeze), and sometimes the default black cursor. In chrome, the cursor is regular sized and changes to breeze. In vscode, the cursor stays black and is very big.

[KucharczykL]

Seems to be fixed on my end.