Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1074 bytes --]

Hi.

On Fri, 2005-03-11 at 22:55, Stefan Seyfried wrote:
> Pavel Machek wrote:
> > Hi!
> 
> > I'm afraid this is racy by default. Machine resumes, then Xscreensaver
> > is being told that it should lock, but bad user may type in console in
> > meantime or something.
> 
> i do of course lock the screen before suspend, but some screensavers are
> not synchronous and take some time to actually lock. It is a mess.
> 
> > Synchronous notification *before* suspend might do the trick,
> > through. Tell Xscreensaver to lock, wait for it to lock, only then
> > proceed with suspend. That seems only safe solution.
> 
> Yes, but you'll need another ~10 seconds until power off.
> Both xscreensaver and kde screensaver are not from the speedy department :-(

There's an xset to activate the screensaver too - and to force it to
lock if you want.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[David Zeuthen]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Fri, 2005-03-11 at 02:12 -0500, Adam Belay wrote:
> > Maybe I'm reading the source wrong, but isn't it the case that some
> > laptops using APM (my IBM thinkpad T41 with acpi=off for instance)
> > suspends without user space interaction when the lid is closed, thus
> > rendering it impossible to send the event from user space? 
> > 
> > One may even ask whether it's sound to assume that all architectures
> > will be suspended via user space?
> > 
> > <snip>
> 
> I would consider this to be an exception.  APM has been obsolete for
> years.  Our focus (for those platforms where it is available) should be
> with ACPI on.
> 

Except that quite a few laptop users (it's getting fewer thankfully,
since ACPI support is getting better all the time) currently are forced
to use APM if they want their laptop to actually suspend.

Cheers,
David



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[David Zeuthen]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

On Fri, 2005-03-11 at 09:41 +0100, Pavel Machek wrote:
> On Pá 11-03-05 00:28:55, David Zeuthen wrote:
> > On Fri, 2005-03-11 at 00:07 +0100, Pavel Machek wrote:
> > > > I was merely asking for an event when the system is resumed.
> > > > 
> > > > I agree it doesn't make much sense for an event just before the system
> > > > is suspended - if this is needed I believe we can orchestrate it
> > > > completely from user space (things like making your email app
> > > > synchronize etc. comes to mind).
> > > 
> > > You can have event when the system is resumed. Just do it in userspace.
> > > 
> > 
> > Maybe I'm reading the source wrong, but isn't it the case that some
> > laptops using APM (my IBM thinkpad T41 with acpi=off for instance)
> > suspends without user space interaction when the lid is closed, thus
> > rendering it impossible to send the event from user space? 
> > 
> > One may even ask whether it's sound to assume that all architectures
> > will be suspended via user space?
> 
> Some machines will suspend without even telling operating system
> anything.
> 
> For APM case, yes some kind of notification makes sense (I thought we
> were talking ACPI/swsusp here).
> 

Oh, I thought the kernel was moving towards presenting user space with
an abstract interface much like /sys/power/state; that would definitely
be easier on user space (we don't have to add new code for every PM
framework), but I do understand if you don't want to do this as it have
negative consequences. But at least some form of feature parity across
different PM frameworks would be nice (e.g. if you make APM resume send
an event, do the same for ACPI and PMU) because in many ways user space
do have to design for lowest common denominator when abstracting this.

> > > . I'm *not* going to do that from kernel. But standartizing what needs
> > > to be ran on resume is indeed good idea, and few lines in
> > > Documentation/power/* are probably worth it.
> > > 
> > 
> > There's a very practical problem of getting all distributions to
> > actually do this.
> 
> Where doing it kernel means we have to do it right..
> 

I understand that, yes.

> > Another point is that user space may just use a timer and look at the
> > wall clock to determine when a suspend happens, but that's hardly an
> > elegant architecture. It does save some discussion, though, either way
> > I'll be quiet now and leave you guys to do real work :-)
> 
> Well, if you propose reasonable way to notify userspace, you can get
> it at least for APM case... So do not drop quiet just now.

I'm not a kernel hacker, sorry, my best bet would be using the
kobject_uevent stuff (since that is used for other notifications) but I
don't really grok all the locking and synchronization needed to do this
right without races / deadlocks.

I was just adding to this thread because Alan asked what user space
would like to see :-)

Cheers,
David



[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

Hi.

On Sat, 2005-03-12 at 03:04, David Zeuthen wrote:
> Oh, I thought the kernel was moving towards presenting user space with
> an abstract interface much like /sys/power/state; that would definitely
> be easier on user space (we don't have to add new code for every PM
> framework), but I do understand if you don't want to do this as it have
> negative consequences. But at least some form of feature parity across
> different PM frameworks would be nice (e.g. if you make APM resume send
> an event, do the same for ACPI and PMU) because in many ways user space
> do have to design for lowest common denominator when abstracting this.

APM is considered obsolete, even Stephen Rothwell says that :> This is
why no work has been done on making it have a sys interface, IIUC.

The /sys interface is the way to go. Some of us are just too scared
by^W^W busy to implement kobjects and keep putting off the transition :>

> > > > . I'm *not* going to do that from kernel. But standartizing what needs
> > > > to be ran on resume is indeed good idea, and few lines in
> > > > Documentation/power/* are probably worth it.

Slow reply, I know.

There's an excellent hibernate script written by Bernard Blackham that
we use for suspend2, but is also able to handle swsusp etc. If everyone
would start using it... (me included! [Bernard, that's five times I've
said it!])

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Greg KH]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Sat, Mar 12, 2005 at 07:49:00AM +1100, Nigel Cunningham wrote:
> There's an excellent hibernate script written by Bernard Blackham that
> we use for suspend2, but is also able to handle swsusp etc. If everyone
> would start using it... (me included! [Bernard, that's five times I've
> said it!])

A pointer to the script?

thanks,

greg k-h

[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Bernard Blackham]

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On Fri, Mar 11, 2005 at 08:15:35PM -0800, Greg KH wrote:
> On Sat, Mar 12, 2005 at 07:49:00AM +1100, Nigel Cunningham wrote:
> > There's an excellent hibernate script written by Bernard Blackham that
> > we use for suspend2, but is also able to handle swsusp etc. If everyone
> > would start using it... (me included! [Bernard, that's five times I've
> > said it!])
> 
> A pointer to the script?

It doesn't have its own page yet.

http://www.suspend2.net/downloads/ - under the "Hibernate Script"
section.

Bernard.

-- 
 Bernard Blackham <bernard at blackham dot com dot au>

[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

Hi.

On Sat, 2005-03-12 at 15:15, Greg KH wrote:
> On Sat, Mar 12, 2005 at 07:49:00AM +1100, Nigel Cunningham wrote:
> > There's an excellent hibernate script written by Bernard Blackham that
> > we use for suspend2, but is also able to handle swsusp etc. If everyone
> > would start using it... (me included! [Bernard, that's five times I've
> > said it!])
> 
> A pointer to the script?

Here you go...

http://suspend2.net/downloads/all/hibernate-script-1.05.tar.gz

Regards,

Nigel

> thanks,
> 
> greg k-h
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Patrick Mochel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1534 bytes --]


On Fri, 11 Mar 2005, Nigel Cunningham wrote:

> Hi.
>
> On Fri, 2005-03-11 at 16:28, David Zeuthen wrote:
> > Maybe I'm reading the source wrong, but isn't it the case that some
> > laptops using APM (my IBM thinkpad T41 with acpi=off for instance)
> > suspends without user space interaction when the lid is closed, thus
> > rendering it impossible to send the event from user space?
> >
> > One may even ask whether it's sound to assume that all architectures
> > will be suspended via user space?
>
> The most common way at the moment for a lid switch to activate
> suspending is via the userspace acpid daemon. I'd be mildly interested
> if you didn't have something equivalent running on your machine.

APM doesn't work like that. There *might* be a way for the lid switch
interrupt to be passed to the kernel, which can the forward it to
userspace. But traditionally, the interrupt would generate an SMI and be
handled by the BIOS in a manner completely transparent to the OS (using
the Evil System Management Mode on x86 processor).

While it is true that APM is obsolete, a similar method to suspend some
systems may be employed by the system designer. I believe it's going to
be common in embedded systems, where an external signal triggers a suspend
transition.

That doesn't preclude us from pushing the signal out to userpsace and
requiring userspace to trigger the susped through sysfs, but my general
opinion is that that solution is inelegant in principal and may not be
fast enough for people employing it.


	Pat
5B

[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm

Re: suspend/resume uevents [was Re: Introducing HAL userspace power management]

[Nigel Cunningham]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Hi.

On Sat, 2005-03-12 at 07:57, Patrick Mochel wrote:
> On Fri, 11 Mar 2005, Nigel Cunningham wrote:
> 
> > Hi.
> >
> > On Fri, 2005-03-11 at 16:28, David Zeuthen wrote:
> > > Maybe I'm reading the source wrong, but isn't it the case that some
> > > laptops using APM (my IBM thinkpad T41 with acpi=off for instance)
> > > suspends without user space interaction when the lid is closed, thus
> > > rendering it impossible to send the event from user space?
> > >
> > > One may even ask whether it's sound to assume that all architectures
> > > will be suspended via user space?
> >
> > The most common way at the moment for a lid switch to activate
> > suspending is via the userspace acpid daemon. I'd be mildly interested
> > if you didn't have something equivalent running on your machine.
> 
> APM doesn't work like that. There *might* be a way for the lid switch
> interrupt to be passed to the kernel, which can the forward it to
> userspace. But traditionally, the interrupt would generate an SMI and be
> handled by the BIOS in a manner completely transparent to the OS (using
> the Evil System Management Mode on x86 processor).

Ah.. sorry. I missed those critical A P M letters :>

Nigel

> While it is true that APM is obsolete, a similar method to suspend some
> systems may be employed by the system designer. I believe it's going to
> be common in embedded systems, where an external signal triggers a suspend
> transition.
> 
> That doesn't preclude us from pushing the signal out to userpsace and
> requiring userspace to trigger the susped through sysfs, but my general
> opinion is that that solution is inelegant in principal and may not be
> fast enough for people employing it.
> 
> 
> 	Pat
> 5B
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


[-- Attachment #2: Type: text/plain, Size: 171 bytes --]

_______________________________________________
linux-pm mailing list
linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
http://lists.osdl.org/mailman/listinfo/linux-pm