suggestion: improvements to battery status detection

[CipherChen]

Due to power line may be loose coupled or unstable, unplug and replug may happen frequently when device is shifted.
In this situation, when "enable dark mode when device is unplugged" is enabled, dark mode would be toggled again and again.
So I suggest adding a delay time (like 10 seconds or user defined time) instead of switching to dark mode immediately when device is unplugged (and light mode when back to plugged).

[Spiritreader]

With the way this is currently implemented, it's pretty difficult to realize.
I will look into it, but don't expect anything anytime soon.

[khuongduybui]

Please implement this. It will also help with the new Surface Laptop Studio's "smart charging" mode that tries to keep the battery level around 80% instead of fully charged.

[Spiritreader]

Please implement this. It will also help with the new Surface Laptop Studio's "smart charging" mode that tries to keep the battery level around 80% instead of fully charged.

I am simultaneously surprised, and entirely unsurprised that Microsoft themselves don't know how to use their own battery management system correctly.

Windows' battery indicator has two separate states:

• Charging, Not Charging
• Plugged in, Not Plugged in

Laptops that use smart charging correctly and don't mess stuff up use the "Plugged in, Not Plugged in" in combination with the others.

For example, on my Lenovo laptop, as soon as the battery hits the designated percentage (60%), the battery status switches to "Plugged in - not charging", which is what it should be. And it stays that way.

ADM reacts to that accordingly by doing nothing (because battery events do not trigger since it's still plugged in).
I've now seen multiple other devices that seem to omit this step, causing Windows battery events to trigger when they shouldn't.

Sadly, as I've said before, this is far from an easy fix as implementing a delay such that it works well and integrates with future infrastructure in Auto Dark Mode is quite the undertaking.

The estimation of my "soon" in the earlier post is weeks to months.

[Spiritreader]

1. Concerning delays

Delaying is still a bit more complicated to figure out, as we must make sure a theme switch is only ever delayed (as in: users have to configure a delay) if there is precedence. For more info on that see section 2.

The current draft on how to realize this looks something like this.
The event is tied to a timer with configurable delay (if delay is 0, timer won't be used)
Whenever a battery event triggers and delay > 0, the timer starts with the corresponding battery status change event (plugged in or discharging).
If, for whatever reason, the battery status changes again during this time, the timer is cancelled.
When the timer reaches its defined end, the theme switch is performed.

2. Concerning fluctuating battery charging status originating from battery protection mechanisms

There are apparently better ways to track the battery status, which in theory should greatly improve the behavior of the charge state detection, eliminating false-positive theme switches almost entirely for most users.

It looks like switching over to PowerSourceKind events is an almost ideal solution.
https://docs.microsoft.com/de-de/windows/windows-app-sdk/api/winrt/microsoft.windows.system.power.powersourcekind?view=windows-app-sdk-1.0

However, this is only available in the new Windows App SDK, which still does not work yet due to a regression with WinForms (which we use for the tray) and .NET6 with ARM deployment.
The Win App SDK requires the entire solution to be built for ARM as well for some reason. despite the fact that the target platform is set to x86-64. According to MS, the Win App SDK doesn't even support ARM, so I don't know what's up with that.
(dotnet/sdk#22565)

So, we will have to wait until this is fixed in net6.
Until then, I have pushed a mitigation that should at least no longer switch the theme if the event gets triggered accidentally by the BatteryStatusChanged event.
These changes are availalble starting with build 10.1.1.4 upwards.

Note: This may introduce unintended side-effects such as Auto Dark Mode POTENTIALY preventing sleep due to reacting to battery events, keeping the system from idling

[FrankSFLYS]

On my Lenovo laptop (ThinkBook 14+) it swtiches to dark mode when battery is full with charger connected. It is a small issue and I have turn this feature off and I'm just reporting it.

[Spiritreader]

I've pushed changes to the latest beta such that Auto Dark Mode now queries the power supply status instead of the battery discharge state.

In theory that should resolve unwanted switches,

[khuongduybui]

Thank you very much for fixing this! I will check it out ASAP!

[Gravifer]

Thanks for the effort for achieving this!
I'd like to supply another circumstance that this is helpful: with multi-connector USB chargers, the PD protocol actually asks the power delivery to be suspended for a split second for all devices every time one is added or removed.

[Spiritreader]

Thanks for the effort for achieving this! I'd like to supply another circumstance that this is helpful: with multi-connector USB chargers, the PD protocol actually asks the power delivery to be suspended for a split second for all devices every time one is added or removed.

@Gravifer Hmm yes that is true.
I think for these cases there's no other way than to implement some kind of hold-over time.
I've actually implemented something similar for config file reloading, so I might be able to also use that for this case.

Would you be able to provide a log file with debugging enabled that reproduces this scenario? That way I can analyze the dropout interval.

[alias-paj]

Is the option to delay the "auto switch to dark mode" triggered by an "unplugged" Laptop/Surface still in progress?

I do unplug and replug my Surface quite often. It would be nice if I could set a delay time t prevent constant switching of the theme. Some programs do not handle that as good as they should.