hyprwm
Screen stays off after fingerprint auth
Regression?
No
Hyprlock Info and Version
Hyprlock version v0.8.2
Hyprlock config
background {
color = rgb(16, 16, 16)
}
auth {
pam:enabled = true
fingerprint:enabled = true
}
animations {
enabled = false
}
general {
ignore_empty_input = true
hide_cursor = true
}
input-field {
size = 300, 64
outline_thickness = 2
dots_size = 0.2
dots_spacing = 0.2
dots_center = true
outer_color = rgba(0, 0, 0, 0)
inner_color = rgba(0, 0, 0, 0.5)
font_color = rgb(200, 200, 200)
fade_on_empty = false
font_family = Hack
placeholder_text = Password
fail_text = $FAIL
hide_input = false
position = 0, -256
halign = center
valign = center
}
# HOUR
label {
text = cmd[update:1000] echo "$(date +"%H")"
color = rgba(255, 255, 255, 0.6)
font_size = 200
font_family = Hack Bold
position = 0, -150
halign = center
valign = top
}
# MINUTE
label {
text = cmd[update:1000] echo "$(date +"%M")"
color = rgba(255, 255, 255, 0.6)
font_size = 200
font_family = Hack Bold
position = 0, -400
halign = center
valign = top
}
Compositor Info and Version
System/Version info
Hyprland 0.50.0 built from branch at commit c4a4c341568944bd4fb9cd503558b2de602c0213 (version: bump to 0.50.0).
Date: Wed Jul 16 09:33:42 2025
Tag: v0.50.0, commits: 6279
built against:
aquamarine 0.9.1
hyprlang 0.6.3
hyprutils 0.8.1
hyprcursor 0.1.12
hyprgraphics 0.1.5
no flags were set
System Information:
System name: Linux
Node name: mxaddict-t14
Release: 6.16.0-rc6
Version: #1 SMP PREEMPT_DYNAMIC Tue Jul 15 05:44:35 PST 2025
GPU information:
c4:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] HawkPoint2 [1002:1901] (rev d1) (prog-if 00 [VGA controller])
os-release: NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
plugins:
Description
When unlocking via fingerprint (without touching mouse/keyboard) screen does not turn on (have to press a key or move mouse to turn on screen.
This might be a hypridle issue, but not sure.
How to reproduce
Wait for hypridle to turn off screen Use fingerprint scranner to login This will login, but screen will stay off until you press a key or move mouse
Crash reports, logs, images, videos
No response
Yup, got reported somewhere else as well I think.
Fixing this will require some workaround in hyprland. The compositor currently has no idea about your fingerprint reader or fprintd, so it doesn't wake up.
It might make sense to have hyprlock tell dbus that the system is awake when it unlocks (Not sure how that would be done though)
Or maybe hypridle can watch for a session-unlock event and wake the system.
It might make sense to have hyprlock tell dbus that the system is awake when it unlocks
Nah the compositor needs to wake and Hyprland doesn't integrate with dbus like that.
Or maybe hypridle can watch for a session-unlock event and wake the system.
Possibly. Or just directly within Hyprland. When unlock, post idle activity. Would be an easy workaround. But sort of a hack.
I’ve been trying to solve this and found that if I replace https://github.com/hyprwm/hyprlock/blob/71691634e4ba32017325d92eb1870b32f63d9189/src/renderer/Renderer.cpp#L620 with g_pHyprlock->releaseSessionLock(), I can simply run hyprctl dispatch dpms on in a post-unlock script to turn on the display after fingerprint auth.
Without the patch the unlock gets delayed until the screen is turned on by pressing a key or moving the cursor.
@JManch ?? then just
hyprlock && hyprctl dispatch dpms on.
@PaideiaDilemma this doesn't work because Hyprlock does not unlock if you authenticate with the screen off (probably due to Hyprland not ticking animations with the screen off so the callback I shared above never runs). This is only possible with fingerprint auth because, typically, typing in your password would turn on the screen.
Yeah but you proposed change is equivalent to that.
Not sure I follow. To be clear this is the behavior I want: when Hyprlock is running and DPMS is off, touching the fingerprint sensor should unlock the session.
The current behavior is that session unlock is delayed until DPMS turns on and the animation system ticks. So the user is required to either press their keyboard or move their cursor.
I can fix it by patching Hyprlock to instantly call releaseSessionLock() instead of calling it after the fade out opacity animation but ofc this isn't a proper solution cause it breaks the opacity fade out animation when the display is on.
A proper solution would maybe skip the opacity fade out animation if the display is off?
Sorry, now I get it. I didn't read properly.
When dpms is off, hyprlock is idle and the animation doesn't finish. That is not good behavior, but it also makes sense why it happens. But idk if we want to fix that. I would like to just solve that in hyprlock with some wayland mechanism instead of dbus. Ideally we can wake when any fingerprint verification happens - so also on failure - and let the animation do it's thing.
But I am not entirely sure about this yet, since this shouldn't be Hyprland exclusive I feel like it might be tricky/hacky find a way to trigger idle resume in a compatible way.
So maybe we need to add a timer for some duration after the fade-out animation proceeded and call releaseSessionLock() there to allow for a && hyprctl dispatch dpms on workaround.
@PaideiaDilemma can't we have some "dummy input" like a 1 px mouse movement whenever hyprlock is unlocked via fp? that would reset the idle timer
yeah we could just use wlr virtual pointer protocol Although I am currently porting hyprlock to hyprtoolkit and this is something that would need to be part of hyprtoolkit, as all the wayland stuff is abstracted there. So it's not on my todo list currently. Also just conceptually I don't think the fingerprint api client should need to worry about that. But it seems very unlikely that there will be any solution on the fprintd side.
Also just conceptually I don't think the fingerprint api client should need to worry about that. But it seems very unlikely that there will be any solution on the fprintd side.
I totally agree. But still, the thing here is that this issue is very unlikely to arise in scenarios that are not a lockscreen (which very often appears as a result of idle). Meaning that it might make sense for a lockscreen to implement a workaround
I think the solution to this would be hyprlock; hyprctl dispatch forceidle 0
Was trying to do stuff with fingerprint unlock and came across this, which matches the behavior I'm seeing on my system. Nothing much to add other than, yes, a mechanism for waking up the display on any kind of fingerprint interaction would be great. Failing that, firing the unlock signal even when DPMS is off would be a nice temporary patch, since we could then use on_unlock_cmd = hyprctl dispatch forceidle 0 in hypridle (which would at least wake up the screen upon successful unlock).
Cross-linking to https://github.com/hyprwm/hypridle/issues/178#issuecomment-3570325554 and https://github.com/hyprwm/hypridle/issues/112#issuecomment-3598421446 for ease of reference.
