Fingerprint auth breaks completely on suspend/resume WITHOUT python-validity

[ipg0]

Regression?

No

Hyprlock Info and Version

Hyprlock version 0.5.0

Hyprlock config

general {
  hide_cursor = true
  enable_fingerprint = true
}

background {
  monitor =
  path = $HOME/Pictures/Wallpapers/alien-sky-purple.png
}

label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 70%
  font_family = "Ubuntu Nerd Font"
  font_size = 64
  text = cmd[update:1000] echo "<b>$(date +'%H:%M')</b>"
}

label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 67%
  font_family = "Ubuntu Nerd Font"
  font_size = 20
  text = cmd[update:1000] echo "<b>$(date +'%a %d %b')</b>"
}

label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 64%
  font_family = "Ubuntu Nerd Font"
  font_size = 11
  text =    $LAYOUT
}




label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 50%
  font_family = "Ubuntu Nerd Font"
  font_size = 18
  text = 󰈷   $FPRINTMESSAGE
}

label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 47%
  font_family = "Ubuntu Nerd Font"
  font_size = 11
  text = or
}

input-field {
  monitor =
  halign = center
  valign = bottom
  position = 0, 40%
  outer_color = rgb(9d37fc) rgb(ed1153) 45deg
  check_color = rgb(0f47ff) rgb(cc00ff) 45deg
  fail_color = rgb(ed1153) rgb(cd2097) 45deg
  inner_color = rgb(1b1b1b)
  font_color = rgb(ffffff)
  size = 20%, 5%
  fade_on_empty = false

  font_family = "Ubuntu Nerd Font"
  fail_text = <b>$FAIL ($ATTEMPTS times)</b>
  placeholder_text = <b>Password</b>
  shadow_passes = 2
  shadow_size = 10
  shadow_boost = 0.7
}

label {
  monitor =
  halign = center
  valign = bottom
  position = 0, 2%
  font_family = "Ubuntu Nerd Font"
  font_size = 14
  text =    $DESC ($USER)
}

Compositor Info and Version

System/Version info

Hyprland 0.45.2 built from branch  at commit 12f9a0d0b93f691d4d9923716557154d74777b0a  ([gha] Nix: update inputs).
Date: Tue Nov 19 21:47:18 2024
Tag: v0.45.2, commits: 5451
built against aquamarine 0.5.0


flags set:
debug


System Information:
System name: Linux
Node name: prometheus
Release: 6.12.1-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Fri, 22 Nov 2024 16:04:27 +0000


GPU information: 
00:02.0 VGA compatible controller [0300]: Intel Corporation Meteor Lake-P [Intel Graphics] [8086:7d45] (rev 08) (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:
  hyprgrass by horriblename ver v0.8.2

Description

This is NOT a duplicate of #531 - everyone there is using python-validity and open-fprintd, and it seems like the issue is with that.

I am using regular fprintd and hyprlock's fingerprint functionality is breaking on suspend.
Hyprlock is set up to run before suspend via hypridle.

How to reproduce

• run hyprlock on suspend
• resume - hyprlock hangs up for about 15-20 seconds
• try to authenticate with the fingerprint sensor - nothing happens

Crash reports, logs, images, videos

When I just run hyprlock for the first time, it works correctly.

When the laptop suspends and then resumes, hyprlock hangs up for about 10 seconds and fingerprint auth does not work. The logs contain the following:

[LOG] fprint: claimed device
[LOG] fprint: started verifying
[LOG] fprint: finger selected: any
[LOG] fprint: PrepareForSleep (start: true)
[WARN] fprint: could not stop verifying, [org.freedesktop.DBus.Error.Timeout] Connection timed out
[LOG] fprint: PrepareForSleep (start: false)
[LOG] Authenticating
[WARN] fprint: could not start verifying, [net.reactivated.Fprint.Error.AlreadyInUse] Verification already in progress

fprintd logs snow nothing.

Upon further investigation, it seems to me that there might be something wrong with DBus system bus just before suspend.

dbus-monitor --system logs are below (relevant section):

signal time=1733674829.567336 sender=:1.0 -> destination=(null destination) serial=2631 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitNew
   string "systemd-suspend.service"
   object path "/org/freedesktop/systemd1/unit/systemd_2dsuspend_2eservice"
signal time=1733674829.567345 sender=:1.0 -> destination=(null destination) serial=2632 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitNew
   string "suspend.target"
   object path "/org/freedesktop/systemd1/unit/suspend_2etarget"
signal time=1733674829.567419 sender=:1.0 -> destination=(null destination) serial=2633 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
   string "sleep.target"
   object path "/org/freedesktop/systemd1/unit/sleep_2etarget"
signal time=1733674829.567429 sender=:1.0 -> destination=(null destination) serial=2634 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
   string "systemd-suspend.service"
   object path "/org/freedesktop/systemd1/unit/systemd_2dsuspend_2eservice"
signal time=1733674829.567436 sender=:1.5 -> destination=(null destination) serial=191 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep
   boolean true
signal time=1733674829.567441 sender=:1.5 -> destination=(null destination) serial=192 path=/org/freedesktop/login1; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged
   string "org.freedesktop.login1.Manager"
   array [
      dict entry(
         string "LidClosed"
         variant             boolean true
      )
   ]
   array [
   ]
signal time=1733674829.567457 sender=:1.5 -> destination=:1.42 serial=193 path=/org/freedesktop/login1/session/_31; interface=org.freedesktop.login1.Session; member=PauseDevice
   uint32 13
   uint32 74
   string "gone"
method call time=1733674829.567777 sender=:1.262 -> destination=net.reactivated.Fprint serial=11 path=/net/reactivated/Fprint/Device/1; interface=net.reactivated.Fprint.Device; member=VerifyStop
method return time=1733674829.567797 sender=:1.5 -> destination=:1.42 serial=194 reply_serial=63
signal time=1733674829.567802 sender=:1.0 -> destination=(null destination) serial=2635 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitRemoved
   string "suspend.target"
   object path "/org/freedesktop/systemd1/unit/suspend_2etarget"

[ipg0]

Since hyprlock does not provide any further details on the error, I can't figure out whether the "connection" that is being "timed out" is the one of hyprlock to the system bus, or the one of fprintd to the sensor (which is a Synaptics, Inc. 06cb:00f9), or any other "connection".

How can I find that out?

[PaideiaDilemma]

To me it seems like the root cause is that we fail to stop verification and that causes the error when we call startVerify again.

Adding some additional logging might help here, but i will look into to code and see if i find anything later today ;)

[ipg0]

@PaideiaDilemma Yeah, that seems like the case. The question is why it fails to stop verifying.

[PaideiaDilemma]

@ipg0
The problem is the PauseDevice signal with the argument "gone".
At that point we are already suspending, but we havn't stopped fprintd, as VerifyStop is part of that routine.
Can you post the entire dbus-monitor --system log during which hyprlock is running?

[ipg0]

@PaideiaDilemma sure, here it is. There's like a couple seconds before/after suspend as well.

Upd: GitHub never finishes uploading for whatever reason, here's a gist:
https://gist.github.com/ipg0/d5aa7b85c9899f7813848885771f300f

[ipg0]

@PaideiaDilemma I tried to add LidSwitchIgnoreInhibited=no to logind config. The fingerprint auth after suspend now works about half the time.

When it doesn't, it fails with a different error (which is much clearer):

[WARN] fprint: could not claim device, [net.reactivated.Fprint.Error.Internal] Open failed with error: USB error on device 06cb:00f9 : No such device (it may have been disconnected) [-4]

It seems now that there is a race condition between the sensor/internal hub powering up and hyprlock trying to claim the sensor, and when hyprlock wins, it fails to do so. Is there any way to wait for the device to reconnect after resume?

I have confirmed that the sensor is disconnecting and reconnecting during the suspend/resume cycle.

[PaideiaDilemma]

@ipg0 can you try this patch?

patch.txt

This just retries to Claim the device. Honestly don't really know what else to do about that problem. And I am not sure if everything is right, because we never explicitly "Release" the device when we go to sleep. So I am unsure why we need to reclaim it.

Also thanks for the pointer to LidSwitchIgnoreInhibited. We should probably add that to the wiki, once we resolved this race.

[ipg0]

@PaideiaDilemma I'll try this later today, thank you

[rzru]

hey folks, any updates on this? looks like I'm having the same issue.

I'm just using the raw fprint and after the suspend the fingerprint auth does not work.

[ipg0]

@rzru wdym by raw fprint? As far as I know, fprint has two APIs - a PAM module and a DBus API.
The PAM module has a timeout, which doesn't allow it to keep the sensor scanning after suspend. Hyprlock uses the DBus API.

@PaideiaDilemma As per the bug in question, it seems to have disappeared even without the patch after I removed hyprlock from the hypridle config for some time and then added it back. I have no idea why that could've happened, since iirc I didn't even run an update within the timeframe.

[PaideiaDilemma]

@ipg0

As per the bug in question, it seems to have disappeared even without the patch after I removed hyprlock from the hypridle config for some time and then added it back. I have no idea why that could've happened, since iirc I didn't even run an update within the timeframe.

Ahh that makes a lot of sense.
We claim the fingerprint device before locking the system.
So when hypridle launches hyprlock a second time, it claims the device, but is unable to lock the session because it is already locked. Turns out there is an early exit where we don't release the device.

[Jackaed]

I'm still experiencing this - I'm unsure as to whether it's a firmware issue on my side or not. I'll do some testing, but I'd like to know if other people have actually had this fix be successful - if they have, then I can be fairly confident it's on my side.