-
-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ON_AC on desktop PCs - unset when iPhone gets USB attached #183
Comments
This was referenced Apr 6, 2022
FYI, the script doesn't check for the |
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
** 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:
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:
hibernationLoopDmesgPatched.log
udevd.log
udevadm.log
laptop-mode-tools.log
About the logs
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.
The text was updated successfully, but these errors were encountered: