rickysarraf/laptop-mode-tools

ON_AC on desktop PCs - unset when iPhone gets USB attached

Opened this issue · 2 comments

labre commented

** Problem description **
ON_AC gets unset on desktop PCs as soon as the apple-mfi-fastcharge module is loaded and an iPhone is USB attached and unlocked.

This is usually unnoticed by desktop users, because most of them have the auto-hibernate module disabled. I have it enabled though, because I use my hard drive sometimes externally on laptops, so this was hard to miss. It happens as soon as the iPhone is either attached and has been unlocked before or it is unlocked the first time. The iPhone displays a notification to unlock the device for using the USB utility before it is first unlocked. It will then give the connected sound twice in short order.

The apple-mfi-fastcharge driver classifies itself as battery, which is wrong and will be probably patched to be classified as a USB charger 1, however laptop-mode-tools still fails to set ON_AC, because it will unset it as soon as there is any /sys/class/power_supply/*/type present. 2

To Reproduce
Steps to reproduce the behavior:

  1. Do not blacklist apple-mfi-fastcharge
  2. Attach an iPhone via USB to a desktop PC and unlock it once
  3. Watch the hibernation loop unfold

Expected behavior
Not hibernating or in other words keeping the ON_AC value at 1 with desktops.

Screenshots
Not much to show. The logs are more relevant here, I guess.

Important Information:

About the logs

  • The hibernationLoopDmesgPatched.log was created with a 5.17.1 kernel patched with the patch from 1. Just syslog-ng and systemd-udevd were running and the kernel was booted with init=/bin/bash.
  • The udevd.log and udevadm.log were created in the same context, showing a few hibernations.
  • The laptop-mode-tools.log was created with the patched kernel in a normal desktop boot to i3 with the auto-hibernate module already disabled.

Additional context

At least the sysfs battery detection could possibly check for missing nodes, which would account for sys nodes from broken drivers like the mentioned one. I will check with an unpatched kernel, whether the nodes could indicate that. However workarounds for broken drivers might be undesired by you, so I need a quick info, whether I should look into that. I would step up to send a PR for this issue, since I’m quite used to shell programming. Just give me a day or two, but please give me the short info, whether I should include a workaround for falsely advertised battery type power_supplies.

hadess commented

FYI, the script doesn't check for the scope of batteries, so any device with a battery that gets attached to the system (say, an Apple Bluetooth mouse, a Logitech keyboard, or in this case an iOS device) will break the script.

labre commented

Which can be "Unknown", "System" or "Device" according to drivers/power/supply/power_supply_sysfs.c. I’ll prepare a commit to check just for system batteries.