Repository: vscode
Issue: Giant, inaccurate mouse cursor on Wayland when using high DPI
Labels: bug,upstream,electron,confirmation-pending,wayland,multi-monitor


Issue Type: <b>Bug</b>

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

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 7 2700X Eight-Core Processor (16 x 3200)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: disabled_off<br>opengl: enabled_on<br>rasterization: disabled_software<br>skia_renderer: enabled_on<br>video_decode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>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|
</details>
<!-- generated by issue reporter -->