Subscribe to power events on Windows #1248
Conversation
There was a problem hiding this comment.
If I read this correctly, it's subscribing to the windows events.
Any thoughts about that approach vs setting up a callback on DAM actions? The bottom of https://learn.microsoft.com/en-us/windows/compatibility/desktop-activity-moderator has a solution section about how to do this with windows notifications.
Yes -- I found this was more reliable/useful than registering the service to receive power events.
A couple places I read (comment on this answer, this answer that links to this official post) indicated that |
I don't know enough to know which approach is more "supported". I do not currently have strong opinions. |
RebeccaMahany
force-pushed
the
becca/watch-power-events
branch
from
7e35ea6
to
9eba669
Compare
| if err != nil { | ||
| level.Debug(p.logger).Log("msg", "error creating pointer to channel path", "err", err) | ||
| return | ||
| } |
There was a problem hiding this comment.
Hrm. I wonder if we should log and return, or return the error. Feels a little TBD.
This feels a bit like our usual go actors -- and we should return the error. Though we might end up ignoring it at the caller level
There was a problem hiding this comment.
I was also thinking this should maybe just be a rungroup actor, and that's why I was waffling on the error handling here -- because I didn't want to return an error on the equivalent of Execute and force a launcher restart, since this is just for logging right now.
I think the option that feels the most consistent to me is to move this setup work into the New function, and return an error on failure to set up. If New returns an error, log it and move on; if it doesn't, add the rungroup with a no-op Execute. Does that sound reasonable?
There was a problem hiding this comment.
Pushed this change, lmk what you think!
There was a problem hiding this comment.
Yes. I think that pattern is good.
New returns an error, and the caller decides if it's fatal. And after that, it's in it's own little world.
|
so we just plan to log the events for now? not actually acting on them? |
Yeah. Partly because I want to get this to customer to see if it's what's happening. And I think actioning them might be tricky. So get this out, then work on what's next |
| // Execute is a no-op, since we've already registered our subscription | ||
| func (p *powerEventWatcher) Execute() error { | ||
| <-p.interrupt | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Feels like a lot of New should move here. But probably doesn't matter yet
RebeccaMahany
dismissed stale reviews from directionless and James-Pickett
via
15de3f0
Uses EvtSubscribe to receive notifications when we enter or leave modern standby.
When looking at the sleep report for my computer, I noticed that on lid shut or sleep, the device entered Modern Standby immediately (event ID 506). On resume, it would exit Modern Standby (507).
After many hours in Modern Standby, the device would exit Modern Standby (507) with
Reason: Sleep, Hibernate, or Shutdown, and immediately enter sleep (42) with reasonHibernate from Sleep - Standby Battery Budget Exceeded. On wake, it would re-enter (506) and then exit (507) Modern Standby.stateDiagram-v2 Awake --> ModernStandby: 506 ModernStandby --> Awake: 507 ModernStandby --> Sleep: 507 => 42 Sleep --> ModernStandby: 506