Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #176343 > unrolled thread

Monitor switched off after resume from hibernation

Back to article view | Back to linux.debian.user

Contents

  Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-05 22:10 +0100
    Re: Monitor switched off after resume from hibernation Keith Bainbridge <keithrbaugroups@gmail.com> - 2017-01-06 01:20 +0100
      Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-06 03:00 +0100
        Re: Monitor switched off after resume from hibernation Keith Bainbridge <keithrbaugroups@gmail.com> - 2017-01-06 06:20 +0100
          Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-06 15:30 +0100
            Re: Monitor switched off after resume from hibernation Stefan Monnier <monnier@iro.umontreal.ca> - 2017-01-06 22:50 +0100
        Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-06 22:10 +0100
          Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-07 05:00 +0100
            Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-07 08:20 +0100
              Re: Monitor switched off after resume from hibernation Joe <joe@jretrading.com> - 2017-01-07 10:10 +0100
                Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-07 16:10 +0100
                Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-07 19:40 +0100
              Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-07 20:40 +0100
                Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-07 21:30 +0100
                Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-08 08:10 +0100
                  Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-09 02:10 +0100
                    Re: Monitor switched off after resume from hibernation Joel Rees <joel.rees@gmail.com> - 2017-01-09 13:50 +0100
                      Re: Monitor switched off after resume from hibernation David Wright <deblis@lionunicorn.co.uk> - 2017-01-09 15:20 +0100
      Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-06 07:00 +0100
        Re: Monitor switched off after resume from hibernation Keith Bainbridge <keithrbaugroups@gmail.com> - 2017-01-06 07:30 +0100
          Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-06 13:20 +0100
        Re: Monitor switched off after resume from hibernation Charlie Kravetz <cjk@teamcharliesangels.com> - 2017-01-06 15:40 +0100
          Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-06 20:50 +0100
            Re: Monitor switched off after resume from hibernation Charlie Kravetz <cjk@teamcharliesangels.com> - 2017-01-06 23:20 +0100
              Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-07 08:00 +0100
    Re: Monitor switched off after resume from hibernation Joel Rees <joel.rees@gmail.com> - 2017-01-09 14:10 +0100
      Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-09 19:00 +0100
        Re: Monitor switched off after resume from hibernation solitone <solitone@mail.com> - 2017-01-22 14:40 +0100

Page 1 of 2  [1] 2  Next page →

#176343 — Monitor switched off after resume from hibernation

I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently 
noticed an issue that affect my system when it hibernates. 

When the screen is already switched off and then the system hibernates, it 
won't resume correctly later on. Specifically, the monitor will be switched off 
again at the end of the resume process.

E.g. I give the following command in order to switch off the monitor:

$ sleep 1 && xset dpms force off

then I close the lid so that my system hibernates. Then I resume the system. 
The monitors turns on, as I see the boot loader screen and some boot messages. 
But then, when the resume is complete, the screen is switched off again, and 
there is no way to turn it on. The only solution is press the power button to 
turn off the entire computer.

I get the same issue even when, instead of using the xset command, I wait 
several minutes so that the screen is switched off automatically by KDE's 
power management, and then I hibernate the system.

By contrast, I have no issue if I hibernate when the screen is still on. The 
resume works perfectly well. Besides, suspend (to RAM) has no issue either, 
both when the screen is on and when it is off. 

I've already reported a bug to the mainteiners of debian kernel. But in the 
meanwhile, as a workaround I'm thinking of using a systemd script that forces 
the monitor on just before the system starts hibernating. I've tried with 
"xset dpms force on", however it won't in fact turn on the monitor. Is there a 
way to do this?

Thanks & Regards,
  Davide

[toc] | [next] | [standalone]

#176350

[Multipart message — attachments visible in raw view] — view raw

Ummm, why turn the monitor off first?

I use suspend rather than hibernate, on a macbook 4,1 and just close the
lid.  I get a password screen as soon as I open up.

Keith Bainbridge

0447667468

keithrbaugroups@gmail.com

Sent from my APad

On 6 Jan 2017 08:04, "solitone" <solitone@mail.com> wrote:

> I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently
> noticed an issue that affect my system when it hibernates.
>
> When the screen is already switched off and then the system hibernates, it
> won't resume correctly later on. Specifically, the monitor will be
> switched off
> again at the end of the resume process.
>
> E.g. I give the following command in order to switch off the monitor:
>
> $ sleep 1 && xset dpms force off
>
> then I close the lid so that my system hibernates. Then I resume the
> system.
> The monitors turns on, as I see the boot loader screen and some boot
> messages.
> But then, when the resume is complete, the screen is switched off again,
> and
> there is no way to turn it on. The only solution is press the power button
> to
> turn off the entire computer.
>
> I get the same issue even when, instead of using the xset command, I wait
> several minutes so that the screen is switched off automatically by KDE's
> power management, and then I hibernate the system.
>
> By contrast, I have no issue if I hibernate when the screen is still on.
> The
> resume works perfectly well. Besides, suspend (to RAM) has no issue either,
> both when the screen is on and when it is off.
>
> I've already reported a bug to the mainteiners of debian kernel. But in the
> meanwhile, as a workaround I'm thinking of using a systemd script that
> forces
> the monitor on just before the system starts hibernating. I've tried with
> "xset dpms force on", however it won't in fact turn on the monitor. Is
> there a
> way to do this?
>
> Thanks & Regards,
>   Davide
>
>

[toc] | [prev] | [next] | [standalone]

#176353

On Fri 06 Jan 2017 at 11:11:45 (+1100), Keith Bainbridge wrote:
> Ummm, why turn the monitor off first?

Perhaps because Davide doesn't want to wait 30 mins¹ before
closing the lid and finding out if the problem still recurs.

> I use suspend rather than hibernate, on a macbook 4,1 and just close the
> lid.  I get a password screen as soon as I open up.

So would that be using more power both when the lid is closed,
and also when the lid is left open for prolonged periods?

¹ I used to specify 10/20/30 minutes for stand-by/suspend/off
when I ran real CRT monitors.

> On 6 Jan 2017 08:04, "solitone" <solitone@mail.com> wrote:
> 
> > I'm on debian stretch, and my computer is a MacBookPro 12,1. I've recently
> > noticed an issue that affect my system when it hibernates.
> >
> > When the screen is already switched off and then the system hibernates, it
> > won't resume correctly later on. Specifically, the monitor will be
> > switched off
> > again at the end of the resume process.
> >
> > E.g. I give the following command in order to switch off the monitor:
> >
> > $ sleep 1 && xset dpms force off
> >
> > then I close the lid so that my system hibernates. Then I resume the
> > system.
> > The monitors turns on, as I see the boot loader screen and some boot
> > messages.
> > But then, when the resume is complete, the screen is switched off again,
> > and
> > there is no way to turn it on. The only solution is press the power button
> > to
> > turn off the entire computer.
> >
> > I get the same issue even when, instead of using the xset command, I wait
> > several minutes so that the screen is switched off automatically by KDE's
> > power management, and then I hibernate the system.
> >
> > By contrast, I have no issue if I hibernate when the screen is still on.
> > The
> > resume works perfectly well. Besides, suspend (to RAM) has no issue either,
> > both when the screen is on and when it is off.
> >
> > I've already reported a bug to the mainteiners of debian kernel. But in the
> > meanwhile, as a workaround I'm thinking of using a systemd script that
> > forces
> > the monitor on just before the system starts hibernating. I've tried with
> > "xset dpms force on", however it won't in fact turn on the monitor. Is
> > there a
> > way to do this?

Do you perhaps need

xset -display <something> dpms force on

in the systemd script?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176355

[Multipart message — attachments visible in raw view] — view raw

Please see below

Keith Bainbridge

0447667468

keithrbaugroups@gmail.com

Sent from my APad

On 6 Jan 2017 12:58, "David Wright" <deblis@lionunicorn.co.uk> wrote:

On Fri 06 Jan 2017 at 11:11:45 (+1100), Keith Bainbridge wrote:
> Ummm, why turn the monitor off first?

Perhaps because Davide doesn't want to wait 30 mins¹ before
closing the lid and finding out if the problem still recurs.



Not my case.  The book simply suspends when the lid is closed.

[toc] | [prev] | [next] | [standalone]

#176364

On Fri 06 Jan 2017 at 16:09:43 (+1100), Keith Bainbridge wrote:
> Please see below
> 
> Keith Bainbridge
> 
> 0447667468
> 
> keithrbaugroups@gmail.com
> 
> Sent from my APad
> 
> On 6 Jan 2017 12:58, "David Wright" <deblis@lionunicorn.co.uk> wrote:
> 
> On Fri 06 Jan 2017 at 11:11:45 (+1100), Keith Bainbridge wrote:
> > Ummm, why turn the monitor off first?
> 
> Perhaps because Davide doesn't want to wait 30 mins¹ before
> closing the lid and finding out if the problem still recurs.
> 
> 
> 
> Not my case.

I wasn't suggesting it was. I was merely answering your question
with a likely scenario. It seemed a reasonable action at the time,
bearing in mind that the OP was probably slumbering at 2:50 am.

> The book simply suspends when the lid is closed.

I think we got that.

Later you wrote "I don't know how much more power you are saving
with hibernate."

AIUI you save 100% "more power" with hibernate; the machine is
powered off.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176393

> AIUI you save 100% "more power" with hibernate; the machine is
> powered off.

FWIW I've seen cases where the power brick consumes *more* when the
machine is off than when it's suspended (and in my experience there's
usually little difference between the two; the largest difference I've
seen is with my old mac mini where the consumption in "power off" is
about half that of "suspended").


        Stefan

[toc] | [prev] | [next] | [standalone]

#176390

On Thursday, January 5, 2017 7:52:20 PM CET David Wright wrote: 
> Do you perhaps need
> 
> xset -display <something> dpms force on
> 
> in the systemd script?

Hi David,

no, I've also tried with the -display option, but I don't get anything, with 
that command in either the pre block or the post block.

BTW, on my system the -display option doesn't seem to be needed, because if I 
do:

$ sleep 1; xset dpms force off; sleep 2; xset dpms force on

in a terminal, the screen switches off and on as expected.

Thanks,
  Davide

[toc] | [prev] | [next] | [standalone]

#176399

On Fri 06 Jan 2017 at 22:00:45 (+0100), solitone wrote:
> On Thursday, January 5, 2017 7:52:20 PM CET David Wright wrote: 
> > Do you perhaps need
> > 
> > xset -display <something> dpms force on
> > 
> > in the systemd script?
> 
> no, I've also tried with the -display option, but I don't get anything, with 
> that command in either the pre block or the post block.
> 
> BTW, on my system the -display option doesn't seem to be needed, because if I 
> do:
> 
> $ sleep 1; xset dpms force off; sleep 2; xset dpms force on
> 
> in a terminal, the screen switches off and on as expected.

Yes, but in your terminal, you'll probably find that
$ echo $DISPLAY
will give you :0 (locally) or localhost:10.0 (if you ssh into
another computer). So your terminal's xset command will be
happy without -display as it's got $DISPLAY instead.

$ xset c 99                                 # good
$ xset c 1                                  # good
$ xset -display :1 c 99                     # bad
xset:  unable to open display ":1"
$ DISPLAY="" xset c 99                      # bad
xset:  unable to open display ""
$ DISPLAY="" xset -display :0 c 99          # good
$ 

I'm assuming that a systemd command that suddenly pops up from nowhere
will not have a suitable value for $DISPLAY.

If I put
*       *       *       *       *       /usr/bin/xeyes
into my crontab, I get an error message mailed to me
every minute as above. If I replace it with
*      *       *       *       *       DISPLAY=":0" /usr/bin/xeyes
I get a new pair of eyes popping up on the screen every minute.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176401

On Friday, January 6, 2017 9:52:13 PM CET David Wright wrote:
> in your terminal, you'll probably find that
> $ echo $DISPLAY
> will give you :0 (locally) or localhost:10.0 (if you ssh into
> another computer). So your terminal's xset command will be
> happy without -display as it's got $DISPLAY instead.
> [...]
> I'm assuming that a systemd command that suddenly pops up from nowhere
> will not have a suitable value for $DISPLAY.

OK, I see.

I've ssh'd into the computer with the screen issue, and done some additional 
tests. I can switch off and on the monitor from ssh with the following 
commands ($DISPLAY is not set in shh):

$ xset -display :0 dpms force off
$ xset -display :0 dpms force on

So, I turn the monitor off, hibernate, and resume, and I get the usual black 
screen. The system is up and running, as I can ssh into it. From ssh I give:

$ xset -display :0 dpms force on

but nothing happen. Even if I try:

$ xset -display :0 dpms force off
$ xset -display :0 dpms force on

nothing happens either.

So the behaviour I have from ssh is similar to what I get from a systemd 
script. The system is apparently up and running, but I can't turn the monitor 
on, neither from systemd, nor from ssh. Funny thing!

[toc] | [prev] | [next] | [standalone]

#176403

On Sat, 07 Jan 2017 08:18:51 +0100
solitone <solitone@mail.com> wrote:

> On Friday, January 6, 2017 9:52:13 PM CET David Wright wrote:
> > in your terminal, you'll probably find that
> > $ echo $DISPLAY
> > will give you :0 (locally) or localhost:10.0 (if you ssh into
> > another computer). So your terminal's xset command will be
> > happy without -display as it's got $DISPLAY instead.
> > [...]
> > I'm assuming that a systemd command that suddenly pops up from
> > nowhere will not have a suitable value for $DISPLAY.  
> 
> OK, I see.
> 
> I've ssh'd into the computer with the screen issue, and done some
> additional tests. I can switch off and on the monitor from ssh with
> the following commands ($DISPLAY is not set in shh):
> 
> $ xset -display :0 dpms force off
> $ xset -display :0 dpms force on
> 
> So, I turn the monitor off, hibernate, and resume, and I get the
> usual black screen. The system is up and running, as I can ssh into
> it. From ssh I give:
> 
> $ xset -display :0 dpms force on
> 
> but nothing happen. Even if I try:
> 
> $ xset -display :0 dpms force off
> $ xset -display :0 dpms force on
> 
> nothing happens either.
> 
> So the behaviour I have from ssh is similar to what I get from a
> systemd script. The system is apparently up and running, but I can't
> turn the monitor on, neither from systemd, nor from ssh. Funny thing!
> 

Is the screen truly off? If you look at it from unusual angles, can you
see any faint sign of the correct display?

I gave up trying suspend and hibernate on any Linux, as none of them
seem to work correctly. One effect I did see sometimes was that the
screen backlight was off, but the display was being operated correctly
and I could see, from some angles, the right screen material. I
couldn't find any way to turn on the backlight in this situation.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#176415

On Saturday, January 7, 2017 9:04:27 AM CET Joe wrote:
> Is the screen truly off? If you look at it from unusual angles, can you
> see any faint sign of the correct display?

I also suspect that in fact the screen isn't off. Although I've tried and 
looked at it from any angle, but I can't see anything.

[toc] | [prev] | [next] | [standalone]

#176422

On Saturday, January 7, 2017 9:04:27 AM CET Joe wrote:
> Is the screen truly off? If you look at it from unusual angles, can you
> see any faint sign of the correct display?

I've further investigated what's going on, and yes, the screen is truly off--
i.e. the backlight is completely off.

First an introduction. Screen brightness can be adjusted writing in "/sys/
class/backlight/intel_backlight/brightness" a value between 0 and 
max_brightness, in my case 1388. 

This value gets copied in "/sys/class/backlight/intel_backlight/
actual_brightness". Ultimately the brightness of the screen is decided by 
"actual_brightness", but you can't write directly to that file.

When you switch off the backlight with "sleep 1 && xset dpms force off", the 
value in "brightness" doesn't change (for instance it remains equal to 1388), 
while only the value in /actual_brightness" is set to 0.

Now, regarding my analysis, I've done it with the help of the usual ssh. When 
the screen is off, as I said this means that "actual_brightness" is 0, while 
"brightness" can be any value (0, 1388, 694, whatever), depending on the 
specific situation, but this is not relevant. Now, if I hibernate the system, 
and then resume it, what I find with ssh is that "brightness" is 1388, but 
"actual_brightness" is still 0, meaning the screen is indeed off.

It's not possible to directly change the value in "actual_brightness", and in 
contrast to the usual behaviour, changing the value in "brightness" has no 
effect on "actual_brightness". As said in my previous posts, also "xset -
display :0 dpms force on" doesn't change the value in "actual_brightness".

[toc] | [prev] | [next] | [standalone]

#176426

On Sat 07 Jan 2017 at 08:18:51 (+0100), solitone wrote:
> On Friday, January 6, 2017 9:52:13 PM CET David Wright wrote:
> > in your terminal, you'll probably find that
> > $ echo $DISPLAY
> > will give you :0 (locally) or localhost:10.0 (if you ssh into
> > another computer). So your terminal's xset command will be
> > happy without -display as it's got $DISPLAY instead.
> > [...]
> > I'm assuming that a systemd command that suddenly pops up from nowhere
> > will not have a suitable value for $DISPLAY.
> 
> OK, I see.
> 
> I've ssh'd into the computer with the screen issue, and done some additional 
> tests. I can switch off and on the monitor from ssh with the following 
> commands ($DISPLAY is not set in shh):
> 
> $ xset -display :0 dpms force off
> $ xset -display :0 dpms force on
> 
> So, I turn the monitor off, hibernate, and resume, and I get the usual black 
> screen. The system is up and running, as I can ssh into it. From ssh I give:
> 
> $ xset -display :0 dpms force on
> 
> but nothing happen. Even if I try:
> 
> $ xset -display :0 dpms force off
> $ xset -display :0 dpms force on
> 
> nothing happens either.
> 
> So the behaviour I have from ssh is similar to what I get from a systemd 
> script. The system is apparently up and running, but I can't turn the monitor 
> on, neither from systemd, nor from ssh. Funny thing!

But you've chosen to do the difficult thing, without knowing whether
there's a bug somewhere that makes it impossible for you to succeed.
Would it not be better to get systemd to turn *on* the monitor
*before* the hibernate (and that's something you should be able to
observe happening).

One scenario might be to make systemd run a service that turns on the
monitor every few minutes. Then you can turn the monitor off with
your xset command and see if the systemd service restores it in a
minute or two.

If that experiment works, then you could go on to combine it with the
hibernation process to make sure that the monitor was on just before
hibernation started. (There might be some sort of serialisation
required to make sure the two actions occur in the right order. You
don't want a race.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176428

On Saturday, January 7, 2017 1:35:07 PM CET David Wright wrote:
> But you've chosen to do the difficult thing, without knowing whether
> there's a bug somewhere that makes it impossible for you to succeed.
> Would it not be better to get systemd to turn *on* the monitor
> *before* the hibernate (and that's something you should be able to
> observe happening).

Hi David, and thanks for your feedback. Yes, you're right, and what you're 
suggesting is the idea I also had originally. I tried also the other way round 
because till now I haven't succeeded in turning on the monitor before the 
hibernate. But I'll experiment following your hints and let you know. 

Thanks again & cheers,
  Davide

[toc] | [prev] | [next] | [standalone]

#176432

On Saturday, January 7, 2017 1:35:07 PM CET David Wright wrote:
> you could go on to combine it with the
> hibernation process to make sure that the monitor was on just before
> hibernation started. (There might be some sort of serialisation
> required to make sure the two actions occur in the right order. You
> don't want a race.)

What sort of serialisation are you referring to? I tried with the following 
script, but won't work:

$cat /usr/lib/systemd/system-sleep/screen_hack_hibernate

if [ "$2" = "hibernate" ]; then
    case "$1" in
        pre)
            xset -display :0 dpms force on
            ;;
    esac
fi

I thought it would be run just before hibernate (it's the same technique I use 
to unload the driver of my wifi adapter before hibernate, to prevent some other 
network issues I had) , but it doesn't.

[toc] | [prev] | [next] | [standalone]

#176480

On Sun 08 Jan 2017 at 07:59:39 (+0100), solitone wrote:
> On Saturday, January 7, 2017 1:35:07 PM CET David Wright wrote:
> > you could go on to combine it with the
> > hibernation process to make sure that the monitor was on just before
> > hibernation started. (There might be some sort of serialisation
> > required to make sure the two actions occur in the right order. You
> > don't want a race.)
> 
> What sort of serialisation are you referring to? I tried with the following 
> script, but won't work:
> 
> $cat /usr/lib/systemd/system-sleep/screen_hack_hibernate
> 
> if [ "$2" = "hibernate" ]; then
>     case "$1" in
>         pre)
>             xset -display :0 dpms force on
>             ;;
>     esac
> fi
> 
> I thought it would be run just before hibernate (it's the same technique I use 
> to unload the driver of my wifi adapter before hibernate, to prevent some other 
> network issues I had) , but it doesn't.

I can only answer you in the vaguest terms. I thought you might add a
service that has to run before hibernate, and it would contain a
Before= (or hibernate an After= ) line to make sure that turning on
the monitor preceeded the hibernation.

If you manage this, perhaps with others' help, you'll be ahead of me
on the systemd learning curve.

BTW I haven't bothered to respond to Stefan Monnier's contribution.
I can imagine scenarios that might cause power consumption when a
machine is off (like network cards running to watch for magic WoL
packets, and things like that), but a machine in hibernation should
cope with a power cut. In any case, I support your expectation that
using sleep/hibernate should not involve compromising monitors'
power-saving behaviour.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176493

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 9, 2017 at 10:01 AM, David Wright <deblis@lionunicorn.co.uk>
wrote:
> On Sun 08 Jan 2017 at 07:59:39 (+0100), solitone wrote:
>> On Saturday, January 7, 2017 1:35:07 PM CET David Wright wrote:
>> > you could go on to combine it with the
>> > hibernation process to make sure that the monitor was on just before
>> > hibernation started. (There might be some sort of serialisation
>> > required to make sure the two actions occur in the right order. You
>> > don't want a race.)
>>
>> What sort of serialisation are you referring to? I tried with the
following
>> script, but won't work:
>>
>> $cat /usr/lib/systemd/system-sleep/screen_hack_hibernate
>>
>> if [ "$2" = "hibernate" ]; then
>>     case "$1" in
>>         pre)
>>             xset -display :0 dpms force on
>>             ;;
>>     esac
>> fi
>>
>> I thought it would be run just before hibernate (it's the same technique
I use
>> to unload the driver of my wifi adapter before hibernate, to prevent
some other
>> network issues I had) , but it doesn't.
>
> I can only answer you in the vaguest terms. I thought you might add a
> service that has to run before hibernate, and it would contain a
> Before= (or hibernate an After= ) line to make sure that turning on
> the monitor preceeded the hibernation.
>
> If you manage this, perhaps with others' help, you'll be ahead of me
> on the systemd learning curve.
>
> BTW I haven't bothered to respond to Stefan Monnier's contribution.
> I can imagine scenarios that might cause power consumption when a
> machine is off (like network cards running to watch for magic WoL
> packets, and things like that),

Cheap power supply designs. I think he indicated.

Without load, some power supply designs draw more energy, either in
not-fully-defined operating modes or in modes where the P/S loads itself
down dynamically.

> but a machine in hibernation should
> cope with a power cut. In any case, I support your expectation that
> using sleep/hibernate should not involve compromising monitors'
> power-saving behaviour.
>
> Cheers,
> David.
>



-- 
Joel Rees

I'm imagining I'm a novelist:
http://reiisi.blogspot.jp/p/novels-i-am-writing.html

[toc] | [prev] | [next] | [standalone]

#176500

On Mon 09 Jan 2017 at 21:47:30 (+0900), Joel Rees wrote:
> On Mon, Jan 9, 2017 at 10:01 AM, David Wright <deblis@lionunicorn.co.uk> wrote:

> > BTW I haven't bothered to respond to Stefan Monnier's contribution.
> > I can imagine scenarios that might cause power consumption when a
> > machine is off (like network cards running to watch for magic WoL
> > packets, and things like that),
> 
> Cheap power supply designs. I think he indicated.

Indicated what?

> Without load, some power supply designs draw more energy, either in
> not-fully-defined operating modes or in modes where the P/S loads itself
> down dynamically.
> 
> > but a machine in hibernation should
> > cope with a power cut. In any case, I support your expectation that
> > using sleep/hibernate should not involve compromising monitors'
> > power-saving behaviour.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#176356

On Friday, January 6, 2017 11:11:45 AM CET Keith Bainbridge wrote:
> Ummm, why turn the monitor off first?

I use KDE's power management tool to e.g. dim the screen after 5 minutes, 
switch the screen off after 10 mins, suspend to RAM after 20 mins, and 
hibernate to disk when I close the lid.

If I leave the computer inactive for more than 10 minutes and then I close the 
lid, the system will hibernate. When I resume it, the monitor will be switched 
off at the end of the resume process.

> I use suspend rather than hibernate, on a macbook 4,1 and just close the
> lid. 

Yes, but I'd rather take advantage of all the energy saving options that are 
available. Booting up is so quick on a MacBookPro 12,1 that you may well use 
hibernate rather than suspend, and resume the system in few seconds.

[toc] | [prev] | [next] | [standalone]

#176357

[Multipart message — attachments visible in raw view] — view raw

I'm no expert, but I wonder if the book is resuming from hibernate in the
state it was at hibernate. If so, the system thinks the screen is off.


On the issue of power saving,  my battery lasts about 15 minutes when
working. In suspend it sits there for several days.  I don't know how much
more power you are saving with hibernate.

Keith Bainbridge

0447667468

keithrbaugroups@gmail.com

Sent from my APad

On 6 Jan 2017 16:55, "solitone" <solitone@mail.com> wrote:

> On Friday, January 6, 2017 11:11:45 AM CET Keith Bainbridge wrote:
> > Ummm, why turn the monitor off first?
>
> I use KDE's power management tool to e.g. dim the screen after 5 minutes,
> switch the screen off after 10 mins, suspend to RAM after 20 mins, and
> hibernate to disk when I close the lid.
>
> If I leave the computer inactive for more than 10 minutes and then I close
> the
> lid, the system will hibernate. When I resume it, the monitor will be
> switched
> off at the end of the resume process.
>
> > I use suspend rather than hibernate, on a macbook 4,1 and just close the
> > lid.
>
> Yes, but I'd rather take advantage of all the energy saving options that
> are
> available. Booting up is so quick on a MacBookPro 12,1 that you may well
> use
> hibernate rather than suspend, and resume the system in few seconds.
>
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web