a/website
1
2
Fork 1
Code Issues Pull requests Projects Releases Wiki Activity

The bug is a bit related to Plasma 6 I guess
All checks were successful
ci/woodpecker/push/woodpecker Pipeline was successful
Details

Browse source
This commit is contained in:
Anthony Wang 2024-03-19 22:24:04 -04:00
parent 96244691a2
commit 42992f35e3
Signed by: a
SSH key fingerprint: SHA256:B5ADfMCqd2M7d/jtXDoihAV/yfXOAbWWri9+GdCN4hQ
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
content/posts/plasma-6-fingerprint-bug.md
View file

@ -48,7 +48,7 @@ Requires=dev-fingerprint.device
The `suspend.target` is important because the `dev-fingerprint.device` seems to initially be active right after the wake-up starts, but then gets deactivated and reactivated during wake-up. Thus, we have to wait until after the wake-up finishes, then wait for `dev-fingerprint.device` to be active.
So, to recap, the bug actually has nothing to do with KDE Plasma. I guess it's an `fprintd` problem since maybe it should wait a bit until the USB devices are all initialized? I'm not sure. The only reason I ran into this bug is because previously, Plasma required pressing enter first to show the fingerprint login prompt, but in Plasma 6 is immediately shows the fingerprint login prompt. This causes a race condition with USB device initialization, so the bug doesn't always happen if the USB devices win the race.
So, to recap, the bug actually has isn't KDE Plasma's fault. I guess it's an `fprintd` problem since maybe it should wait a bit until the USB devices are all initialized? I'm not sure. The only reason I ran into this bug is because previously, Plasma required pressing enter first to show the fingerprint login prompt, but in Plasma 6 is immediately shows the fingerprint login prompt. This causes a race condition with USB device initialization, so the bug doesn't always happen if the USB devices win the race.
Another potential problem is that `fprintd` waits around 30 seconds after a successful login before quitting, so sleeping and waking up and sleeping and waking up can cause the bug to reappear during the second wake-up, but I don't think I'd ever run into this corner case except while debugging this bug. When debugging, I had to manually run `sudo killall fprintd` between sleep-wake up tests.