Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Giant, inaccurate mouse cursor on Wayland when using high DPI #136390

Open
jeremy-wolfe opened this issue Nov 3, 2021 · 16 comments
Open

Giant, inaccurate mouse cursor on Wayland when using high DPI #136390

jeremy-wolfe opened this issue Nov 3, 2021 · 16 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug confirmation-pending electron Issues and items related to Electron multi-monitor Issues with multiple display setups upstream Issue identified as 'upstream' component related (exists outside of VS Code) wayland Issue related to wayland display server

Comments

@jeremy-wolfe
Copy link

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 (b3318bc, 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
@Tyriar Tyriar assigned deepak1556 and unassigned Tyriar Nov 5, 2021
@smasher164
Copy link
Member

I noticed that today, the Chromium bug tracker marked the umbrella issue for wayland cursor bugs as fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=928274.

@xsrvmy
Copy link

xsrvmy commented Jan 23, 2022

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.

@markbaas
Copy link

markbaas commented Feb 2, 2022

It's probably related to electron/electron#11050

Also it happens on X11. Vscode needs to upgrade to electron 17 and it's fixed.

@edrex
Copy link

edrex commented Jun 14, 2022

In my testing cursor scaling on HiDPI outputs under native wayland appears to work correctly with the latest electron 18 based insider build (see #148507 (comment)), so I believe this is fixed.

@FossPrime
Copy link

FossPrime commented Sep 12, 2022

This exact issue also happens on 14" 1080p Chromebooks out of the box. They come set to 125% display scaling. They are running Chrome 105.

When running apps like Firefox and Microsoft Edge, they run under Wayland, so the issue would manifest there too.

The issue also affects GitHub's GitHub.dev and Code Spaces🌍

Scaling down to 100% works, bit is very tiny. 200% is not a reasonable option.

Screenshot 2022-09-09 11 04 08

@deepak1556
Copy link
Contributor

Is this present with latest stable 1.73 when launching with --enable-features=WaylandWindowDecorations --ozone-platform=wayland ?

@deepak1556 deepak1556 added the info-needed Issue requires more information from poster label Dec 7, 2022
@KucharczykL
Copy link

Seems to be fixed on my end.

@ozls
Copy link

ozls commented Jan 6, 2023

Not fixed on my end, on Wayland and using Code 1.74.2 with Electron 19.1, also with scaling set to 125%

@deepak1556
Copy link
Contributor

@ozls are you launching vscode with the flags mentioned in #136390 (comment) ?

@ozls
Copy link

ozls commented Jan 10, 2023

Yes. Additional info : seems to only happen when I run two vscode windows on two different monitors, an unscaled one and a scaled one (namely my 1080 laptop screen scaled 100% and my 4k external monitor scaled 125%)

@deepak1556 deepak1556 added upstream Issue identified as 'upstream' component related (exists outside of VS Code) electron Issues and items related to Electron confirmation-pending wayland Issue related to wayland display server multi-monitor Issues with multiple display setups bug Issue identified by VS Code Team member as probable bug and removed info-needed Issue requires more information from poster labels Jan 10, 2023
@NVolcz
Copy link

NVolcz commented Feb 9, 2023

The options mentioned in #136390 (comment) fixes this issue for me but vscode is now blurry on my laptop screen (3456x2160 + 200% scaled) but looks good on my external monitor (3440x1440, 100% scaled).

Edit: Using fractional scaling doesn't seem to help.

@iskrisis
Copy link

iskrisis commented Aug 7, 2023

This still happens on wayland with multi-monitors with different resolutions and fractional scaling. I have two screens 1920x1080 and 3840x2160 and no matter on which screen the cursor is in VSCode its giant.

@olafurw
Copy link

olafurw commented Aug 18, 2023

Fedora 38. Just added a 3rd monitor and if the main monitor uses 200% scaling then it doesn't matter what other monitor VSCode is on (or what their scaling setting is), the mouse cursor is huge.

If I set all monitors to 100% scaling then the cursor behaves correctly.

@la3rence
Copy link

Ubuntu 22. 200% scaling with retina display running in a VM on macOS. Resolution 3360x2100.
This issue seems happen in many apps like the built-in Terminal, Firefox and VS Code.

@wangwillian0
Copy link

For those using KDE, going to the SDDM settings and clicking "Apply Plasma Settings" solved this issue for me.

@Firestar-Reimu
Copy link

Firestar-Reimu commented Mar 26, 2024

屏幕截图_20240326_202152
屏幕截图_20240326_202143

same problem, but my cursor is very tiny when the cursor is in vscode

KDE Plasma 6.0 with wayland and vscode 1.87.2

2560x1440 screen, 200% scaling.

default is /usr/bin/code --unity-launch, --enable-features=WaylandWindowDecorations --ozone-platform=wayland can solve this problem, or delete the --unity-launch option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue identified by VS Code Team member as probable bug confirmation-pending electron Issues and items related to Electron multi-monitor Issues with multiple display setups upstream Issue identified as 'upstream' component related (exists outside of VS Code) wayland Issue related to wayland display server
Projects
None yet
Development

No branches or pull requests