VS Code should default to Wayland when possible

[justin13888]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.87.0
• OS Version: Fedora 39 x86_64

Steps to Reproduce:

Run code from terminal or open VS Code using code.desktop packaged with VS Code for Fedora repositories.

Problem:

It appears VS Code always defaults to XWayland on running on Linux Wayland desktops (at least when I tried on Fedora Workstation 39 and Ubuntu 22.04 LTS). Wayland has been the default display server on most GNU/Linux distros for the past few years, even for NVIDIA drivers. While forcing VS Code to start with Wayland with command-line arguments for example is possible, it is an extra step and the most convenient method to always start VS Code with Wayland is to append --enable-features=UseOzonePlatform --ozone-platform=wayland to your .desktop files or alias code with those arguments.

However, updating VS Code for example on Fedora may overwrite any changes to the .desktop file. There should be a way for VS Code to default to Wayland without manual user invention when Wayland is detected. Open to thoughts and comments on this suggestion and its feasibility!

Note: There may be similar issues or duplicate but I cannot find them

[ryanabx]

Should be noted: --enable-features=UseOzonePlatform --ozone-platform=auto would cover people who use X11 -- because it will use wayland, and if wayland isn't detected fall back to X11

[justin13888]

In terms of steps needed to address this improvement, I think the most direct approach would be for VS Code to default to Ozone on Linux? Users should be able to just run code from the terminal and VS code would start in Wayland when used.

[RafalSkolasinski]

that would be highly appreciated, the warning is quite annoying

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.

[real-felix]

Yes please, I hate the current state. There is no way to ask vscode to run with wayland by default, I have tried all of the X-flags.conf I have found online without success. Without wayland, the scaling is awful.

[SethMacKayChandler]

For those who use gnome shell, there is a method to update the application shortcut for code in a way that doesn't get overwritten by updates.

Since implementing this behavior as default would still allow for x11 fallback support when needed I think it is a fantastic idea to make this the default behavior.

[MartyBeGood]

--ozone-platform=auto wouldn't open a window for me, but the other options for it seem to be wayland and x11.
code --enable-features=UseOzonePlatform --ozone-platform=$XDG_SESSION_TYPE works well over here for now.

[septatrix]

You may also create the following file on distros using systemd (or in ~/.profile or similar file otherwise):

# ~/.config/environment.d/30-electron-ozone-wayland.conf
ELECTRON_OZONE_PLATFORM_HINT=auto

Though for me running under wayland breaks shortcuts like Ctrl+Shift+´ (which I assume is the same issue as #127932) so that should be fixed before defaulting to wayland as I assume many people using non-US layouts will be affected by this.

[Flimm]

Thank you @septatrix . Setting the environment variable ELECTRON_OZONE_PLATFORM_HINT to auto worked for me. To test it out quickly, I ran:

ELECTRON_OZONE_PLATFORM_HINT=auto code

[Flimm]

Thank you @septatrix . Setting the environment variable ELECTRON_OZONE_PLATFORM_HINT to auto worked for me. To test it out quickly, I ran:

ELECTRON_OZONE_PLATFORM_HINT=auto code

For changes to ~/.config/environment.d/*.conf to take effect, I had to restart my computer.

[po1o]

I tried everything listed here, but vscode still starts under XWayland for me. Any idea what's going on?
I am on Fedora 40.

[opiateblush]

You may also create the following file on distros using systemd (or in ~/.profile or similar file otherwise):

# ~/.config/environment.d/30-electron-ozone-wayland.conf
ELECTRON_OZONE_PLATFORM_HINT=auto

Though for me running under wayland breaks shortcuts like Ctrl+Shift+´ (which I assume is the same issue as #127932) so that should be fixed before defaulting to wayland as I assume many people using non-US layouts will be affected by this.

That works on Ubuntu 22.04, as well, thanks! Unfortunately, it also moved the close, minimize and maximize buttons to the other side of the window bar (from right to left). Is there a way to reverse this?

[ptr727]

Just installed insiders on ubuntu, same issue, 4K monitor, 150% scaling (also had to fix chrome with chrome://flags/#ozone-platform-hint). What is the best method to fix this when installing using snap, or am I better off installing from DEB so I can edit startup?

[justin13888]

Just installed insiders on ubuntu, same issue, 4K monitor, 150% scaling (also had to fix chrome with chrome://flags/#ozone-platform-hint). What is the best method to fix this when installing using snap, or am I better off installing from DEB so I can edit startup?

Just from personal experience, for something that you use as frequently as your code editor that runs various things on your system for dev, I prefer the actual binary (i.e. code distributed through the deb repo).

[ptr727]

Just from personal experience, for something that you use as frequently as your code editor that runs various things on your system for dev, I prefer the actual binary (i.e. code distributed through the deb repo).

That's what I ended up doing, uninstall snap, install from repo, set env, only downside as others mentioned is the min/max/close buttons are now reversed to the OS.

It is a pita to have to fix wayland scaling for chrome and vscode and warp, each in a different way, for the same issue.

[justin13888]

your

wait so what happened to the window decoration (the thing around the actual application window with the buttons? Are you on ubuntu desktop (since you mentioned Snaps)?

To be fair, fractional scaling on Wayland is a (basically) solved problem in Electron. But it's really something that's a problem with app devs and because desktop Linux users still make up such a small fraction in general. Also Gnome on wayland only has client-side decorations so that's another part app devs have to handle (although I don't think it's right)

[ptr727]

wait so what happened to the window decoration (the thing around the actual application window with the buttons? Are you on ubuntu desktop (since you mentioned Snaps)?

When setting the env variable code changes its location of window control buttons (decorations?) to the other side compared to normal apps, this is on ubuntu desktop 24.04.

[justin13888]

wait so what happened to the window decoration (the thing around the actual application window with the buttons? Are you on ubuntu desktop (since you mentioned Snaps)?

When setting the env variable code changes its location of window control buttons (decorations?) to the other side compared to normal apps, this is on ubuntu desktop 24.04.

I reread everything you wrote a few times but it isn't entirely clear what you did and what happened. But the screenshot in the issue you referenced seems to show a standard GTK decoration.

The blurriness from rendering through xwayland out of the box should be fixed as a priority though. Wondering if there's a timeline for this?

[hermidalc]

ELECTRON_OZONE_PLATFORM_HINT=auto code works for me on Fedora 38. Thanks for the tip

[adsick]

Hello, for some reason my VS Code is always using XWayland instead of native Wayland. I believe it is after some nvidia driver update/other update.
I have

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

in /home/user/.config/code-flags.conf, but when resizing VS Code window it's not smooth and I see distinctive black strips around the edge of the window - signs of XWayland running.

[justin13888]

Hello, for some reason my VS Code is always using XWayland instead of native Wayland. I believe it is after some nvidia driver update/other update.
I have

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

in /home/user/.config/code-flags.conf, but when resizing VS Code window it's not smooth and I see distinctive black strips around the edge of the window - signs of XWayland running.

Have you confirmed the flags are actually fed into vs code on startup? I'm assuming you're on Arch with the conf path

[adsick]

Have you confirmed the flags are actually fed into vs code on startup? I'm assuming you're on Arch with the conf path

I'm on Fedora 40. You are right, I've tested manually passing flags to the code command and I see that it's running on Wayland now. (confirmed with xeyes test)

although I see this log:

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

What I did is I modified the desktop file and created an alias in my .baschrc:
/usr/share/applications/code.desktop

...
Exec=code --enable-features=UseOzonePlatform --ozone-platform=wayland %F
...

/home/user/.bashrc

...
alias code="code --enable-features=UseOzonePlatform --ozone-platform=wayland"
...

It really works, but does not seem totally ideal to me.
Do you know any better way of configuring VSC with these flags enabled on every start?

[hermidalc]

Have you confirmed the flags are actually fed into vs code on startup? I'm assuming you're on Arch with the conf path

I'm on Fedora 40. You are right, I've tested manually passing flags to the code command and I see that it's running on Wayland now. (confirmed with xeyes test)

although I see this log:

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

What I did is I modified the desktop file and created an alias in my .baschrc: /usr/share/applications/code.desktop

...
Exec=code --enable-features=UseOzonePlatform --ozone-platform=wayland %F
...

/home/user/.bashrc

...
alias code="code --enable-features=UseOzonePlatform --ozone-platform=wayland"
...

It really works, but does not seem totally ideal to me. Do you know any better way of configuring VSC with these flags enabled on every start?

No need for command line options just set the env var discussed above

[PlatinumLucario]

Did you try --enable-features=UseOzonePlatform instead of --enable-ozone?

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

Tried it, doesn't work...

administrator@MS-7984:~$ /snap/bin/code --enable-features=UseOzonePlatform --ozone-platform=wayland
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
administrator@MS-7984:~$

[PlatinumLucario]

Also, I should note that I'm using Ubuntu 24.04 LTS as well, which uses GNOME 46 as the DE.

[PlatinumLucario]

I've also created a separate issue regarding VS Code no longer supporting Native Wayland, as seen here: #231955

[ctilley83]

Did you try --enable-features=UseOzonePlatform instead of --enable-ozone?
code --enable-features=UseOzonePlatform --ozone-platform=wayland

Tried it, doesn't work...

administrator@MS-7984:~$ /snap/bin/code --enable-features=UseOzonePlatform --ozone-platform=wayland
Warning: 'enable-features' is not in the list of known options, but still passed to Electron/Chromium.
administrator@MS-7984:~$

Even though I get those warnings, it still applies them correctly for me. Open xeyes and run your cursor over the vscode window and see if the eyes move.

[PlatinumLucario]

Even though I get those warnings, it still applies them correctly for me. Open xeyes and run your cursor over the vscode window and see if the eyes move.

Please re-read what I said above:

It crashes immediately upon running it

That means it doesn't open at all. No window, nothing. Even the code process doesn't come up in the list of processes. It doesn't work in wayland.

[Waakul]

Even though I get those warnings, it still applies them correctly for me. Open xeyes and run your cursor over the vscode window and see if the eyes move.

Please re-read what I said above:

It crashes immediately upon running it

That means it doesn't open at all. No window, nothing. Even the code process doesn't come up in the list of processes. It doesn't work in wayland.

It didn't open for me with the flags mentioned above --enable-features=UseOzonePlatform --ozone-platform=wayland rather it worked when i enabled the feature WaylandWindowDecorations too --enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland

@PlatinumLucario try the above

[pawel-kuzma-someone-stole-my-name]

I have the same problem as @PlatinumLucario. VSC on fresh ubuntu 24.04 dosent open at all. '--enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland' dosent work

[Waakul]

I have the same problem as @PlatinumLucario. VSC on fresh ubuntu 24.04 dosent open at all. '--enable-features=UseOzonePlatform,WaylandWindowDecorations --ozone-platform=wayland' dosent work

does it work with no flags? if not, then its due to something else.

[zubozrout]

does it work with no flags? if not, then its due to something else.

Sure it works with no flags. Simply put and as already stated above, the Snap package doesn't work with Wayland at least on Ubuntu and with these options 'enable-features' is not in the list of known options, but still passed to Electron/Chromium is returned instead.

[Waakul]

does it work with no flags? if not, then its due to something else.

Sure it works with no flags. Simply put and as already stated above, the Snap package doesn't work with Wayland at least on Ubuntu and with these options 'enable-features' is not in the list of known options, but still passed to Electron/Chromium is returned instead.

I thought everyone having this problem were on ubuntu.

[PlatinumLucario]

Sure it works with no flags. Simply put and as already stated above, the Snap package doesn't work with Wayland at least on Ubuntu and with these options 'enable-features' is not in the list of known options, but still passed to Electron/Chromium is returned instead.

It's not just the Snap package that won't open in Native Wayland, I can confirm by trying that all of them won't open in Native Wayland. Yep, this means even the .tar.gz portable package, and the apt installations or any installation via any package manager won't make any difference. It only runs in XWayland, it refuses to boot in Native Wayland.

[deeptechdig]

Sure it works with no flags. Simply put and as already stated above, the Snap package doesn't work with Wayland at least on Ubuntu and with these options 'enable-features' is not in the list of known options, but still passed to Electron/Chromium is returned instead.

It's not just the Snap package that won't open in Native Wayland, I can confirm by trying that all of them won't open in Native Wayland. Yep, this means even the .tar.gz portable package, and the apt installations or any installation via any package manager won't make any difference. It only runs in XWayland, it refuses to boot in Native Wayland.

Same here. None of the ELECTRON_OZONE_PLATFORM_HINT=auto and --enable-features=UseOzonePlatform --ozone-platform=wayland options work for me on KDE neon 6.2 with ubuntu 24.04. killall Xwayland will kill it no matter it launches.
My vscode is .deb package downloaded from the official site.

[max-aigner]

For me (Fedora 41 / Gnome 47 / vscode 1.95.2) the true test is also whether vscode survives killall Xwayland and it does not, no matter how I invoke it. I tried with all extensions disabled (including the default ones like git etc) so that Running Extensions is empty but no difference.
For context, I must use the kst plot app which for my use case leaks Xwayland memory @ 2GB/hour so need to kill Xwayland multiple times per day and reopen my vscode sessions. Yes not a real problem and yes restarts are scripted and yes I'm looking for a different plotter but it'd be great if vscode could join the no-Xwayland list like firefox.

[musjj]

On Gnome, I'm getting a weird flickery/flashy white border on the top, when the window is maximized with Wayland. With XWayland, this glitchy artifact goes away. Anyone experiencing this?

[PlatinumLucario]

I've also noticed that this not only affects VS Code, but all apps built in Electron. So this is an Electron issue, meaning it's completely broken in all Electron apps.

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[jbirnick]

Please see the comment above and vote it up if you support it!

@Flimm @hermidalc @ctilley83 @deepak1556 @PlatinumLucario @justin13888 @ryanabx @RafalSkolasinski @real-felix @SethMacKayChandler @MartyBeGood @zortax @musjj @zubozrout @Waakul @christian80gabi @RichardFevrier @mikeslade @shreyasminocha

[vs-code-engineering]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[Sk7Str1p3]

For some reason if I open code with terminal(kitty) it uses env variable which makes it work with Wayland. But if I launch it with Rofi (rofi-wayland exactly), it uses xwayland. The only thing driving me nuts is keyring issues, I have to reenter my token any time it's launching with xwayland. I guess rofi is issue but I can't be sure with that