> On 1 May 2025, at 11:21, [email protected] wrote: > > Hallo Hakan, > thank you for the reply.
Hi Christian, > > Am 01.05.2025 09:45 schrieb Hakan Bayındır: >> However, I like how “Amphetamine” (a macOS application) behaves by >> default. Amphetamine is a tool which prevents Macs from sleeping. When >> you enable it, it keeps Macs awake, but the catch is, the device is >> allowed to sleep when its lid is closed. > > Sounds like an akward Mac-like use case to me. :D > But I am assuming I just don't get that use case. Even on Windows you can > trigger sleep mode when closing the lid but keep the system awak when the lid > is open. Why does Mac need an extra application for that? We use Amphetamine on macOS because the out of the box power saving policy is a bit too aggressive, however, since the default behavior allows weeks of uptime, we don’t change it much. Amphetamine enables us to keep macOS awake unless we close the lid, allowing us to keep SSH sessions running or prevent long running tasks from being interrupted. Some applications suspend power saving to prevent interruptions, but the list is not definitive. If you are really adamant, Amphetamine can disable stand-by even when you close the lid, but we don’t use it, so many Macs stay awake “unless you close the lid”. Since this behavior is useful (and I use Macs for a long time now alongside Linux to compare them effectively), I thought BiT can mirror this “disable sleep, but allow lid to suspend the system” behavior. > >> Maybe BiT can behave the same way. Inhibiting sleep, but not >> preventing lid to trigger sleep/standby. > > I don't get that either. In this case BIT need to "monitor" the lid status > and even know that there is a lid. > I need to release the inhibition when the lid is closed. To complex in > implementation and even complex for users. Linux Kernel knows if your system has a lid, and can monitor for lid events. This is why I said “it’s been a while since I looked into it”, Linux Kernel allows detailed power management, and this can be easily handled in theory. BiT doesn’t need to have the logic to detect the system capabilities. Kernel already does it. BiT needs to ask the correct questions and listen to the correct channels. > >> but can you point me to the code which >> handles this in BiT? > > You can dive in the code via following the linked issue. > > But the question is not about code or how to implement something. It is more > about behavior of BIT itself. Implementing is very easy. > The question is more about inverting a 17 year old default behavior. > > Currently to me the answer of my initial question is "No". And I can > implement that (don't inhibit) even with keeping the old behavior (inhibit) > for existing backup profiles. I’m currently away from my Linux systems, so I can’t work on it outright, but I wanted to see the code because I wondered how BiT does it. Adding an option to not inhibit sleep is a good starting point, then maybe more granular controls “keep system on, but respect lid”, etc. can be implemented later. To prevent surprises, keeping sleep inhibition enabled as a default is a good choice from my point of view, but giving an option to override is also good. I’ll look into the power events API when I get back to home, next week, and will let you know. > > Regards, > Christian Cheers, Hakan > _______________________________________________ > Bit-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/bit-dev.python.org/ > Member address: [email protected] _______________________________________________ Bit-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/bit-dev.python.org/ Member address: [email protected]
