Running python-validity prevents USB autosuspend (06cb:009a, Lenovo X1C6)

python3-validity.service is running:

# systemctl start python3-validity

# systemctl is-active python3-validity
active

# cat /sys/bus/usb/devices/1-9/idVendor
06cb

# sleep 10

# grep . -r /sys/bus/usb/devices/1-9/power
/sys/bus/usb/devices/1-9/power/runtime_active_time:862019
/sys/bus/usb/devices/1-9/power/wakeup:disabled
/sys/bus/usb/devices/1-9/power/active_duration:862064
/sys/bus/usb/devices/1-9/power/runtime_active_kids:0
/sys/bus/usb/devices/1-9/power/connected_duration:941124
/sys/bus/usb/devices/1-9/power/persist:1
/sys/bus/usb/devices/1-9/power/runtime_usage:1
/sys/bus/usb/devices/1-9/power/runtime_status:active
/sys/bus/usb/devices/1-9/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/1-9/power/async:enabled
/sys/bus/usb/devices/1-9/power/runtime_suspended_time:78841
/sys/bus/usb/devices/1-9/power/runtime_enabled:enabled
/sys/bus/usb/devices/1-9/power/control:auto
/sys/bus/usb/devices/1-9/power/level:auto
/sys/bus/usb/devices/1-9/power/autosuspend:2

python3-validity.service is not running:

# systemctl stop python3-validity.service

# sleep 10

# grep . -r /sys/bus/usb/devices/1-9/power
/sys/bus/usb/devices/1-9/power/runtime_active_time:873841
/sys/bus/usb/devices/1-9/power/wakeup:disabled
/sys/bus/usb/devices/1-9/power/active_duration:873887
/sys/bus/usb/devices/1-9/power/runtime_active_kids:0
/sys/bus/usb/devices/1-9/power/connected_duration:955394
/sys/bus/usb/devices/1-9/power/persist:1
/sys/bus/usb/devices/1-9/power/runtime_usage:0
/sys/bus/usb/devices/1-9/power/runtime_status:suspended
/sys/bus/usb/devices/1-9/power/autosuspend_delay_ms:2000
/sys/bus/usb/devices/1-9/power/async:enabled
/sys/bus/usb/devices/1-9/power/runtime_suspended_time:81289
/sys/bus/usb/devices/1-9/power/runtime_enabled:enabled
/sys/bus/usb/devices/1-9/power/control:auto
/sys/bus/usb/devices/1-9/power/level:auto
/sys/bus/usb/devices/1-9/power/autosuspend:2

It would appear that a running instance of the python-validity dbus service prevents USB autosuspend from working (regardless of the fact that the included udev rule explicitly enables runtime PM on the fingerprint reader device).

Maybe it would make sense to release the device internally after a timeout and reacquire it every time a bus request is made?

Or, alternatively, maybe turn the architecture upside-down and have the open-fprintd manager invoke and enumerate drivers in turn until a device is found?

[uunicorn]

How much time is that in absolute terms?

It is about 3 seconds.

What exactly is on the other side of this compromise?

Slow-ish initialization time was not the only problem with initialization on demand. Performing TLS initialization too often seems to be causing device to lock-up. I don’t really understand what exactly is causing it, nor I can quantify the “too often” part. During this lock-up a device is refusing TLS setups. Rebooting into Windows, powering off/on, even factory reset via BIOS - nothing seems to help. However after about 24h problem just magically goes away. Very odd.

[uunicorn]

It is by design. Allowing the device to autosuspend resets the TLS state and I can type my password faster than that state can be re-established on my 0097 device.

Or, alternatively, maybe turn the architecture upside-down and have the open-fprintd manager invoke and enumerate drivers in turn until a device is found?

Original fprintd daemon is designed that way. It is linked against libfprintd (which contains actual FP drivers) and it is activated by Gnome or a PAM module via client DBus API. Each time it activates, it enumerates the bus and initializes the device. One reason to introduce the back-end DBus API and the open-fprintd service was to turn the fprintd architecture upside-down so that the driver can have its own life-cycle and keep the device open and initialized as long as it is connected.