Open talex5 opened 1 year ago
I've also had the same issue.
Same issue here. It looks like the only upstream change is a bump to matrix-react-sdk
https://github.com/vector-im/element-desktop/compare/v1.11.32...v1.11.33
Related to Electron 25 bump in #237070. See vector-im/element-desktop#1026 for upstream issue
is there any workaround for it yet?
is there any workaround for it yet?
I've just been running NIXOS_OZONE_WL= element-desktop
and dealing with the blurriness. I did consider chasing down the issue and either making an Electron patch or Element patch to fix it, but I have not had the time
I also encountered a similar problem, element-desktop doesn't crash (on wayland) but does not display anything (23.11.20230621.faee04a) (last known working: 23.11.20230606.0ce0c73, running it results in "DRI driver not from this Mesa build ('23.1.2' vs '23.1.1') failed to bind extensions" warnings, but it works)
DRI driver not from this Mesa build ('23.1.2' vs '23.1.1') failed to bind extensions
You might need to log out and log back in after updating or restart. That message means you've activated a config with Mesa 23.1.2 but tried to run element-desktop compiled against Mesa 23.1.1 (e.g. the element-desktop before you updated, possibly from old cached path/desktop entry in your DE)
You might need to log out and log back in after updating or restart. That message means you've activated a config with Mesa 23.1.2 but tried to run element-desktop compiled against Mesa 23.1.1 (e.g. the element-desktop before you updated, possibly from old cached path/desktop entry in your DE)
well, that's not the issue, I just run the last known good executable, which is built against an older version of nixpkgs... and somehow appears to hardcode the DRI driver location...
Oh I didn't read your initial message very well. Do you get the "doesn't crash but doesn't display anything" behavior with element-desktop from the same nixpkgs revision your system is built with then?
(Also Mesa on NixOS impurely loads DRI drivers from /run/opengl-drivers
so for software that requires graphical acceleration, you do need to only use the same Mesa version as the program was compiled with (since recently Mesa stopped supporting mixing versions like that, unfortunately))
a similar problem, element-desktop doesn't crash (on wayland) but does not display anything
I also have this variation of the problem: element-desktop starts, shows notifications, shows a tray icon, and even shows the 'show/hide or quit' window when right-clicking the tray icon, but does not show the main window. I tried to bisect but it seems it (also) depends on some state on the filesystem. NIXOS_OZONE_WL=
also works around it for me.
The console shows a bunch of errors around the GPU, but I haven't checked whether those are also there when it does work:
@raboof. I encountered the same behavior.
The console shows a bunch of errors around the GPU, but I haven't checked whether those are also there when it does work
Today it works for me, and indeed no DMA/GPU errors
I noticed that it starts quite reliably when I have my laptop on the "performance" power profile, while it fails to start up quite reliably on "powersave". Smells like some sort of race condition...
I've also noticed that it renders pretty slowly and eats a lot of CPU -- which leads me to suspect it's not using GPU-accelerated rendering? No relevant errors on stdout/stderr though.
Can everyone share what Wayland compsitor they are using, what GPU driver they are using, and what NixOS channel they are using (e.g. unstable or 23.05)?
I'm wondering if the behavior differs based on compositor
I'm on Sway, i915, nixos-unstable
I'm using volare (99% sway, 1% funky stuff) on nixos-unstable. TBH I don't know how to tell which GPU driver I'm using - lspci shows I have an Intel controller using the i915 kernel module and an NVIDIA 3D controller using nouveau.
Sway, radeon, nixos-unstable
Sway, amdgpu (according to lsmod
), NixOS 23.05 for me.
(also: I'm sure it's not related, but for completeness I should mention I have a slightly patched wlroots: see https://github.com/talex5/wayland-proxy-virtwl/issues/55#issuecomment-1564515542)
Sway, i915, nixos-23.05
Just experienced this reliably independent of the power profile on a new machine (which is however identical to the other one...). Running it under strace to try and work out the problem doesn't reproduce it, so +1 on my previous suspicion that it's a race condition :roll_eyes:
It does seem that making a sway window rule to float Element (and also removing the window-state.json
file to reset it) lets it work again, but as soon as I make it tiled it crashes
It also seems Element isn't the only app affected by this, so it's definitely an upstream Electron issue (it's always an Electron issue...)
Just to confirm this, I'm on sway, amdgpu, nixos-unstable (645ff62 to be exact) and also had this issue. Using (element-desktop.override {electron = electron_24;})
fixed it for me, so it's highly likely to be related to Electron itself.
Should we change the package to use 24 by default, although that diverges from what upstream uses https://github.com/vector-im/element-desktop/blob/4e69dda7d23028c141dc05467ce4a67f2781dcdb/package.json#L93 ?
While using 24 might work on amdgpu, it seems to still be broken on nvidia (with sway, nixos-unstable). With (element-desktop.override {electron = electron_24;})
I get
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to open nvidia-drm: /run/opengl-driver/lib/dri/nvidia-drm_dri.so: cannot open shared object file: Permission denied (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open zink: /run/opengl-driver/lib/dri/zink_dri.so: cannot open shared object file: Permission denied (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /run/opengl-driver/lib/dri/kms_swrast_dri.so: cannot open shared object file: Permission denied (search paths /run/opengl-driver/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /run/opengl-driver/lib/dri/swrast_dri.so: cannot open shared object file: Permission denied (search paths /run/opengl-driver/lib/dri, suffix _dri)
which someone else reported happening with webcord: https://github.com/SpacingBat3/WebCord/issues/433.
With --ozone-platform=x11
I get the same error and a black window instead of no window.
The same error was reported in this repo in April: https://github.com/NixOS/nixpkgs/issues/224332#issuecomment-1519033918
Edit: It does seem to work with --disable-gpu
though.
Experience report for 1.11.35:
Driver | Compositor | Is NIXOS_OZONE_WL=1 set? |
Was --use-gl=desktop passed? |
Does it work? |
---|---|---|---|---|
NVIDIA | KDE | Yes | No | No, window refuses to open |
NVIDIA | KDE | Yes | Yes | No, window refuses to open |
NVIDIA | KDE | No | No | No, window opens but renders a black screen |
NVIDIA | KDE | No | Yes | Yes |
amdgpu | Hyprland | Yes | No | No, a transparent window pops open and immediately closes, or a window pops up and things are drawn but interacting with the window in any way kills it |
amdgpu | Hyprland | Yes | Yes | No, window refuses to open |
amdgpu | Hyprland | No | No | Yes |
amdgpu | Hyprland | No | Yes | Yes |
i915 | Hyprland | Yes | No | No, a transparent window pops open and immediately closes, or a window pops up and things are drawn but interacting with the window in any way kills it |
i915 | Hyprland | Yes | Yes | No, window refuses to open |
i915 | Hyprland | No | No | Yes |
i915 | Hyprland | No | Yes | Yes |
stdout/stderr logs:
nvidia-no-no.txt nvidia-no-yes.txt nvidia-yes-no.txt nvidia-yes-yes.txt
amdgpu-no-no.txt amdgpu-no-yes.txt amdgpu-yes-no.txt amdgpu-yes-yes.txt
The i915 logs are identical to the amdgpu logs so there's no reason to upload those.
Disclaimer: I have no idea what --use-gl=desktop
actually does or why it works. It even seems like this is supposed to be the default behavior, if I'm reading this correctly: https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/gl_switches.cc;l=100-101;drc=8bca1335dc7993df8e44307816092f9f9d25d4aa.
Note: If you're looking at this and thinking "but I don't see my compositor on the list, what do I do!?", the answer is the compositor is most likely irrelevant and all you need to focus on is the GPU driver. I only included it in the unlikely event that it does matter.
I can confirm I can reproduce one of those combinations:
Driver: Nvidia
Compositor: Hyprland
Is NIXOS_OZONE_WL=1
set?: No
Was --use-gl=desktop
passed?: Yes
Does it work: Yes?
$ NIXOS_OZONE_WL= /nix/store/ans88lqlrs559jjab71ccca93db8bni7-element-desktop-1.11.35/bin/element-desktop --use-gl=desktop
Any other combination either results in no window or a black window.
I'm on nixos unstable using the nvidia driver from nvidiaPackages.production
.
However I do get horrible flicker.
I'm experiencing the same thing on river, amd and unstable.
Downgrading electron to 24 allows me to use the app for now.
Supposedly, according to the linked element-desktop issue linked higher up in this thread, Electron 26 fixes this. If anyone wants to test
(It seemed racy to begin with for the last several Electron versions, though, so I wouldn't be surprised if it was just "fixed" in that it no longer occurs with the current version rather than actually fixed)
I've changed my override to explicitly use electron_26
for building element-desktop
(version 1.11.40 currently) and it seems to work fine. Still on amdgpu and wayland (sway). It does consistently segfault when quitting but that's not exactly a big issue.
Report: element package from nixpkgs master and electron_26
, Nvidia GPU, and wayland (hyprland). Still does not work. I still have to launch with NIXOS_OZONE_WL= element-desktop --use-gl=desktop
and even then the flickering and typing lag is extreme making it unusable.
I've changed my override to explicitly use
electron_26
for buildingelement-desktop
(version 1.11.40 currently) and it seems to work fine. Still on amdgpu and wayland (sway). It does consistently segfault when quitting but that's not exactly a big issue.
FWIW, same experience here except on Hyprland instead of Sway.
I've changed my override to explicitly use
electron_26
for buildingelement-desktop
(version 1.11.40 currently) and it seems to work fine. Still on amdgpu and wayland (sway). It does consistently segfault when quitting but that's not exactly a big issue.FWIW, same experience here except on Hyprland instead of Sway.
same here
Element 1.11.51 is out using electron 27, and it still does not work on nixos with wayland.
Presumably you mean specifically with the NVIDIA proprietary drivers?
Correct, sorry, got lazy yesterday, let me add more detail like my previous comment.
I saw that the develop branch of element-desktop is using Electron v28. So I tested with it, and it works pretty well!
Electron Version | Is NIXOS_OZONE_WL=1 set? | Was --use-gl=desktop passed? | Does it work? |
---|---|---|---|
28.0.0 | Yes | Yes | No, no screen |
" | Yes | No | No, no screen |
" | No | Yes | Yes (!) |
" | No | No | Yes (!) |
27.1.3 | Yes | Yes | No, no screen |
" | Yes | No | No, no screen |
" | No | Yes | No, no screen |
" | No | No | No, no screen |
26.3.0 | Yes | Yes | No, no screen |
" | Yes | No | No, no screen |
" | No | Yes | Sort of, screen renders but much input latency and visual flickering |
" | No | No | No, no screen |
...
home.packages = [
(edge.element-desktop.override {electron = pkgs.electron_28;})
];
...
any updates on this? im having the same errors
So over the past year the exact behavior has changed week-to-week as I update unstable and upstream packages change.
Currently:
565.57.01-6.6.58
(aka boot.kernelPackages.nvidiaPackages.beta
),element-desktop --use-gl=desktop
,pkgs.element-desktop
) NIXOS_OZONE_WL
unsetelement-desktop is running fine. No flickering, no missing screen, etc. Just works
Describe the bug
After updating to the latest element-desktop-wayland, it crashes on startup.
NIXOS_OZONE_WL=1 /nix/store/iqmzwvjhn1kqwhikifq4xy9w2gdx33l5-element-desktop-1.11.32/bin/element-desktop
worksNIXOS_OZONE_WL=1 /nix/store/2a735sj7xw7gbnq6pamwq2hd0bfajvsc-element-desktop-1.11.33/bin/element-desktop
crashesSteps To Reproduce
Just run it:
The messages displayed are the same for the working and failing versions, except for the SIGSEGV line in the failing one.
coredumpctl debug
doesn't seem helpful:Notify maintainers
@ma27 @fadenb @mguentner @ekleog @ralith @dandellion @sumnerevans
Metadata
Commit 9b19034f7d0 doesn't work, while the previous commit does.