Open sjcobb2022 opened 1 month ago
penguix0
commented
1 month ago I am also experiencing these issues, especially when closing the lid of my laptop or when a monitor goes into standby while locked. Weird thing is that I'm not getting any logs from hypridle nor hyprlock. How are you acquiring these error messages?
sjcobb2022
commented
1 month ago @penguix0
journalctl --user -u hypridle | tail -n 500
myned
commented
1 month ago Able to consistently reproduce on AMD with https://github.com/hyprwm/Hyprland/commit/4beac91cbd791657cc53d6e483eb41bf4df1ec0c, hyprlock @ https://github.com/hyprwm/hyprlock/commit/cf0e975fedcddde897a75c5b6a2a111177b0baad as well with:
hyprlock --immediate &> hyprlock.log & sleep 1 && hyprctl dispatch dpms offDoes not occur without the and --immediate flag--immediate-render does not change the outcome of a red screen. Below logs taken from a TTY.
misaka18931
commented
1 month ago Encountered the same issue on nixos-unstable with nVidia 1660 GPU.
PaideiaDilemma
commented
1 month ago I can confirm. I reproduced it by
hyprlock>hyprlock.log & sleep 2 && hyprctl keyword monitor "DP-3,disable" && sleep 2 && hyprctl keyword monitor "DP-3,1920x1080,0x0,1"Hyprlock is stuck with [CRITICAL] Couldn't create eglWindow because it fails to create the eglWIndow for the FALLBACK output.
~In addition to that I noticed that hyprlock is not notified when an output is removed.~ Hyprland complains (see logs below) ~and hyprlock never receives the removed event for the monitor.~ Edit: It does receive the removed event, but something is weird. Edit 2: No it does work properly. It is just that the output is not commited, so it does not turn off and the last rendered frame is displayed.
[TRACE] CMonitorState::ensureBufferPresent: Ignoring, monitor is not enabled
[LOG] [AQ] drm: Disabling output DP-3
[ERR] [AQ] drm: Cannot commit when a page-flip is awaiting
[WARN] state.commit() failed in CMonitor::onDisconnectProbably related to https://github.com/hyprwm/Hyprland/issues/6995
PaideiaDilemma
commented
1 month ago Also kinda related to #417
PaideiaDilemma
commented
1 month ago Please rename this issue, since it has nothing to do with NixOS or Nvidia
kito30
commented
1 month ago bindl=,switch:on:[switch name],exec,hyprctl keyword monitor "eDP-1, disable" bindl=,switch:off:[switch name],exec,hyprctl keyword monitor "eDP-1, 2560x1600, 0x0, 1" I'm also having problem when have this on, I want to dock it when I am using external monitors. When not using external monitor, hyprlock just die when there is no display.
husjon
commented
2 weeks ago I'm on NixOS and after recently switching from 24.05 stable version of hyprlock (0.3.0) to upstream (hyprlock-0.4.1+date=2024-08-18_f673759), I found that the one of my monitors shows a fully red screen while on the other, hyprlock is running but does not accept any input.
I do not have any logging enabled at the moment but I'll enable to get some data on it.
This is similar to what I experienced back in March. I do have a slightly different setup than last time (then nvidia, now amd). https://github.com/hyprwm/hyprlock/issues/76#issuecomment-1979247577
@vaxerski this is better, now with the patch applied I can disconnect and reconnect the monitor manually without it failing.
However I do see that if I disconnect one of the monitors, I cannot input my credentials until I reconnect that monitor.
I forgot to add that after I started using 24.05 stable version of hyprlock (0.3.0) I thought the issue was fixed but of course there were a version mismatch from me issue I mentioned :)
Logged on at 11:19, found secondary monitor red and primary ok but not accepting input. Had to switch to a different tty and restart Hyprland to get back. Hypridle didn't log enything out of the ordinary https://gist.github.com/husjon/1732813d4a26954be664780c4e8f58bc (also includes journald entries for this timeperiod) However when checking journald, I see that one hour earlier at 10:08, hypridle logs the following to journald:
sep. 01 10:08:24 workstation hypridle[203585]: Hyprland IPC didn't respond in time
sep. 01 10:08:24 workstation hypridle[203585]: Couldn't read (5)Then shortly after brave dumps core and it also seem to affect pipewire + wireplumber
sep. 01 10:08:27 workstation kernel: amdgpu 0000:03:00.0: [drm] enabling link 0 failed: 15
sep. 01 10:08:27 workstation kernel: snd_hda_codec_hdmi hdaudioC1D0: HDMI: Unknown ELD version 0
sep. 01 10:08:30 workstation kernel: amdgpu 0000:03:00.0: [drm] enabling link 1 failed: 15
sep. 01 10:08:31 workstation wireplumber[197073]: wplua: [string "alsa.lua"]:182: attempt to concatenate a nil value (local 'node_name')
stack traceback:
[string "alsa.lua"]:182: in function <[string "alsa.lua"]:175>
sep. 01 10:08:32 workstation systemd[1]: Started Process Core Dump (PID 203601/UID 0).
sep. 01 10:08:34 workstation systemd-coredump[203602]: Process 135234 (brave) of user 1000 dumped core.
Module libnssckbi.so without build-id.
... REDACTED FOR BREVITY ...I just switched hyprland to use the package from the unstable channel (0.42.0).
PaideiaDilemma
commented
1 week ago For now hyprctl keyword monitor "FALLBACK,1920x1080@60,auto,1" fixes it.
~But only after https://github.com/hyprwm/Hyprland/commit/83ab3ae0afeafe25ca2038888478740d0a80396a, otherwise crash on login.~
Edit: nevermind for that was some bad commit I was on. It works on 0.42.0 with the command.
husjon
commented
1 week ago Unfortunately Hyprland 0.42.0 refuses to run on my system, gets a SIGABRT shortly after starting so I won't be able to test / verify it.
Hyprland just before sigabrt.
did not find extension DRI_Mesa version 2
did not find extension DRI_SWRast version 5
failed to bind extensions
terminate called after throwing an instance of 'std::runtime_error'
what(): CBackend::create() failed!`I'll take a look at the logs and open a new issue related to it Hyprland.
PaideiaDilemma
commented
1 week ago I guess you are on nixos.
Most likely your systems mesa version does not match the one that Hyprland was build with.
This is very easy to get when on nix for example when using flakes and not specifying inputs.nixpkgs.follows = "nixpkgs"; in the hyprland input
husjon
commented
1 week ago Correct about nixos, I am running on 24.05 but I do also have an overlay to pass in the unstable channel for certain packages, this is also where hyprland 0.42.0 comes in, aka I do not add hyprland as a separate input.
This way I can specify a package from unstable like so:
programs.hyprland = {
enable = true;
xwayland.enable = true;
package = pkgs.unstable.hyprland;
};If this is wrong, I'd happily correct it :)
PaideiaDilemma
commented
1 week ago Yeah this is wrong, since pkgs.unstable.hyprland is build with a different mesa version than the one in nixpkgs stable.
But only after https://github.com/hyprwm/Hyprland/commit/83ab3ae0afeafe25ca2038888478740d0a80396a, otherwise crash on login.
You cannot test if this is fixed properly with 0.42.0 anyways, so I would highly suggest you use the hyprland flake directly.
husjon
commented
1 week ago Cool and no worries, I'll update my inputs to use the hyprland flake directly and give it another go a bit later on, thanks for the pointers.
husjon
commented
1 week ago @PaideiaDilemma gave it a quick shot before logging off for the day.
Using the flake directly but staying on NixOS 24.05 stable results in a failed build because stable only has libinput v1.25 (requires libinput>=1.26.0, which is available in unstale). https://gist.github.com/husjon/f7e45cb07391c36db1cbda3aee687686#file-nixos-stable-hyprland-0-42-0-flake-md
Setting my base nixpkgs to point to unstable is even worse, it complains that the directory for hyprland is not a git repository (fatal: not a git repository (or any of the parent directories): .git) and then that CMakeList.txt is missing.
https://gist.github.com/husjon/f7e45cb07391c36db1cbda3aee687686#file-nixos-unstable-hyprland-0-42-0-flake-md
PaideiaDilemma
commented
1 week ago @husjon
Using the flake directly but staying on NixOS 24.05 stable results in a failed build because stable only has libinput v1.25 (requires libinput>=1.26.0, which is available in unstale). https://gist.github.com/husjon/f7e45cb07391c36db1cbda3aee687686#file-nixos-stable-hyprland-0-42-0-flake-md
Well that is unfortunate. You could overlay a newer libinput version to fix it, but that is annoying.
Setting my base nixpkgs to point to unstable is even worse, it complains that the directory for hyprland is not a git repository (fatal: not a git repository (or any of the parent directories): .git) and then that CMakeList.txt is missing. https://gist.github.com/husjon/f7e45cb07391c36db1cbda3aee687686#file-nixos-unstable-hyprland-0-42-0-flake-md
Pretty sure that is because you need ?submodules=1 in your flake input for hyprland like that: url = "git+https://github.com/hyprwm/Hyprland?submodules=1";
See the hyprland wiki's nix section.
husjon
commented
1 week ago Adding ?submodules=1 did help to get it going but now it failed building the xdg-portal for hyprland, I'll give the linbinput overlay a shot instead.
If that doesn't work for somewhat reason, I will be switcing system to unstable after I'm done splitting my main flake (currently have my servers and personal computers in it).
Thanks for the pointers so far. :)
PaideiaDilemma
commented
1 week ago use something like this to take xdph from the flake. Good luck.
programs.hyprland = {
enable = true;
package = inputs.hyprland.packages.${pkgs.system}.hyprland;
portalPackage = inputs.hyprland.packages.${pkgs.system}.xdg-desktop-portal-hyprland;
};Regarding the actual issue:
To fix it make sure you update aquamarine to 0.4.0. If you can't yet put monitor=FALLBACK,1920x1080@60,auto,1 in your config for now
@sjcobb2022 @penguix0
husjon
commented
1 week ago use something like this to take xdph from the flake. Good luck.
programs.hyprland = { enable = true; package = inputs.hyprland.packages.${pkgs.system}.hyprland; portalPackage = inputs.hyprland.packages.${pkgs.system}.xdg-desktop-portal-hyprland; };
That worked like a charm (also a tad simpler than my approach), thank you. Overlays are still something that I've not yet done much with on a per-package level.
I'm now on latest main of Hyprland, I'm gonna let it roll for a few days to see how both it and hyprlock behaves.
❯ hyprctl systeminfo -c
Hyprland, built from branch at commit 9b54342baa27d8de0460e1103ec4c3cc65592ed8 ().
Date: 2024-09-03
Tag: , commits: 9b54342baa27d8de0460e1103ec4c3cc65592ed8Edit:
hyprlock is now 0.4.1 (73b0fc2).
Running it, throws the following error: [CRITICAL] Hyprlock threw: EGL_EXT_platform_base not supported :thinking:
Using the non-flake version from unstable works but is from the release in July.
PaideiaDilemma
commented
1 week ago Running it, throws the following error: [CRITICAL] Hyprlock threw: EGL_EXT_platform_base not supported 🤔 Using the non-flake version from unstable works but is from the release in July.
Use the flake and make sure you use inputs.nixpkgs.follows = "nixpkgs"; for the hyprlock flake input as well.
gil0mendes
commented
1 week ago Do something like this on your flake like @PaideiaDilemma said:
hyprland.url = "git+https://github.com/hyprwm/Hyprland?submodules=1";
hyprland.inputs.nixpkgs.follows = "nixpkgs-unstable";Hi and thanks, unfortuntately it is exactly the way I've already set it up.
I am going to make my configuration public soon so it will be a bit easier to reference, but for now, this is how it's set up after I switched to unstable:
My inputs:
inputs = {
nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
hyprland.url = "git+https://github.com/hyprwm/Hyprland?submodules=1";
hyprland.inputs.nixpkgs.follows = "nixpkgs";
}Systems configuration for hyprland:
programs.hyprland = {
enable = true;
xwayland.enable = true;
package = inputs.hyprland.packages."${pkgs.system}".hyprland;
portalPackage = inputs.hyprland.packages.${pkgs.system}.xdg-desktop-portal-hyprland;
}; Finally, hyprlock is set up via home-manager as part of my flake, with inputs fed to home-manager via extraSpecialArgs:
programs.hyprlock = {
enable = true;
package = inputs.hyprlock.packages."${pkgs.system}".hyprlock;
}programs.hyprlock.package is commented out in my actual config so I have something that works in the meanwhile. :)
PaideiaDilemma
commented
1 week ago I don't understand.
Add
hyprlock.url = "github:hyprwm/hyprlock";
hyprlock.inputs.nixpkgs.follows = "nixpkgs";to your inputs
and then just uncomment the programs.hyprlock.package line and it should work.
husjon
commented
1 week ago FML, yeah that was my problem, I had not set nixpkgs.follows on hyprlock, I only did it on hyprland facepalm
I must skipped past the last part of your comment
Use the flake and make sure you use
inputs.nixpkgs.follows = "nixpkgs";for the hyprlock flake input as well.
Sorry and thanks @PaideiaDilemma :)
husjon
commented
1 week ago Today when I got back from work, one of my monitors were black while my main monitor showed hyprlock, it initially did not respond to input, however after about a second my second monitor was restored and input was accepted.
This is with hyprlock-0.4.1+date=2024-09-01_73b0fc2 and hyprland-0.42.0+date=2024-09-03_9b54342.
A lot better than it was :)
Edit 08. Sept: What I described above have happened a couple of time but all of them have recovered a few seconds after the first monitor have been awoken.
andresilva
commented
4 days ago FWIW this seems to have started happening again (even after https://github.com/hyprwm/Hyprland/commit/83ab3ae0afeafe25ca2038888478740d0a80396a).
PaideiaDilemma
commented
3 days ago Yeah the root cause has not been fixed yet.
monitor=FALLBACK,1920x1080@60,auto,1 still works as a temporary fix.
I need to figure out a few things to know how to address it properly. Basically headless outputs need to advertise a default mode in aq.
andresilva
commented
3 days ago Thanks, I'll re-add the monitor rule. I wonder if the root cause of the issue also leads to this somehow. Sorry for the off-topic.
user354015
commented
3 days ago Yeah the root cause has not been fixed yet.
monitor=FALLBACK,1920x1080@60,auto,1still works as a temporary fix.I need to figure out a few things to know how to address it properly. Basically headless outputs need to advertise a default mode in aq.
Thank you so much, I've been having issues with this exact thing for months, and I couldn't lock my screen (I'd instead switch to another tty) because it would just freeze everything. Adding this to my config fixed it completely!
Hi there,
I have been running hyprlock with my hyprland setup and it's been great.
Recently, however I have had a lot of red screens, and a couple of crashes.
I am running on an NVidia GPU with kernel 6.9 on NixOS.
Here is my hyprlock config:
And if necessary here is my hypridle setup:
Below is my journalctl output, stating that there is a double free or corruption.
journalctl output
``` Jul 22 12:32:13 slaptop hypridle[487689]: [CRITICAL] [core] Disconnected from pollfd id 0 Jul 22 12:32:13 slaptop hypridle[487689]: [LOG] Executing (async) sleep 2 && hyprlock --immediate & disown Jul 22 12:32:13 slaptop hypridle[487689]: [LOG] Process Created with pid 488349 Jul 22 12:32:13 slaptop hypridle[487689]: double free or corruption (!prev) Jul 22 12:32:14 slaptop systemd-coredump[488360]: Process 487689 (hyprlock) of user 1000 dumped core. Module pam_warn.so without build-id. Module pam_env.so without build-id. Module pam_deny.so without build-id. Module libcrypt.so.2 without build-id. Module pam_unix.so without build-id. Module libpciaccess.so.0 without build-id. Module liblzma.so.5 without build-id. Module libxml2.so.2 without build-id. Module libncursesw.so.6 without build-id. Module libdrm_intel.so.1 without build-id. Module libdrm_nouveau.so.2 without build-id. Module libdrm_amdgpu.so.1 without build-id. Module libdrm_radeon.so.1 without build-id. Module libsensors.so.5 without build-id. Module libzstd.so.1 without build-id. Module libxshmfence.so.1 without build-id. Module libxcb-sync.so.1 without build-id. Module libxcb-present.so.0 without build-id. Module libxcb-dri3.so.0 without build-id. Module libxcb-xfixes.so.0 without build-id. Module libxcb-dri2.so.0 without build-id. Module libX11-xcb.so.1 without build-id. Module libbrotlicommon.so.1 without build-id. Module libXdmcp.so.6 without build-id. Module libXau.so.6 without build-id. Module libdatrie.so.1 without build-id. Module libselinux.so.1 without build-id. Module libbrotlidec.so.1 without build-id. Module libbz2.so.1 without build-id. Module libxcb-randr.so.0 without build-id. Module libexpat.so.1 without build-id. Module libxcb-shm.so.0 without build-id. Module libxcb-render.so.0 without build-id. Module libxcb.so.1 without build-id. Module libXrender.so.1 without build-id. Module libXext.so.6 without build-id. Module libX11.so.6 without build-id. Module libpng16.so.16 without build-id. Module libgraphite2.so.3 without build-id. Module libfreetype.so.6 without build-id. Module libpcre2-8.so.0 without build-id. Module libthai.so.0 without build-id. Module libfribidi.so.0 without build-id. Module libfontconfig.so.1 without build-id. Module libpangoft2-1.0.so.0 without build-id. Module libz.so.1 without build-id. Module libsharpyuv.so.0 without build-id. Module libffi.so.8 without build-id. Module libGLdispatch.so.0 without build-id. Module libaudit.so.1 without build-id. Module libgcc_s.so.1 without build-id. Module libstdc++.so.6 without build-id. Module libGLX.so.0 without build-id. Module libdrm.so.2 without build-id. Module libharfbuzz.so.0 without build-id. Module libpango-1.0.so.0 without build-id. Module libpangocairo-1.0.so.0 without build-id. Module libmagic.so.1 without build-id. Module libwebp.so.7 without build-id. Module libjpeg.so.62 without build-id. Module libxkbcommon.so.0 without build-id. Module libOpenGL.so.0 without build-id. Module libhyprlang.so.2 without build-id. Module libEGL.so.1 without build-id. Module libpam.so.0 without build-id. Module hyprlock without build-id. Stack trace of thread 487689: #0 0x00007f8c050a2efc __pthread_kill_implementation (libc.so.6 + 0x8fefc) #1 0x00007f8c05052e86 raise (libc.so.6 + 0x3fe86) #2 0x00007f8c0503b9bf abort (libc.so.6 + 0x289bf) #3 0x00000000004402db _ZL20handleCriticalSignali (hyprlock + 0x402db) #4 0x00007f8c05052f30 __restore_rt (libc.so.6 + 0x3ff30) #5 0x00007f8c050a2efc __pthread_kill_implementation (libc.so.6 + 0x8fefc) #6 0x00007f8c05052e86 raise (libc.so.6 + 0x3fe86) #7 0x00007f8c0503b935 abort (libc.so.6 + 0x28935) #8 0x00007f8c0503c7e6 __libc_message_impl.cold (libc.so.6 + 0x297e6) #9 0x00007f8c050acbd5 malloc_printerr (libc.so.6 + 0x99bd5) #10 0x00007f8c050aeb4c _int_free_merge_chunk (libc.so.6 + 0x9bb4c) #11 0x00007f8c050aee49 _int_free (libc.so.6 + 0x9be49) #12 0x00007f8c050b1613 free (libc.so.6 + 0x9e613) #13 0x00000000004435e5 _ZN9CRendererD1Ev (hyprlock + 0x435e5) #14 0x0000000000442046 _ZN9CHyprlock3runEv (hyprlock + 0x42046) #15 0x0000000000416275 main (hyprlock + 0x16275) #16 0x00007f8c0503d10e __libc_start_call_main (libc.so.6 + 0x2a10e) #17 0x00007f8c0503d1c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a1c9) #18 0x0000000000417305 _start (hyprlock + 0x17305) Stack trace of thread 487726: #0 0x00007f8c0509fc5d pthread_cond_destroy@@GLIBC_2.3.2 (libc.so.6 + 0x8cc5d) #1 0x00000000004326ec _ZNSt10unique_ptrI5CAuthSt14default_deleteIS0_EED1Ev (hyprlock + 0x326ec) #2 0x00007f8c050552f6 __run_exit_handlers (libc.so.6 + 0x422f6) #3 0x00007f8c0505542e exit (libc.so.6 + 0x4242e) #4 0x0000000000440e43 _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN9CHyprlock3runEvEUlvE_EEEEE6_M_runEv (hyprlock + 0x40e43) #5 0x00007f8c052e8683 execute_native_thread_routine (libstdc++.so.6 + 0xe8683) #6 0x00007f8c050a1272 start_thread (libc.so.6 + 0x8e272) #7 0x00007f8c0511cdec __clone3 (libc.so.6 + 0x109dec) Stack trace of thread 487725: #0 0x00007f8c0509dc5e __futex_abstimed_wait_common (libc.so.6 + 0x8ac5e) #1 0x00007f8c050a04c0 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x8d4c0) #2 0x0000000000430a12 _ZN5CAuth12waitForInputEv (hyprlock + 0x30a12) #3 0x00000000004315a3 _Z4conviPPK11pam_messagePP12pam_responsePv (hyprlock + 0x315a3) #4 0x00007f8c05d75e7e pam_vprompt (libpam.so.0 + 0x8e7e) #5 0x00007f8c05d760ba pam_prompt (libpam.so.0 + 0x90ba) #6 0x00007f8c05d72623 pam_get_authtok_internal (libpam.so.0 + 0x5623) #7 0x00007f8c03c28048 pam_sm_authenticate (pam_unix.so + 0x4048) #8 0x00007f8c05d70dab _pam_dispatch (libpam.so.0 + 0x3dab) #9 0x00007f8c05d7067f pam_authenticate (libpam.so.0 + 0x367f) #10 0x0000000000431e58 _ZN5CAuth4authEv (hyprlock + 0x31e58) #11 0x00000000004321f3 _ZNSt6thread11_State_implINS_8_InvokerISt5tupleIJZN5CAuth5startEvEUlvE_EEEEE6_M_runEv (hyprlock + 0x321f3) #12 0x00007f8c052e8683 execute_native_thread_routine (libstdc++.so.6 + 0xe8683) #13 0x00007f8c050a1272 start_thread (libc.so.6 + 0x8e272) #14 0x00007f8c0511cdec __clone3 (libc.so.6 + 0x109dec) ELF object binary architecture: AMD x86-64 Jul 22 12:32:15 slaptop hypridle[488454]: [CRITICAL] Couldn't connect to a wayland compositor ```I am most worried about the fact that it could not connect to a wayland compositor.
Any thoughts on this?