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

[intelfx]

trafficstars

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]

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.

[intelfx]

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.

How much time is that in absolute terms?

On my system, suspending the fingerprint reader — when it is the last active USB device — means almost a 3 hour battery life difference (5W vs 4W in idle, with ideal battery capacity of 57 W·h). What exactly is on the other side of this compromise?

[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.

[intelfx]

I see. Thanks for the explanation, @uunicorn. I guess you can close the issue then — or leave it as a reminder in case someone comes up with a workable idea, I don't know.

Do you have any idea, per chance, what does the Windows driver do in this regard? Does it just ignore USB selective suspend or maybe it does something nontrivial to have the cake and eat it, that you were not able to replicate?

[uunicorn]

Do you have any idea, per chance, what does the Windows driver do in this regard?

Sorry, I haven't tried to figure out this aspect specifically, but the way I remember, PnP framework calls OnPrepareHardware for the device during the bus enumeration, which results in a USB device to be open and go to D0 power state. The driver then reacts to a D0 event by establishing the TLS state. So in theory if something would cause the device to change the power state to a lower one and then back to D0, the diver would re-establish the state correctly and automatically, however I never saw the driver to actively cause the device to switch to a lower power state or even close the USB device handle. It could be that my sandbox was not waiting long enough for that to happen.