You are not logged in.
Since I started to use Plasma login manager most of the times I get black screen on initial startup. Before reaching the login manager I can see the Arch splashcreen on the monitor. If I switch to tty2 I can also see that, but most of the times the login manager's screen is not visible.
Workaround is to either switch between tty2 and tty1 a couple of times, or turn off the monitor once or twice. After these I can always see the screen.
I have NVIDIA GPU (RTX 2070 Super), based on the Wiki I tried to modify the DRM kernel mode setting, set early module loading, but so far nothing helped.
I'm posting systemd journal logs from my recent boot, where the issue happened: Termbin link
I turned my monitor off/on two times: 10:19:58, 10:20:57 and after the second time it worked.
One additional note is that as far as I can tell, I only see this issue after power on, after a 'systemctl reboot' I think I never saw this.
Last edited by Elkor1991 (Yesterday 08:38:39)
Offline
only nvidia vga, nvidia loads in the initramfs,
Oct 29 10:19:29 DESKTOP-ROBI plasmalogin[481]: Message received from greeter: Connect
Oct 29 10:19:29 DESKTOP-ROBI plasma-login-greeter[636]: Reading session (1) from "/usr/share/wayland-sessions/plasma.desktop"
Oct 29 10:19:29 DESKTOP-ROBI plasma-login-greeter[636]: QDBusConnection: name 'org.freedesktop.UPower' had owner '' but we thought it was ':1.26'
Oct 29 10:19:35 DESKTOP-ROBI plasma-login-greeter[636]: There are no outputs - creating placeholder screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 29 10:21:00 DESKTOP-ROBI plasmalogin[481]: Message received from greeter: Login
Oct 29 10:21:00 DESKTOP-ROBI plasma-login-greeter[636]: Message received from daemon: LoginSucceeded
Oct 29 10:21:00 DESKTOP-ROBI plasma-login-greeter[636]: There are no outputs - creating placeholder screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Oct 29 10:21:06 DESKTOP-ROBI plasmalogin[481]: Greeter stopping...for OUT in /sys/class/drm/card*; do echo $OUT; edid-decode $OUT/edid; echo "================="; doneYou'll need https://archlinux.org/packages/extra/x86_64/v4l-utils/
Offline
Offline
1440p@60Hz by default on displayport, supports VRR - doesn't seem prone to stumble the handshake.
Does it help if you copy and inject the EDID, https://wiki.archlinux.org/title/Kernel … s_and_EDID ?
You can just
sudo cp /sys/class/drm/card0-DP-2/edid /usr/lib/firmware/Offline
I copied the edid file.
If I understand correctly, I don't have to specify the edid_firmware in the kernel command line, right? It's enough to copy the file to /usr/lib/firmware.
Offline
No, you do have to specify the edid_firmware to inject it (notably the filename is complete freeform and you might want to indicate the output to which to assign the edid as well)
Offline
Ok, sorry, I misunderstood that part then.
Now I copied the file to firmware/edid/edid.bin and also added it to cmdline and included the file in initramfs.
Can I somehow check if that edid file is used?
In journalctl I can see this, I'm not sure if that's enough:
Oct 30 10:46:36 archlinux kernel: Command line: drm.edid_firmware=edid/edid.bin nvidia-drm.modeset=1 nvidia-drm.fbdev=1 initcall_blacklist=simpledrm_platform_driver_init root=UUID=5d2a9725-8024-4ecb-8ad1-0db92a7bc33f rw
Oct 30 10:46:36 archlinux kernel: Kernel command line: drm.edid_firmware=edid/edid.bin nvidia-drm.modeset=1 nvidia-drm.fbdev=1 initcall_blacklist=simpledrm_platform_driver_init root=UUID=5d2a9725-8024-4ecb-8ad1-0db92a7bc33f rwBy the way, the first couple of shutdown -> power on tests worked now.
Offline
Can I somehow check if that edid file is used?
Should™ show up in the journal, yes.
By the way, the first couple of shutdown -> power on tests worked now.
\o/
In case this holds and in general please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
I only see the kernel command line logs in the journal, nothing else about edid. But hopefully it works.
Thanks for the help!
Offline
You can try to issue a bogus path - at least that should™ get you an error, but this usually works as expected ![]()
Offline
Unfortunately the issue triggered again: journal
I also tried to use false path for the edid to check if it really gets used and I think it works, because when false path is used I got this error:
Oct 31 09:29:59 archlinux kernel: nvidia 0000:01:00.0: Direct firmware load for false/path.bin failed with error -2
Oct 31 09:29:59 archlinux kernel: nvidia 0000:01:00.0: [drm] *ERROR* [CONNECTOR:828:DP-1] Requesting EDID firmware "false/path.bin" failed (err=-2)1440p@60Hz by default on displayport, supports VRR - doesn't seem prone to stumble the handshake.
I don't know if this matters, but refresh rate is set to 360Hz
Offline
Does the output only shut down when starting plasma-login-manager or does it remain off during the entire boot?
Offline
Only when plasma-login-manager is starting. Prior to that I can see the boot and arch splash screen and the boot log screen as well.
I'm also uploading a successful boot process, where Plasma login manager's output show up the first time, without any problem (this happened right now after a power off/on sequence): journal
Offline
Does it help to artificially delay the start of plasma-loginmanager by eg 3 seconds?
https://bbs.archlinux.org/viewtopic.php … 2#p2305642
Otherwise try to force the DM/kwin to run at 60Hz and/or disable VRR
Offline
I tried the delay solution first (+5s) but it did not help, issue triggered multiple times.
Now I changed the refresh rate to 60Hz (VRR was disabled by default) and so far so good. Did not encounter the same problem. If really the high refresh rate is causing the problem, do you think there is any solution for this, to keep using the higher refresh rate, but also solving the problem?
Offline
Do you have access to alternative cables?
360Hz seems excessive and typically would be a technical detail of VRR, is it stable at 120Hz?
Offline
Unfortunately no access to alternative cable, at least for now. If the issue will be persistent with 120Hz I will get one.
For now I switched to 120Hz and also turned on VRR.
First few tries were ok.
Offline