Native wayland support with newest electron

[toger5]

Native wayland support would be great to run vs code without XWayland as described in https://github.com/microsoft/vscode/issues/77752.

Recently electron merged the chrome version with the ozone backend needed: https://github.com/electron/electron/pull/26022

This would allow for:

• Kinetic scrolling (maybe this is more elegantly implemented on the elctron side)
• Better touch support (touch scrolling)
• better dpi scaling

[Maia-Everett]

Answering a question from #135696:

Does it work when you launch with --enable-features=UseOzonePlatform --ozone-platform=wayland

Just checked. It works with three caveats.

1. I have the custom title bar enabled, and it works correctly under KDE X11, but under KDE Wayland, VS Code has both standard KWin window decorations and its own custom window decorations.
2. Cursor settings are not respected. VS Code uses the default dark KDE cursor theme even though I have the light one set in system settings.
3. This one, unfortunately, is the show stopper. Editor window rendering under KDE Wayland feels slow and sluggish and has tearing when scrolling. Under X11, editor windows are blazing fast.

[paulcarroty]

The 3rd^ probably somehow related to KDE itself 'cause there's no tearing/slow rendering on GNOME Wayland.

[mystiquewolf]

1. This has already been fixed upstream, probably some time next year will reach stable.
2. File a bug at https://bugs.kde.org/
3. Might be https://github.com/microsoft/vscode/issues/125402, who knows...

[darkbasic]

That's weird, I use code-oss every day on my KDE Plasma (Wayland + HiDPI) and it works like a charm (Arch Linux).

[mcilloni]

On the other hand - in KDE with VS Code custom titlebar you get two titlebars, so you have to use the System one, no matter whether you prefer to use the custom one.

I managed to get rid of KWin window titlebars using the following rule:

I have used it a bit and it seems like it works fine, no real issues for now. It's still less than ideal though, so let's hope Electron is going to fix the whole CSD situation.

[ZZYSonny]

On the other hand - in KDE with VS Code custom titlebar you get two titlebars, so you have to use the System one, no matter whether you prefer to use the custom one.

I managed to get rid of KWin window titlebars using the following rule:

I have used it a bit and it seems like it works fine, no real issues for now. It's still less than ideal though, so let's hope Electron is going to fix the whole CSD situation.

I think a better way to do this is to set this in window decoration. Using your fix there is no window shadow, which is inconsistent with other windows. //For some reason I cannot use Window ClassName for the rule, maybe a kwin bug?

[Austaras]

Chrome 97 has been stablized in 1.5, and IBus works fine in native Wayland. How long will vscode take to adopt this fix?

[jgcodes2020]

2. Cursor settings are not respected. VS Code uses the default dark KDE cursor theme even though I have the light one set in system settings.

This isn't a KDE-specific issue, I use GNOME 40, and it too uses the default cursor theme. I had to change some configuration files to get it to stick with the cursor I want it to use.

[mrksr]

@jgcodes2020 That's great to hear! Could you describe (or point to a description of) the changes you had to make? :)

[jgcodes2020]

@mrksr It should be noted that the default cursor problem is not just specific to VSCode. My workaround was to override the default cursor theme. Put the following in ~/.icons/default/index.theme:

[icon theme]
Inherits=<your theme>

Alternatively, this background script can be used on GNOME (sed -u is not POSIX though):

#!/bin/sh
gsettings monitor 'org.gnome.desktop.interface' cursor-theme | sed -Eue "s/^cursor-theme: '(.+?)'\$/\\1/g" | while IFS= read -r line; do
cat << {END_OF_FILE} > ~/.icons/default/index.theme
[icon theme]
Inherits=$line
{END_OF_FILE}
done

VSCode won't update the cursor live, but it will use the correct cursor theme on startup.

[ultimaweapon]

I'm feeling a mouse coordinate inside a file explorer is slightly incorrect when hover on a file. Does anybody have this problem?

[jmariondev]

@ultimaweapon I notice the mouse cursor position is "off" throughout the entire UI (including the editor).

[mystiquewolf]

@ultimaweapon I notice the mouse cursor position is "off" throughout the entire UI (including the editor).

I think i don't have this issue.

[ianhattendorf]

@ultimaweapon I notice the mouse cursor position is "off" throughout the entire UI (including the editor).

I think i don't have this issue.

I noticed this, specifically when trying to resize the left panel. I need to click to the left of the divider by ~5px instead of right on it.

Fedora 35/Gnome 41.3/code 1.64.0

[mystiquewolf]

Don;t experience this, code 1.64.0, KDE 5.23.5

[mattpepin-funeraweb]

@ultimaweapon I notice the mouse cursor position is "off" throughout the entire UI (including the editor).

Same, but in the most recent stable, it's now OK in the editor. Still happens in the left panel though. I'm using HiDPI scaling, that's probably what's causing it.

[eternal-sorrow]

Same, but in the most recent stable, it's now OK in the editor. Still happens in the left panel though. I'm using HiDPI scaling, that's probably what's causing it.

I'm not using scaling, but I'm still having it.

[C0rn3j]

Seems like the support for automatic wayland detection to launch with equivalent of --enable-features=UseOzonePlatform --ozone-platform=wayland flags has been merged few months ago and therefore should be included since around electron 16 release (2021-11-16).

VSC switch to electron 16 was merged a few days ago https://github.com/microsoft/vscode/pull/137241, so hopefully no more fiddling flags on every launch whenever next release 1.65.0 hits!

EDIT: Actually VSC would also have to add the --ozone-platform-hint=auto auto value as default I believe

[jcdickinson]

Edit: for a window chrome under Gnome 40, see this comment: https://github.com/microsoft/vscode/issues/109176#issuecomment-1069111278

[RicArch97]

Unfortunately there is a bug in chromium 97 (used by electron 16) which causes a crash when using wlroots 0.15.x, this was fixed in chromium 98, which means an upgrade to electron 17 would be necessary to use the wayland backend

[iMonZ]

Under Gnome 40, I am finding that there is no default window chrome. I had to add this to my settings:

"window.titleBarStyle": "native"

Where do you put that?

[jcdickinson]

Under Gnome 40, I am finding that there is no default window chrome. I had to add this to my settings:

"window.titleBarStyle": "native"

Where do you put that?

In your vscode settings JSON.

[lrazovic]

Unfortunately there is a bug in chromium 97 (used by electron 16) which causes a crash when using wlroots 0.15.x, this was fixed in chromium 98, which means an upgrade to electron 17 would be necessary to use the wayland backend

Electron devs are trying (with several problems) to backport the patch on Electron 16 as well. Perhaps we should wait for further developments and unfortunately go back to the previous version of sway/wlroots.

• https://github.com/electron/electron/issues/32487#issuecomment-1018848455
• https://github.com/electron/electron/pull/32603

[darkbasic]

Unfortunately there is a bug in chromium 97 (used by electron 16)

Electron 16 is based on Chromium 96, not 97.

[HubKing]

Seems like the support for automatic wayland detection to launch with equivalent of --enable-features=UseOzonePlatform --ozone-platform=wayland flags has been merged few months ago and therefore should be included since around electron 16 release (2021-11-16).

Has it actually been added? I installed the "insider" version on Linux (Manjaro, Gnome, Wayland) and the text is still blurry with fractional scaling. I tried to pass those arguments, but I got:

Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium. Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.

Here is the information of my VSCode:

Version: 1.66.0-insider Commit: 6b7453421201c888b81eae5c04ec822a6423608f Date: 2022-03-11T06:27:47.212Z Electron: 17.1.1 Chromium: 98.0.4758.109 Node.js: 16.13.0 V8: 9.8.177.11-electron.0 OS: Linux x64 5.15.25-1-MANJARO

[IzhakJakov]

Working for me. How are you invoking code?

[IzhakJakov]

@HubKing ⬆️

[thblckjkr]

I just tried to launch vscode-insiders like this, and it apparently doesn't work.

$ code-insiders -v 
1.66.0-insider
3e5c7e2c570a729e664253baceaf443b69e82da6
x64

$ code-insiders --enable-features=UseOzonePlatform --ozone-platform=wayland
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
# Does not launch vscode

$ code-insiders --ozone-platform=wayland
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
# Does not launch vscode

$ code-insiders --enable-features=UseOzonePlatform
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
# Launches it, but it's under xorg/xwayland (it is detected by xeyes).

[IzhakJakov]

Oh you are trying to use code-insiders. I am just using code-oss. code --enable-features=UseOzonePlatform --ozone-platform=wayland worked for me. code is a softlink to code-oss which is an invoker to an unbranded version of vscode. https://wiki.archlinux.org/title/Visual_Studio_Code.

---

What happens if you add the followings:

--enable-features=UseOzonePlatform
--ozone-platform=wayland

to ~/.config/electron-flags.conf as described in this document?

That worked for me but I had to use ~/.config/electron13-flags.conf which is described in this document as well.

[IzhakJakov]

code-insiders is essentially an invoker for $VSCODE_PATH/resources/app/out/cli.js You can try adding --enable-features=UseOzonePlatform --ozone-platform=wayland directly to: https://github.com/microsoft/vscode/blob/037fd05f03db027dc2ac7517e71ac4a952fd374c/resources/linux/bin/code.sh#L53 and see what happens.

[thblckjkr]

I added the flags to /usr/bin/code-insiders and the line ended up looking ike this:

ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --ms-enable-electron-run-as-node "$@" --enable-features=UseOzonePlatform --ozone-platform=wayland

The output was the same (flags not recognized) and the program failed to start.

If I try to run the binary directly, it still fails, but now it says: segmentation fault.

$ /opt/visual-studio-code-insiders/code-insiders --ozone-platform=wayland
[14304:0315/122951.408013:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is 
[14304:0315/122951.411317:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
[0315/122951.464512:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0315/122951.483451:ERROR:directory_reader_posix.cc(42)] opendir /home/thblckjkr/.config/Code - Insiders/Crashpad/attachments/1afec696-1873-45a6-aedc-cda4c093efb9: No such file or directory (2)
Segmentation fault (core dumped)

I also added the flags on the ~/.config/electron-flags.conf file, but it looks like it isn't recognized and loaded on my installation.

[IzhakJakov]

I just ran:

❯ ELECTRON_RUN_AS_NODE=1 electron13 /usr/lib/code/out/cli.js /usr/lib/code/code.js --enable-features=UseOzonePlatform --ozone-platform=wayland
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.

And confirmed that although I get this warning. code is indeed running in wayland. I can easily tell because xwayland does not respect my dark theme. Also I am using a 4k monitor and code on xwayland is pixelated very badly. So when I run code with --enable-features=UseOzonePlatform --ozone-platform=wayland, it's using wayland and when I don't it is using xwayland

wayland on the right VS xwayland on the left

Another way to find out if the program you are running is wayland or not is to simply stop xwayland and if you can not click on anything in some app, that app is xwayland. You can re-enable xwayland and everything you click should work again.

Try that on your code-insiders

---

One interesting thing I found out is that while you do not need xwayland for code to be running if it was invoked with --enable-features=UseOzonePlatform --ozone-platform=wayland, you still need it to be running when you start code[^1]. I hope this is something that would be fixed in the future.

[^1]: If you start code with --enable-features=UseOzonePlatform --ozone-platform=wayland, you can close xwayland afterwards.

[HubKing]

@HubKing arrow_up

I am using (Gnome) Manjaro. The version in the official repository is Code OSS. That thing did not start if I pass those flags.

The version in in AUR, seems to use Wayland if I pass those flags, because the text does not look blurry, but it has no window decoration, so I cannot drag the window.

Also, it seems to be using Electron 13. I have manually installed the latest Electron, whose version seems to be 17, and it looks crisp text. I want to try "ELECTRON_RUN_AS_NODE=1 electron /usr/lib/code/out/cli.js /usr/lib/code/code.js ...." but there are no such files. I only see "/opt/visual-studio-code", and it has "cli.js", but no "code.js". It has "code", but its size is 130MB, so it probably is not a JS file.

[IzhakJakov]

I am using (Gnome) Manjaro. The version in the official repository is Code OSS. That thing did not start if I pass those flags.

Hmm... I wonder how you called it because it works for me on sway.

---

seems to use Wayland if I pass those flags, because the text does not look blurry, but it has no window decoration, so I cannot drag the window.

According to this document on Gnome you might need additional feature to enable window decorations on wayland:

--enable-features=UseOzonePlatform,WaylandWindowDecorations

BTW, unless you change the default keybindings for Gnome, you should be able to move the window by holding + (I am not sure which mouse button)

[abraxxa]

Adding on the cli works for me on Ubuntu 21.10 with sway, in ~/.config/electron-flags.conf and ~/.config/electron13-flags.conf doesn't. XDG_CONFIG_HOME isn't set by sway, not sure if that makes a difference.

[nkia-christoph]

According to this document on Gnome you might need additional feature to enable window decorations on wayland

Alternatively you can use the custom title bar. Works well for me on Pop!_OS and also saves some vertical space.

[rstrube]

VSCode 1.66 just hit stable for Arch, and after upgrading to 1.66 I can no longer run VSCode as a native wayland application. There must be a regression issue. Previously I code run: code --enable-features=UseOzonePlatform --ozone-platform=wayland or simply setup ~/.config/code-flags.conf with:

--enable-features=UseOzonePlatform
--ozone-platform=wayland

And it would run as a native wayland application.

When I try to do this with 1.66, the application fails to start.

I can still run it just fine as an XWayland application.

Note: you can run xlsclients to see any applications that are running under XWayland.

[RicArch97]

Since Chromium 97, enabling the Wayland backend only requires the --ozone-platform-hint=auto flag, which then automatically detects Wayland if you're using it. VSCode should be on Chromium 98 now so you can use that instead.

(this has nothing to do with the comment above)

[rstrube]

Since Chromium 97, enabling the Wayland backend only requires the --ozone-platform-hint=auto flag, which then automatically detects Wayland if you're using it. VSCode should be on Chromium 98 now so you can use that instead.

(this has nothing to do with the comment above)

I've tried that, and it didn't seem to work (even before the hard crash now with VSCode 1.66). I'm not sure if it's because VSCode is still using an older version of electron? You're correct that it does work for Google Chrome. In fact I do have the following in my ~/.config/chrome-flags.conf

--enable-features=WebRTCPipeWireCapturer
--ozone-platform-hint=auto

It it works fine for Chrome.

Edit: continued... But this does not appear to work for VSCode.

[rstrube]

I wanted to provide a coredump of the crash that is occurring with VSCode 1.66 when attempting to run it as a native wayland application. I'm not sure if this will help or not.

Based on this thread it seemed that there was a regression introduced with 1.66 (which people using code-insiders started to notice). Now that 1.66 is stable this same problem is affecting everyone.

vscode_1.66.coredump.txt

[oscarkey]

I'm also hitting this as of 1.66. Seems like it's probably the same issue as being discussed here? https://github.com/microsoft/vscode/issues/146349

[paolomainardi]

I don't know if has already been said, but also Chrome updated yesterday on Arch - Version 100.0.4896.60 (Official Build) (64-bit) - is broken with Wayland now.

[bacteriostat]

Electron17 is now updated to 17.3.1. Now I am able to launch code under wayland with code --enable-features=UseOzonePlatform --ozone-platform=wayland. But the --ozone-platform-hint=auto flag seems to have no effect. It does work on chromium.

[pbryan]

[pbryan@sesame ~]$ /opt/visual-studio-code/code --enable-features=UseOzonePlatform --ozone-platform=wayland
[304926:0404/102527.563331:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is 
[304926:0404/102527.567356:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process.
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
Warning: 'ozone-platform' is not in the list of known options, but still passed to Electron/Chromium.
[304883:0404/102527.615072:ERROR:cursor_loader.cc(116)] Failed to load a platform cursor of type kNull
[0404/102527.620756:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0404/102527.640310:ERROR:directory_reader_posix.cc(42)] opendir /home/pbryan/.config/Code/Crashpad/attachments/0946e5db-6f17-4fa7-a220-d77c8b893670: No such file or directory (2)
Segmentation fault (core dumped)

[slagiewka]

FWIW the Insiders version runs, but starts as LoDPI on a display which has 200% scaling. Using Developer: Reload Window fixes that and it then runs as proper HiDPI window.

Same is with latest signal-desktop, but for Signal I know of no way to reload it the window...

[major-mayer]

Yes for me the VSCode insiders version runs with Wayland backend enabled by adding --ozone-platform-hint=auto.

Unfortunately Code-OSS which is packaged by Arch/ Manjaro does not crash anymore, but launches with XWayland even if you pass --enable-features=UseOzonePlatform --ozone-platform=wayland. I've checked this with the xeyes tool.

But since the upstream insiders version works fine, I guess it's only a matter of time until the packaged version also works again.

[bbx0]

Actually on Arch code runs with native wayland using the respective settings. :)

Version: 1.66.0
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-04-02T14:00:30.308Z
Electron: 17.4.0
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: 9.8.177.13-electron.0
OS: Linux x64 5.17.3-zen1-1-zen

$ pacman -Q code                                                                                                                                                                                                         
code 1.66.0-2
$ cat ~/.config/electron17-flags.conf                                                                                                                                                                                    
--enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer
--ozone-platform=wayland
--ozone-platform-hint=auto

--ozone-platform-hint=auto has currently no effect. I just maintain it for future reference.

[major-mayer]

Well i don't know what went wrong before, but now for me it also works... Sorry for the spam BTW: You don't need UseOzonePlatform anymore. Ozone is the new default since a few Chromium releases.

[abraxxa]

None of those config files work for me on Ubuntu 22.04 with code 1.66.2. Launching code with --verbose spews so much output it doesn't help me see the problem. Any pointers?

[RicArch97]

None of those config files work for me on Ubuntu 22.04 with code 1.66.2. Launching code with --verbose spews so much output it doesn't help me see the problem. Any pointers?

If you mean the ~/.config/electron-flags.conf file, that's Arch Linux specific.