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

Vscode does not launch in wayland session #146349

Closed
adamijak opened this issue Mar 30, 2022 · 26 comments
Closed

Vscode does not launch in wayland session #146349

adamijak opened this issue Mar 30, 2022 · 26 comments
Assignees

Comments

@adamijak
Copy link

adamijak commented Mar 30, 2022

  • VS Code Version: 1.66
  • OS Version: Fedora 36

Steps to Reproduce:

  1. When I launch vscode with code --enable-features=UseOzonePlatform --ozone-platform=wayland it does not run under wayland it does under xwayland
@Xelphos
Copy link

Xelphos commented Mar 30, 2022

Can confirm. Refuses to launch for me as well.
Fedora 36, Ryzen 3700x, RTX 2070 SUPER, Wayland, GNOME.

@FeralHedgehog
Copy link

FeralHedgehog commented Mar 30, 2022

I'm experiencing the same issue on Arch Linux, but I've found a weird workaround - if you run code with many command line options it will reliably launch in Wayland-native mode:
code --enable-features=UseOzonePlatform --ozone-platform=wayland --log debug --log debug
I've gotten it to work on several machines, though each requires a different amount of --log debug options (one needs two, another needs five).

Tested on:
Arch Linux, Ryzen 5 5600G, Radeon Graphics, Wayland, Sway - x2 --log debug
Arch Linux, Intel Core i7-1165G7, Iris Xe Graphics, Wayland, Sway - x5 --log debug
Arch Linux, Intel Core m3-6Y30, Intel HD Graphics 515, Wayland, Sway - x2 --log debug

@barklan
Copy link

barklan commented Mar 30, 2022

Recent version of Insomnia (uses electron 17.1.0) does not start as well with flags --enable-features=UseOzonePlatform --ozone-platform=wayland.

@barklan
Copy link

barklan commented Mar 30, 2022

Same thing, exactly this input (or more args) launches VSCode with native Wayland window

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

Without any arguments or with just --ozone-platform-hint=wayland it starts xwayland window.
Arch Linux / KDE Plasma (wayland session)

@Xelphos
Copy link

Xelphos commented Mar 30, 2022

I could be wrong, but I wonder if this issue is this: electron/electron#33355

@rstrube
Copy link

rstrube commented Mar 30, 2022

Same here, since 1.66 unable to run as a native wayland application.

Previously I had setup ~/.config/code-flags.conf with the following:

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

And it would run as a native wayland application. Since 1.66 I get a crash. I've attached the coredump:

vscode_1.66.coredump.txt

I've gone back to running it as a XWayland application for the time being.

@utybo
Copy link

utybo commented Mar 30, 2022

As a side note, this affects all electron applications with version 17 I've tried, including the little test app that pops up when you run just electron (this probably affects earlier versions of Electron as well) but not with electron-nightly, hopefully thanks to the PR mentioned by Xelphos.

For example: on the left, using the latest available version of Electron (from Manjaro repositories), on the right using electron-nightly from NPM.

image

I guess we have to wait for a backport of whatever fixed the issue into 17.x, then wait for VS Code to update the bundled version of Electron?

@Xelphos
Copy link

Xelphos commented Mar 30, 2022

As a side note, this affects all electron applications with version 17, including the little test app that pops up when you run just electron (this probably affects earlier versions of Electron as well) but not with electron-nightly, hopefully thanks to the PR mentioned by Xelphos.

For example: on the left, using the latest available version of Electron (from Manjaro repositories), on the right using electron-nightly from NPM.

I guess we have to wait for a backport of whatever fixed the issue into 17.x, then wait for VS Code to update the bundled version of Electron?

Ah, cool. Thanks for sharing. Yeah, it looks like the fix was included Electron 17.3.1. So I guess we just have to wait for that.

@PHLAK
Copy link

PHLAK commented Mar 31, 2022

Same, VS Code fails to launch after updating to v1.66.0. Here's the verbose output.

$ code --verbose
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.
[4087:0330/222408.674131:WARNING:wayland_object.cc(94)] Binding to gtk_shell1 version 4 but version 5 is available.
[4087:0330/222408.674374:WARNING:wayland_drm.cc(96)] Failed to get drm magic
[4087:0330/222408.789478:WARNING:bluez_dbus_manager.cc(248)] Floss manager not present, cannot set Floss enable/disable.
[4130:0330/222408.814735:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is
[4130:0330/222408.817684:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process.
[main 2022-03-31T05:24:08.860Z] [File Watcher (node.js)] Request to start watching: /home/chris/.config/Code/User (excludes: <none>),/home/chris/.config/Code/User/settings.json (excludes: <none>)
[main 2022-03-31T05:24:08.875Z] Starting VS Code
[main 2022-03-31T05:24:08.875Z] from: /opt/visual-studio-code/resources/app
[main 2022-03-31T05:24:08.875Z] args: {
  _: [],
  diff: false,
  add: false,
  goto: false,
  'new-window': false,
  'reuse-window': false,
  wait: false,
  help: false,
  'list-extensions': false,
  'show-versions': false,
  'pre-release': false,
  version: false,
  verbose: true,
  status: false,
  'prof-startup': false,
  'no-cached-data': false,
  'prof-v8-extensions': false,
  'disable-extensions': false,
  'disable-gpu': false,
  'ms-enable-electron-run-as-node': false,
  telemetry: false,
  debugRenderer: false,
  logExtensionHostCommunication: false,
  'skip-release-notes': false,
  'skip-welcome': false,
  'disable-telemetry': false,
  'disable-updates': false,
  'disable-keytar': false,
  'disable-workspace-trust': false,
  'disable-crash-reporter': false,
  'crash-reporter-id': 'a1eecd63-651b-426c-97ba-236bca2d24e1',
  'skip-add-to-recently-opened': false,
  'unity-launch': false,
  'open-url': false,
  'file-write': false,
  'file-chmod': false,
  'driver-verbose': false,
  force: false,
  'do-not-sync': false,
  trace: false,
  'force-user-env': false,
  'force-disable-user-env': false,
  'open-devtools': false,
  __sandbox: false,
  'no-proxy-server': false,
  'no-sandbox': false,
  nolazy: false,
  'force-renderer-accessibility': false,
  'ignore-certificate-errors': false,
  'allow-insecure-localhost': false,
  'disable-dev-shm-usage': false,
  logsPath: '/home/chris/.config/Code/logs/20220330T222408'
}
[main 2022-03-31T05:24:08.876Z] Resolving machine identifier...
[main 2022-03-31T05:24:08.876Z] Resolved machine identifier: 31950d74875970a23fcd086e0932c06c52174bdf1301a3dcd541555964f70073
[main 2022-03-31T05:24:08.877Z] Main->SharedProcess#connect
[main 2022-03-31T05:24:08.881Z] [File Watcher (node.js)] Started watching: '/home/chris/.config/Code/User'
[main 2022-03-31T05:24:08.882Z] [File Watcher (node.js)] Started watching: '/home/chris/.config/Code/User/settings.json'
[main 2022-03-31T05:24:08.884Z] StorageMainService: creating global storage
[main 2022-03-31T05:24:08.889Z] lifecycle (main): phase changed (value: 2)
[main 2022-03-31T05:24:08.890Z] windowsManager#open
[main 2022-03-31T05:24:08.891Z] windowsManager#open pathsToOpen [
  {
    workspace: { id: '62750c442316dab285c54ce35595073b', configPath: [h] },
    type: 1,
    exists: true,
    remoteAuthority: undefined,
    transient: undefined
  }
]
[main 2022-03-31T05:24:08.892Z] windowsManager#doOpenFolderOrWorkspace {
  folderOrWorkspace: {
    workspace: { id: '62750c442316dab285c54ce35595073b', configPath: [h] },
    type: 1,
    exists: true,
    remoteAuthority: undefined,
    transient: undefined
  },
  filesToOpen: undefined
}
[main 2022-03-31T05:24:08.893Z] IPC Object URL: Registered new channel vscode:65862d78-bb52-4652-bd76-e8634f4237c9.
[main 2022-03-31T05:24:08.893Z] window#validateWindowState: validating window state on 1 display(s) { mode: 0, x: 0, y: 0, width: 1024, height: 768 }
[main 2022-03-31T05:24:08.893Z] window#validateWindowState: 1 monitor working area { x: 0, y: 0, width: 1920, height: 1200 }
[main 2022-03-31T05:24:08.893Z] window#ctor: using window state { mode: 0, x: 0, y: 0, width: 1024, height: 768 }
[4087:0330/222408.893894:WARNING:wayland_surface.cc(118)] Server doesn't support zcr_alpha_compositing_v1.
[4087:0330/222408.893907:WARNING:wayland_surface.cc(129)] Server doesn't support overlay_prioritizer.
[4087:0330/222408.893910:WARNING:wayland_surface.cc(139)] Server doesn't support surface_augmenter.
[4087:0330/222408.894139:ERROR:cursor_loader.cc(116)] Failed to load a platform cursor of type kNull
[0330/222408.898545:ERROR:elf_dynamic_array_reader.h(64)] tag not found
[0330/222408.917129:ERROR:directory_reader_posix.cc(42)] opendir /home/chris/.config/Code/Crashpad/attachments/2049057f-ca20-4181-a48e-4eb7ccc9a045: No such file or directory (2)

@deepak1556
Copy link
Contributor

Merging to #141964, this is a known issue and will be fixed with next electron patch update.

@mamantoha
Copy link

Electron 17.3.1 should fix the issue https://github.com/electron/electron/releases/tag/v17.3.1

@jokeyrhyme
Copy link

Howdie, thanks for sharing this very cool project

I was wondering if there were plans to include a wayland test case in CI at some point? Is there a milestone or a set of other tasks that need to be done before doing so?

Put another way, when will wayland regressions block releases?

Cheers!

@eternal-sorrow
Copy link

eternal-sorrow commented Mar 31, 2022

Howdie, thanks for sharing this very cool project

I was wondering if there were plans to include a wayland test case in CI at some point? Is there a milestone or a set of other tasks that need to be done before doing so?

Put another way, when will wayland regressions block releases?

Cheers!

I guess not before Wayland backend becomes default when running in a wayland compositor. Right now it's opt-in, so users who enable it should know what they are doing and what the risks are.

@mtorromeo
Copy link

Right now it's opt-in, so users who enable it should know what they are doing and what the risks are

I don't understand the reasoning, this does not have anything to do with testing a feature in CI

@hlafaille
Copy link

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

Doesn't work on Arch, including --disable-gpu-sandbox

@ljedrz
Copy link

ljedrz commented Apr 1, 2022

The following works for me on Arch (4x --log debug):

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

@alosarjos
Copy link

Still failing for me with 1.66.1

@mamantoha
Copy link

Failing because 1.66.1 uses Electron 17.2.0. I guess next release will use >= 17.4.0
image

@juxuanu
Copy link

juxuanu commented Apr 13, 2022

1.66.2 crashed my gnome-shell 🥳 . Still not working, then.

@adamijak
Copy link
Author

adamijak commented Apr 13, 2022

1.66.2 crashed my gnome-shell partying_face . Still not working, then.

It does not crash mine gnome-shell, but vscode is not starting either.
Issue still not resolved. I will stick with 1.65.2

@utybo
Copy link

utybo commented Apr 13, 2022

For people stuck on 1.65 because of Wayland-related issues, you can also use VS Code Insiders which is less stable (as you'd expect from nightly releases) but it works well for me under Wayland. Mine reports Electron 17.4.0.

@Ashark
Copy link

Ashark commented May 4, 2022

you can also use VS Code Insiders

In Arch Linux I have built code-git version 1.67.0.r96226.g9556854c8fc-1, it reports Electron 13.6.9 for some reason. But it launches with Wayland.

@9Lukas5
Copy link

9Lukas5 commented May 7, 2022

Hey folks, I'm on Ubuntu 20.04/Gnome 42. Updated to 1.67.0-1651667246 and it works again under wayland without changing my desktop file 👍

@zoeleu
Copy link

zoeleu commented May 8, 2022

It works on 1.67.0, however, I have no window decorations.

@Xelphos
Copy link

Xelphos commented May 8, 2022

It works on 1.67.0, however, I have no window decorations.

You need to use --enable-features=WaylandWindowDecorations

Or change the Title Bar Style to custom in settings.

@9Lukas5
Copy link

9Lukas5 commented May 8, 2022

@Xelphos hu, cool feature flag, helps me with another application.

For VSCode I'm using an internal setting quite a while now:

  • Open your settings in texteditor (JSON) (ctrl+shift+p, type "settings", open settings (JSON))
  • add "window.titleBarStyle": "custom"

And I'll keep using the VSCode custom title bar, because with the electron flag I get a normal looking title bar, but the buttons are on the left instead of the right and going to fullscreen keeps a quite large padding around the whole window.
With the custom title bar it looks much better in my opinion.

@github-actions github-actions bot locked and limited conversation to collaborators May 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests