GNU bug report logs - #63620
30.0.50; [Feature Request] run hooks on sleep/wake

Previous Next

Full log

View this message in rfc822 format

From: Andrew Cohen <acohen <at> ust.hk>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 63620 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de, Ship Mints <shipmints <at> gmail.com>
Subject: bug#63620: 30.0.50; [Feature Request] run hooks on sleep/wake
Date: Thu, 06 Feb 2025 13:59:40 +0800

>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

[...]

    SM> BTW: I understand what a "wake" event means, but what about a
    SM> "sleep" event?  I mean: how can we receive this event before we
    SM> wake up again?  Or does it mean that we're about to sleep?  

The events that I am detecting with D-Bus are actually part of logind, a
tiny daemon that manages user logins in various ways. The process
monitors the status of a variety of hardware components (such as the
state of the lid, power, etc), and is responsible for managing
suspension and hibernation.  I think that logind, part of
freedesktop.org, is pretty universal on gnu/linux.

The signal I am accessing, PrepareForSleep, is sent right before the
systems enters suspend/hibernate (with argument True), and right after
the system leaves suspend/hibernate (with argument False). 

    SM> If so what do we know about when we'll sleep?  

I don't think there is a guarantee how much time remains before the
sleep state is fully realized. However I've been using this for a couple
of years and have never had a failure to run the hooks to completion.

    SM> Can we influence (e.g. delay) it?

logind has a method to inhibit sleeping (exposed through D-Bus), which
can be used to create an inhibition lock, preventing sleep until the
lock is released. It would be ideal to implement this around running the
hooks to ensure that all the Emacs code completes before finishing
sleep. It shouldn't be hard, I just haven't found it necessary. I'll
take a look. And its probably important to have some well-designed API
for this as well.

The real question is what to do on systems that don't use logind. That
will depend on what kind of information is available and how we can
control things. Inevitably this means that we will have a fair amount of
system-specific code in the package.

Best,
Andy

PS:

In trying to understand `unread-command-events' and 'special-event-map'
I came across this bit in bindings.el:

;; FIXME: Do those 3 events really ever reach the global-map ?
;;        It seems that they can't because they're handled via
;;        special-event-map which is used at very low-level.  -stef
(global-set-key [delete-frame] 'handle-delete-frame)
(global-set-key [iconify-frame] 'ignore)
(global-set-key [make-frame-visible] 'ignore)

So I think the answer to the question is "yes, provided someone puts the
event on unread-command-events" where it won't be handled first by
special-event-map. This is why I found that I could inject these special
events onto unread-command-events and have them trigger a callback, but
not the others.

-- 
Andrew Cohen

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.