Switching users consistently causes black screen with cursor

Help
, ,
1

Context

Per the undermentioned, I’ve experienced the display becoming black with merely a cursor when attempting to switch user at least twice over the last few months: [1]

Question

What logs should I acquire to provide actionable information on this?

Diagnosis

I ask because when looking in journalctl -b -1 -e [2], ignoring the constant repetitions of unrelated log spam…

  1. amdgpu 0000:59:00.0: [drm] ERROR lttpr_caps phy_repeater_cnt is 0x0, forcing it to 0x80.

    [3]

  2. amdgpu 0000:59:00.0: [drm] Cannot find any crtc or sizes

    [4]

…I see repetitions of:

Mar 26 22:43:44 Beedell.RokeJulianLockhart.desktop.SSV2AY kwin_wayland[1793]: kwin_core: Failed to open drm node: "/dev/dri/card0"
Mar 26 22:43:47 Beedell.RokeJulianLockhart.desktop.SSV2AY pcscd[21891]: 10329108 ../src/auth.c:166:IsClientAuthorized() Process 152016 (user: 1000) is NOT authorized for action: access_pcsc
Mar 26 22:43:47 Beedell.RokeJulianLockhart.desktop.SSV2AY pcscd[21891]: 00000068 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client

At least 40 of these fill journalctl -b -1 -e, solely after SystemD begins to stop services. It solely appears once in -b 0, per | grep access_pcsc:

Mar 26 22:46:40 Beedell.RokeJulianLockhart.desktop.SSV2AY pcscd[2813]: 00000000 ../src/auth.c:166:IsClientAuthorized() Process 2668 (user: 999) is NOT authorized for action: access_pcsc
Mar 26 22:46:40 Beedell.RokeJulianLockhart.desktop.SSV2AY pcscd[2813]: 00000049 ../src/winscard_svc.c:357:ContextThread() Rejected unauthorized PC/SC client

  1. bugs.kde.org/show_bug.cgi?id=439873#c35 ↩︎

  2. -1 45d2eb9e8d004e8aa4d029d194ccbbc5

    ↩︎

  3. discussion.fedoraproject.org/t/144259/2 ↩︎

  4. gitlab.freedesktop.org/drm/amd/-/issues/3248#note_2383118 ↩︎

2

Reproduction

Actually, this consistently reproduces. I’m forced to RESET_SW it:

…which appears to have caused GRUB2 to undo my resolution override:

IMG_20250326_232048
IMG_20250326_2320481920×1440 132 KB

It doesn’t reproduce on my brother’s installation:

3

Hi - I don’t know if it answers anything, but just to check and possibly help narrow down where to search: does your brother’s device have the same kind of smart card that yours has? I’m thinking of whatever is causing the “Rejected unauthorized PC/SC client” error.

1 Like
4

@johnandmegh, the error is caused by a smart card? If so, I don’t believe even mine has one installed. I have an SD Card reader attached via USB-C to a hub, but it doesn’t have a card inside.

I’ll definitely check whether his journalctl contains the same logs, though. Apologies for not doing so beforehand. Thanks.

5

I don’t necessarily know if it’s caused by a smart card, but two of the three lines that keep repeating are from code in that project: GitHub - LudovicRousseau/PCSC: pcsc-lite: PC/SC implementation

It might also be worth checking to make sure that /dev/dri/card0 refers to your actual intended graphics card - maybe there’s some race-type condition there where sometimes the wrong graphics device is getting picked first? ex. in my desktop, the device for AMD integrated graphics is /card1, although nothing is connected to it, and the NVIDIA card is /card2. I…don’t know how it works on mine, I guess it just does? :slight_smile: But I’m sure there are ways to force one to be chosen if needed.

1 Like
6

@johnandmegh, the logs don’t appear on my laptop (an FW16), nor my brother’s desktop (an ASRock X670E, too), even after performing “Switch user”. Checking their journalctls was definitely useful confirmation that PCSC’s errata are either a definitive symptom or cause. On that note, thank you for explaining what it is. I’ve asked at its repository:

I did have a Polish friend using fedora too, who experienced something similar with his secondary NVIDIA GPU. That occurring to me could explain why bugzilla.rpmfusion.org/show_bug.cgi?id=6713#c24 affects me too.

Anyway, I’ll try. Thanks.

7

I’ve ascertained exactly what reproduces this:

#!/usr/bin/env sh
qdbus --system org.freedesktop.DisplayManager /org/freedesktop/DisplayManager/Seat0 org.freedesktop.DisplayManager.Seat.SwitchToGreeter

Screenshot_20250327_162613
Screenshot_20250327_1626131274×251 21.2 KB

It’s demonstrated something interesting - if I invoke it from a terminal, the OS instead hangs without ever transitioning to the black screen:

8

I’ve filed bugs.kde.org/show_bug.cgi?id=502082, because, whatever the cause, although the OS shouldn’t get into this kind of state when the DE fails, the DE also shouldn’t allow itself to get into this state.