Il 21/05/2014 15:30, Gerald Pfeifer ha scritto:

For my notebook, in addition to the main battery I've got a secondary that I uses when traveling.

In generally things work fine, except when openSUSE 13.1/GNOME decide to shoot me in my foot. :-)

When the secondary battery drains, and the system switches to back to the primary while I work, everything is fine.

When I then suspend-to-RAM and wake up again, I get a pop up indicating that my battery (singular) is running low and the system will be shut down.

/proc/acpi/battery/BAT*/* and the battery indicator in the status panel (upper right corner of the screen) both indicate that I have hours to go.

Still, within seconds a shutdown of the system is initiated without me having any change to stop.

Soo, two questions:

- How can we get this fixed properly such that whatever is deciding my battery is running low actually uses the same source of information as the status indicator (which gets it right)?

- As a stop gap measure, but generally: How can I avoid such a forced shutdown? Frankly, I'd rather let the system run out of battery than anything being force on my.

Gerald (on a long haul flight back home this evening)

I let more experts people talk about your specific problems but I doubt that you will have the issues resolved soon because power-management in openSUSE 13.1 is really inefficient and unreliable. If you have time and will, give a reading to my email in attach. Good luck! -- Marco Calistri (amdturion)

@Marco -

power-management in openSUSE 13.1 is really inefficient and unreliable.

I read your email, but I never responded to it as I have personal experience with over half a dozen laptops which behave differently (in fact, exactly as you request). For example, on the x220 I'm using to write this email, Battery Notification is working, Suspend to RAM at battery threshold is working, as is Hibernate. Indeed, Gerald's issue is a case of the behavior you complain about in your personal email working..just working a little too viciously. Rather than making sweeping statements that I have to try hard not to take personally, could you please file a bug report with details such as extracts from /var/log/messages and/or GNOME Settings Daemon logs (produced by running "gnome-settings-daemon --no-daemon --debug &> g-s-d-debug.txt") that show what's going on when power is low..we might actually be able to help :) On 30 May 2014 07:48, Gerald Pfeifer wrote:

...

- How can we get this fixed properly such that whatever is deciding my battery is running low actually uses the same source of information as the status indicator (which gets it right)?

GNOME relies heavily on upower, and I suspect the problem lies either between upower, or in gnome-settings-daemons interpretation/logic/implementation of what information it's receiving from upower. There is evidence of upower struggling with multiple batteries for a very long time (eg. https://bugzilla.gnome.org/show_bug.cgi?id=570133 ) I cant reproduce this problem on my hardware (I only have a single battery), but GNOME:STABLE:3.12 contains both a new gnome-settings-daemon and a new upower (it was mandatory for GNOME 3.12). If you're willing to go for a 'shot in the dark', you might have luck adding the following repository and running zypper dup (of course, I'd recommend backups/snapshots, etc, just in case it doesn't work) http://download.opensuse.org/repositories/GNOME:/STABLE:/3.12/openSUSE_13.1/

...

- As a stop gap measure, but generally: How can I avoid such a forced shutdown? Frankly, I'd rather let the system run out of battery than anything being force on my.

...any takers on this aspect?

I just lost work with only one battery in the system. When I got the critical power warning, I suspended to RAM, reconnected power, loaded for an hour and resumed, and then the system still decided to shut down. :-(

Is there a reason the system can't hibernate? the default behavior for critical battery power shortage is hibernate, which, while imperfect especially in your case, should at least result in work being maintained.

Since GNOME in openSUSE 13.1 is actively hurting me in the context of powersaving, I'd like disable this "shutdown when GNOME feels the battery is nearly empty" functionality.

1) In the system configuration I see "When battery power is critical" under "Power", alas that only offers "Shutdown" and "Hibernate".

2) In dconf-editor I found critical-batter-action which seems to do what I need, alas trying to set it via the command-line fails:

dconf write /org/gnome/settings-daemon/plugins/power/critical-battery-action nothing

just gives me "error: 0-7:unable to infer type".

How can I set this programmatically?

Try, gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action 'nothing' This appears to set things the way you want in dconf-editor - unfortunately my laptop has too long a battery life for me to confirm it works for some hours yet :) Hope this helps, - Richard -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On Sat, 2014-05-31 at 01:59 -0300, Marco Calistri wrote:

I executed your command but here on my machine something is not working:

If I use --no-daemon the result is this:

marco@linux-turion64:~/upower> /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --no-daemon --debug

** (gnome-settings-daemon:3296): WARNING **: Opzione --no-daemon sconosciuta (unknown option)

If I remove --no-daemon the result is this:

marco@linux-turion64:~/upower> /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --debug

** (gnome-settings-daemon:3309): WARNING **: Name taken or bus went away - shutting down ** (gnome-settings-daemon:3309): DEBUG: Shutting down ** (gnome-settings-daemon:3309): DEBUG: SettingsDaemon finished

Absolutely right, my mistake, that'll teach me for spitting out debug commands from memory the right command to run gnome-settings-daemon in debug mode and replacing the one that is currently running in your gnome session is: /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --replace --debug If you could throw the output of that in a log during some of your power management problems, it should give us some very interesting clues Hope this helps, Richard -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 01/06/2014 11:03, Richard Brown ha scritto:

On Sat, 2014-05-31 at 01:59 -0300, Marco Calistri wrote:

...

I executed your command but here on my machine something is not working:

If I use --no-daemon the result is this:

marco@linux-turion64:~/upower> /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --no-daemon --debug

** (gnome-settings-daemon:3296): WARNING **: Opzione --no-daemon sconosciuta (unknown option)

If I remove --no-daemon the result is this:

marco@linux-turion64:~/upower> /usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --debug

** (gnome-settings-daemon:3309): WARNING **: Name taken or bus went away - shutting down ** (gnome-settings-daemon:3309): DEBUG: Shutting down ** (gnome-settings-daemon:3309): DEBUG: SettingsDaemon finished

Absolutely right, my mistake, that'll teach me for spitting out debug commands from memory

the right command to run gnome-settings-daemon in debug mode and replacing the one that is currently running in your gnome session is:

/usr/lib/gnome-settings-daemon-3.0/gnome-settings-daemon --replace --debug

If you could throw the output of that in a log during some of your power management problems, it should give us some very interesting clues

Hope this helps,

Richard

Bug filed: https://bugzilla.novell.com/show_bug.cgi?id=880869 Regards. -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.11.10-11-default Gnome 3.10.1 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On 27 June 2014 18:08, Marco Calistri wrote:

Dear Richard,

I opened a bug some time ago but I am sure nobody have take it to verify:

https://bugzilla.novell.com/show_bug.cgi?id=880869

BIG SNIP! You're wrong to think that no one has paid attention to this issue. I've been looking at the bug, but haven't commented on it because I don't have the hardware to reproduce the issue, and because the logs simply that the issue might actually be a hardware issue - there seems to be regular notifications hitting gnome-settings-daemon that 'state is now charging' I've searched upstream for similar bugs, but the closest I have found were closed as INVALID because the issue was deemed to be local issues with broken/misbehaving batteries in peoples laptops. But without similar hardware of my own, I'm in no position to suggest that - so I'd rather leave the bug 'untouched' rather than push it in either direction Are you sure your batteries are happy and healthy? Have you been able to reproduce the problem with different batteries installed? do you have a similar laptop with the same issue? Cant you add the same logs to the bug? ps. I get that you're frustrated, and I sympathise, I really do, but please can you sympathise that working on openSUSE is something I do in my spare time as my hobby. The repeated broad statements, the doom and gloom, and general malaise that fills your last paragraph really discourages me..and such discouragement makes it harder for me to work with you to find a solution for your problem. I know it can be tough when something is broken, but try and keep your chin up and work with us rather than tearing us down, please? -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Hi. On Fri, Jun 27, 2014 at 04:02:56PM -0300, Marco Calistri wrote:

I'm frustrated because in my personal opinion Linux in general is getting worse in terms of user usability comparing it to Microsoft software and this frustrate me enough.

That's fair enough. I suggest to channel that energy into making things better. Not worse by being inappropriately offensive on Free Software lists.

Beside GNOME3 and poor (or totally broken power-management if you prefer) I can also add Bluetooth among the things that are getting worse or are totally broken and it is not just a frustration, but a fact!

That may be true. Very well so. Fortunately, you're dealing with Free Software. Not only can you attempt to fix it yourself, you can also hire someone to do it. Even better: You can redistribute the changes to your community. Generally though, expecting things to just fix themselves is not going to work.

If the power management problem is an hardware problem, why on Windows 7 I don't notice it? I don't know. But hypothecically, a driver can paper over the broken hardware.

If the problem is limited to just some brands or laptop model, why it is not documented into the opensuse Release Notes?

Probably because nobody did it. Are you volunteering for the next release?

I doubt instead that it is the product of big changes happened recently into Linux not just at kernel level but also inside DE (Gnome3 especially) as well as may be due to the scarce interest to develop a better power-management for laptop. I have glanced over the archives of the relevant mailing list https://mail.gnome.org/mailman/listinfo/gnome-power-manager-list I couldn't find any post from you. I suggest to reach out there. In case you haven't found it yourself, yet, I suggest having a look at this page (although it seems to be a bit outdated) https://projects.gnome.org/gnome-power-manager/bugs.html https://wiki.ubuntu.com/DebuggingGNOMEPowerManager also looks interesting.

Good luck, Tobi -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 27/06/2014 14:16, Richard Brown ha scritto:

On 27 June 2014 18:08, Marco Calistri wrote:

...

Dear Richard,

I opened a bug some time ago but I am sure nobody have take it to verify:

https://bugzilla.novell.com/show_bug.cgi?id=880869

BIG SNIP!

You're wrong to think that no one has paid attention to this issue. I've been looking at the bug, but haven't commented on it because I don't have the hardware to reproduce the issue, and because the logs simply that the issue might actually be a hardware issue - there seems to be regular notifications hitting gnome-settings-daemon that 'state is now charging'

I've searched upstream for similar bugs, but the closest I have found were closed as INVALID because the issue was deemed to be local issues with broken/misbehaving batteries in peoples laptops. But without similar hardware of my own, I'm in no position to suggest that - so I'd rather leave the bug 'untouched' rather than push it in either direction

Are you sure your batteries are happy and healthy? Have you been able to reproduce the problem with different batteries installed? do you have a similar laptop with the same issue? Cant you add the same logs to the bug?

ps. I get that you're frustrated, and I sympathise, I really do, but please can you sympathise that working on openSUSE is something I do in my spare time as my hobby. The repeated broad statements, the doom and gloom, and general malaise that fills your last paragraph really discourages me..and such discouragement makes it harder for me to work with you to find a solution for your problem. I know it can be tough when something is broken, but try and keep your chin up and work with us rather than tearing us down, please?

Again on this topic, This is an (I guess/hope) interesting message I get from Yast service management configurations: upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled) Active: active (running) since Mon 2014-06-30 20:34:13 BRT; 1h 21min ago Docs: man:upowerd(8) Main PID: 786 (upowerd) CGroup: /system.slice/upower.service `-786 /usr/lib/upower/upowerd Jun 30 20:34:13 linux-turion64 systemd[1]: Starting Daemon for power management... Jun 30 20:34:13 linux-turion64 systemd[1]: Started Daemon for power management. Jun 30 20:34:14 linux-turion64 upowerd[786]: (upowerd:786): UPower-Linux-WARNING **: energy_full (43.815600) is greater than energy_full_design (41.990400) Are there any relations with the latest lines of Warning and my problem of system shutdown due to battery running below minimum threshold ?? Thanks. Regards, -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.11.10-17-default Gnome 3.10.1 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

* Marco Calistri [06-30-14 21:00]:

Il 27/06/2014 14:16, Richard Brown ha scritto:

...

On 27 June 2014 18:08, Marco Calistri wrote:

...

Dear Richard,

I opened a bug some time ago but I am sure nobody have take it to verify:

https://bugzilla.novell.com/show_bug.cgi?id=880869

BIG SNIP!

[...] Much bigger snip

This is an (I guess/hope) interesting message I get from Yast service management configurations:

upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled) Active: active (running) since Mon 2014-06-30 20:34:13 BRT; 1h 21min ago Docs: man:upowerd(8) Main PID: 786 (upowerd) CGroup: /system.slice/upower.service `-786 /usr/lib/upower/upowerd

Jun 30 20:34:13 linux-turion64 systemd[1]: Starting Daemon for power management... Jun 30 20:34:13 linux-turion64 systemd[1]: Started Daemon for power management. Jun 30 20:34:14 linux-turion64 upowerd[786]: (upowerd:786): UPower-Linux-WARNING **: energy_full (43.815600) is greater than energy_full_design (41.990400)

Are there any relations with the latest lines of Warning and my problem of system shutdown due to battery running below minimum threshold ??

Just a guess but wouldn't it more likely be wrong parameters or reading wrong levels for your particular battery. The *expected* energy_full_design level is less than the level read or presented to your software. ie: not properly supported which I believe is the jist of the earlier conversation. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On Mon, 30 Jun 2014 22:00:35 -0400 Patrick Shanahan wrote:

* Malcolm [06-30-14 21:56]:

...

On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri wrote:

<snip>

[...] another snip

...

Why is the upower service enabled. On all my systems the upower service is disabled (and running fine), I have two HP Probook 4440s and a HP ProBook 4430s.

What do you get from;

upower -i /org/freedesktop/UPower/devices/battery_BAT0

PS I only use GNOME and have all HP systems (six altogether) and one Dell, two have built in bluetooth and I also use a dongle for the others when needed, yet to strike any issues with either my bt mouse or LG230 phone(s)....

You are in control: systemctl disable upower

ps: running on one of my four desktops and not on either laptop ???

Hi But I never disabled it in the first place, on the output from Marco, it shows enabled.... which AFAIK is not the default....? For example; systemctl status upower.service upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled) Active: active (running) since Mon 2014-06-30 17:17:10 CDT; 3h 21min ago Docs: man:upowerd(8) Main PID: 1181 (upowerd) CGroup: /system.slice/upower.service └─1181 /usr/lib/upower/upowerd Jun 30 17:17:10 ernie.gekkota.dyndns.org systemd[1]: Started Daemon for power management. -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 3:53, 3 users, load average: 0.10, 0.06, 0.08 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 30/06/2014 23:13, Malcolm ha scritto:

On Mon, 30 Jun 2014 22:00:35 -0400 Patrick Shanahan wrote:

...

* Malcolm [06-30-14 21:56]:

...

On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri wrote:

<snip>

[...] another snip

...

Why is the upower service enabled. On all my systems the upower service is disabled (and running fine), I have two HP Probook 4440s and a HP ProBook 4430s.

What do you get from;

upower -i /org/freedesktop/UPower/devices/battery_BAT0

PS I only use GNOME and have all HP systems (six altogether) and one Dell, two have built in bluetooth and I also use a dongle for the others when needed, yet to strike any issues with either my bt mouse or LG230 phone(s)....

You are in control: systemctl disable upower

ps: running on one of my four desktops and not on either laptop ???

Hi But I never disabled it in the first place, on the output from Marco, it shows enabled.... which AFAIK is not the default....?

For example;

systemctl status upower.service

upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled) Active: active (running) since Mon 2014-06-30 17:17:10 CDT; 3h 21min ago Docs: man:upowerd(8) Main PID: 1181 (upowerd) CGroup: /system.slice/upower.service └─1181 /usr/lib/upower/upowerd

Jun 30 17:17:10 ernie.gekkota.dyndns.org systemd[1]: Started Daemon for power management.

@Malcolm: marco@linux-turion64:~> upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: (null) power supply: no updated: mer 31 dic 1969 21:00:00 BRT (1404244550 seconds ago) has history: no has statistics: no unknown warning-level: unknown icon-name: '(null)' upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled) Active: active (running) since mar 2014-07-01 09:25:26 BRT; 7h ago Docs: man:upowerd(8) Main PID: 783 (upowerd) CGroup: /system.slice/upower.service └─783 /usr/lib/upower/upowerd sudo systemctl status upower.service lug 01 09:25:25 linux-turion64 systemd[1]: Starting Daemon for power management... lug 01 09:25:26 linux-turion64 systemd[1]: Started Daemon for power management. lug 01 09:25:26 linux-turion64 upowerd[783]: (upowerd:783): UPower-Linux-WARNING **: energy_full (43.772400) is greater than energy_full_design (41.990400) @Patrick: At the end have I to disable upower from Yast or not? Is it a problem with my battery or probably with something else insided upower: look the date reported: ---> updated: mer 31 dic 1969 21:00:00 BRT (1404244550 seconds ago) Thanks both of you for replies. (Running Gnome 3.12.1) Cheers, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 01/07/2014 17:10, Patrick Shanahan ha scritto:

* Marco Calistri [07-01-14 16:03]: [...]

...

...

...

You are in control: systemctl disable upower

ps: running on one of my four desktops and not on either laptop

[...]

...

marco@linux-turion64:~> upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: (null) power supply: no updated: mer 31 dic 1969 21:00:00 BRT (1404244550 seconds ago) has history: no has statistics: no unknown warning-level: unknown icon-name: '(null)'

upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled) Active: active (running) since mar 2014-07-01 09:25:26 BRT; 7h ago Docs: man:upowerd(8) Main PID: 783 (upowerd) CGroup: /system.slice/upower.service └─783 /usr/lib/upower/upowerd

sudo systemctl status upower.service

lug 01 09:25:25 linux-turion64 systemd[1]: Starting Daemon for power management... lug 01 09:25:26 linux-turion64 systemd[1]: Started Daemon for power management. lug 01 09:25:26 linux-turion64 upowerd[783]: (upowerd:783): UPower-Linux-WARNING **: energy_full (43.772400) is greater than energy_full_design (41.990400)

@Patrick:

At the end have I to disable upower from Yast or not?

no but I imagine that you can. Also: systemctl stop upower systemctl disable upower

You *do* read the responses you get ???

...

Is it a problem with my battery or probably with something else insided

AGAIN: appears an incompatibility between your system and the software, ie: support for your system is not there. Which you were told earlier in the thread.

w/o systems availabile for testing, much can be missed. And if you do not submit bug reports, unlikely to *ever* be fixed. Really, free software is not enitrely free. You are expected to help, ie: with bug reports.

All OK, I accept your blames but certainly I'm not alone with this not supported hardware problem, then do not base the overall issue still not resolved just upon the fact that myself have not been a good free-software user and has not contributed with opening of bug reports because many others are complaining about same not working power-management in Linux. I red the responses from you and Malcolm and these are not in sync about upower enabling, for this reason I'm asking confirmations, beside this it could be possible I miss something because I'm not Anglo-Saxon then some words or concepts can even escape from my understanding. Regards, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 01/07/2014 18:05, Malcolm ha scritto:

On Tue, 01 Jul 2014 17:42:57 -0300 Marco Calistri wrote:

...

Il 01/07/2014 17:10, Patrick Shanahan ha scritto:

...

* Marco Calistri [07-01-14 16:03]: [...]

...

...

...

You are in control: systemctl disable upower

ps: running on one of my four desktops and not on either laptop

[...]

...

marco@linux-turion64:~> upower -i /org/freedesktop/UPower/devices/battery_BAT0 native-path: (null) power supply: no updated: mer 31 dic 1969 21:00:00 BRT (1404244550 seconds ago) has history: no has statistics: no unknown warning-level: unknown icon-name: '(null)'

upower.service - Daemon for power management Loaded: loaded (/usr/lib/systemd/system/upower.service; enabled) Active: active (running) since mar 2014-07-01 09:25:26 BRT; 7h ago Docs: man:upowerd(8) Main PID: 783 (upowerd) CGroup: /system.slice/upower.service └─783 /usr/lib/upower/upowerd

sudo systemctl status upower.service

lug 01 09:25:25 linux-turion64 systemd[1]: Starting Daemon for power management... lug 01 09:25:26 linux-turion64 systemd[1]: Started Daemon for power management. lug 01 09:25:26 linux-turion64 upowerd[783]: (upowerd:783): UPower-Linux-WARNING **: energy_full (43.772400) is greater than energy_full_design (41.990400)

@Patrick:

At the end have I to disable upower from Yast or not?

no but I imagine that you can. Also: systemctl stop upower systemctl disable upower

You *do* read the responses you get ???

...

Is it a problem with my battery or probably with something else insided

AGAIN: appears an incompatibility between your system and the software, ie: support for your system is not there. Which you were told earlier in the thread.

w/o systems availabile for testing, much can be missed. And if you do not submit bug reports, unlikely to *ever* be fixed. Really, free software is not enitrely free. You are expected to help, ie: with bug reports.

All OK, I accept your blames but certainly I'm not alone with this not supported hardware problem, then do not base the overall issue still not resolved just upon the fact that myself have not been a good free-software user and has not contributed with opening of bug reports because many others are complaining about same not working power-management in Linux.

I red the responses from you and Malcolm and these are not in sync about upower enabling, for this reason I'm asking confirmations, beside this it could be possible I miss something because I'm not Anglo-Saxon then some words or concepts can even escape from my understanding.

Regards,

Hi On my systems upower is not enabled, yours is for what ever reason? I'm not running 3.12 only 3.10.

On this HP 4440s I run with the following boot option (for brightness control);

acpi_osi=\"!Windows 2012\"

Maybe adding this will help with newer hardware?

Hi Malcolm! I don't know why it is enabled I was just checking into Yast and found it that way. I installed 3.12 a couple of days ago just to see if with this new release the problems go away (suggestion of giving a try to 3.12 by Richard Brown to one of my previous post). I have the following boot option on my laptop, it is not new hardware at all: Lenovo Z470 Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.10-17-default root=UUID=d7862dd1-e694-4817-9fe4-adb352109a9f resume=/dev/disk/by-id/ata-SAMSUNG_HM501II_S2PMJ56B607218-part7 splash=silent quiet i915.i915_enable_rc6=7 i915.i915_enable_fbc=1 i915.lvds_downclock=1 drm.vblankoffdelay=1 showopts I wont add something if not specific to resolve my particular issue. Thanks for your reply. Cheers, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On Mon, 07 Jul 2014 12:33:18 -0300 Marco Calistri wrote:

Malcolm,

During this meanwhile I updated my kernel to latest stable which is something around version 3.15, then I cleaned all my previous boot options from grub2 and added just your suggested line:

acpi_osi=\"!Windows 2012\"

I have not yet had the possibility to test the reached battery limit but I noticed an encouraging fact: the warning message of Upower about battery design is disappeared:

UPower-Linux-WARNING **: energy_full (43.772400) is greater than energy_full_design (41.990400)

Then may be your suggestion did the trick!

Regards,

Hi Try it with and without when you get a chance as hopefully the 3.15 kernel doesn't need it as the issue could be fixed in those newer kernels. -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 13:36, 3 users, load average: 0.36, 0.29, 0.26 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 07/07/2014 13:13, Marco Calistri ha scritto:

Il 07/07/2014 12:46, Malcolm ha scritto:

...

On Mon, 07 Jul 2014 12:33:18 -0300 Marco Calistri wrote:

...

Malcolm,

During this meanwhile I updated my kernel to latest stable which is something around version 3.15, then I cleaned all my previous boot options from grub2 and added just your suggested line:

acpi_osi=\"!Windows 2012\"

I have not yet had the possibility to test the reached battery limit but I noticed an encouraging fact: the warning message of Upower about battery design is disappeared:

UPower-Linux-WARNING **: energy_full (43.772400) is greater than energy_full_design (41.990400)

Then may be your suggestion did the trick!

Regards,

Hi Try it with and without when you get a chance as hopefully the 3.15 kernel doesn't need it as the issue could be fixed in those newer kernels.

Fine!

Cheers,

Malcolm, I reached critical battery level but system has not been hibernated. The good thing is that now I see battery warning notifications on desktop while before I was "totally blind". I collected a detail of current upower I would like to submit here to your and others attention: marco@linux-turion64:~> sudo upower -d Device: /org/freedesktop/UPower/devices/line_power_ACAD native-path: ACAD power supply: yes updated: mar 08 lug 2014 12:32:43 BRT (19 seconds ago) has history: no has statistics: no line-power warning-level: none online: yes icon-name: 'ac-adapter-symbolic' Device: /org/freedesktop/UPower/devices/battery_BAT1 native-path: BAT1 vendor: SANYO model: L09S6Y02 power supply: yes updated: mar 08 lug 2014 12:32:43 BRT (19 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: charging *warning-level: none* energy: 1,9278 Wh energy-empty: 0 Wh energy-full: 47,061 Wh energy-full-design: 135,601 Wh energy-rate: 25,7922 W voltage: 10,778 V time to full: 1,7 hours percentage: 4% capacity: 34,7054% technology: lithium-ion icon-name: 'battery-caution-charging-symbolic' History (charge): 1404833561 4,000 charging History (rate): 1404833563 25,792 charging 1404833561 25,817 charging 1404833494 24,973 charging Device: /org/freedesktop/UPower/devices/keyboard_0003o046DoC52Bx0005 native-path: /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.2/0003:046D:C52B.0004/0003:046D:C52B.0005 vendor: Logitech, Inc. model: K230 serial: 4E184B5D power supply: no updated: mar 08 lug 2014 12:32:41 BRT (21 seconds ago) has history: yes has statistics: no keyboard present: yes rechargeable: yes state: discharging warning-level: none percentage: 90% icon-name: 'battery-full-symbolic' Device: /org/freedesktop/UPower/devices/DisplayDevice power supply: yes updated: mer 31 dic 1969 21:00:00 BRT (1404833582 seconds ago) has history: no has statistics: no battery present: yes state: charging warning-level: none energy: 1,9278 Wh energy-full: 47,061 Wh energy-rate: 25,7922 W time to full: 1,7 hours percentage: 4% icon-name: 'battery-caution-charging-symbolic' Daemon: daemon-version: 0.99.0 on-battery: no lid-is-closed: no lid-is-present: yes is-docked: no *critical-action: HybridSleep* On particular I would like if are there any ways to customize "critical-action" field which now reports "HybridSleep" (what does it means in the end??) and warning-level: into battery section above. Thanks, -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.15.3-1.g42bf625-default Gnome 3.12.2 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Quoting Marco Calistri :

Daemon: daemon-version: 0.99.0 on-battery: no lid-is-closed: no lid-is-present: yes is-docked: no *critical-action: HybridSleep*

On particular I would like if are there any ways to customize "critical-action" field which now reports "HybridSleep" (what does it means in the end??)

Not going directly no your actual issue, but at least trying to answer this question: HybridSleep is a combination of hybernation (data saved to disk, then system powered off) and 'sleep' (data kept in memory, sleep mode at reduced power consumption. Wikipedia outlines it rather easy understandable (http://en.wikipedia.org/wiki/Sleep_mode#Hybrid_sleep) """ Sleep mode and hibernation can be combined: the contents of RAM are first copied to non-volatile storage like for regular hibernation, but then, instead of powering down, the computer enters sleep mode. This approach combines the benefits of sleep mode and hibernation: The machine can resume instantaneously, but it can also be powered down completely (e.g. due to loss of power) without loss of data, because it is already effectively in a state of hibernation. """ Using this as 'critical' power action sounds rather useless: it's almost certain that 'sleep mode' will not be there for too long.. but then, it does not really matter neither: the content is stored to disk and if the battery runs low, so be it. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 10/07/2014 11:25, Dominique Leuenberger a.k.a. Dimstar ha scritto:

Quoting Marco Calistri :

...

Daemon: daemon-version: 0.99.0 on-battery: no lid-is-closed: no lid-is-present: yes is-docked: no *critical-action: HybridSleep*

On particular I would like if are there any ways to customize "critical-action" field which now reports "HybridSleep" (what does it means in the end??)

Not going directly no your actual issue, but at least trying to answer this question:

HybridSleep is a combination of hybernation (data saved to disk, then system powered off) and 'sleep' (data kept in memory, sleep mode at reduced power consumption.

Wikipedia outlines it rather easy understandable (http://en.wikipedia.org/wiki/Sleep_mode#Hybrid_sleep) """ Sleep mode and hibernation can be combined: the contents of RAM are first copied to non-volatile storage like for regular hibernation, but then, instead of powering down, the computer enters sleep mode. This approach combines the benefits of sleep mode and hibernation: The machine can resume instantaneously, but it can also be powered down completely (e.g. due to loss of power) without loss of data, because it is already effectively in a state of hibernation. """

Using this as 'critical' power action sounds rather useless: it's almost certain that 'sleep mode' will not be there for too long.. but then, it does not really matter neither: the content is stored to disk and if the battery runs low, so be it.

Cheers, Dominique

Hi Dominique! Thanks for the description of HybridSleep! In any case that is not working on my laptop neither, I'm going to test the suggestion made by Malcolm about pm-utils. Regards, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri wrote:

Il 10/07/2014 01:19, Malcolm ha scritto:

...

zypper if pm-utils

Malcolm,

The output difference is related to upower and not to pm-utils which is same version as your while my upower is the one for Gnome 3.12:

marco@linux-turion64:~> zypper if pm-utils

Informazioni per pacchetto pm-utils: ------------------------------------ Repository: openSUSE-13.1-Update Nome: pm-utils Versione: 1.4.1-33.5.1 Arch: x86_64 Fornitore: openSUSE Installato: Sì Stato: aggiornato Dimensione installata: 184,1 KiB Sommario: Strumenti per sospendere e ibernare computer Descrizione: pm-utils provide simple shell command line tools to suspend and hibernate computers that can be used to run vendor or distro supplied scripts on suspend and resume.

marco@linux-turion64:~> zypper if upower

Informazioni per pacchetto upower: ---------------------------------- Repository: GNOME-3.12 Nome: upower Versione: 0.99.0-1.3 Arch: x86_64 Fornitore: obs://build.opensuse.org/GNOME Installato: Sì Stato: aggiornato Dimensione installata: 270,3 KiB Sommario: Struttura di enumerazione dei dispositivi energetici Descrizione: UPower is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus. Some operations (such as suspending the system) are restricted using PolicyKit.

Cheers,

Hi So what about downgrading the upower package back to the current oss update version? Can you also change the setting via; gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action hibernate -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 3 days 12:12, 4 users, load average: 0.12, 0.19, 0.17 CPU Intel® B840@1.9GHz | GPU Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 11/07/2014 11:21, Malcolm ha scritto:

On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri wrote:

...

Il 10/07/2014 01:19, Malcolm ha scritto:

...

zypper if pm-utils

Malcolm,

The output difference is related to upower and not to pm-utils which is same version as your while my upower is the one for Gnome 3.12:

marco@linux-turion64:~> zypper if pm-utils

Informazioni per pacchetto pm-utils: ------------------------------------ Repository: openSUSE-13.1-Update Nome: pm-utils Versione: 1.4.1-33.5.1 Arch: x86_64 Fornitore: openSUSE Installato: Sì Stato: aggiornato Dimensione installata: 184,1 KiB Sommario: Strumenti per sospendere e ibernare computer Descrizione: pm-utils provide simple shell command line tools to suspend and hibernate computers that can be used to run vendor or distro supplied scripts on suspend and resume.

marco@linux-turion64:~> zypper if upower

Informazioni per pacchetto upower: ---------------------------------- Repository: GNOME-3.12 Nome: upower Versione: 0.99.0-1.3 Arch: x86_64 Fornitore: obs://build.opensuse.org/GNOME Installato: Sì Stato: aggiornato Dimensione installata: 270,3 KiB Sommario: Struttura di enumerazione dei dispositivi energetici Descrizione: UPower is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus. Some operations (such as suspending the system) are restricted using PolicyKit.

Cheers,

Hi So what about downgrading the upower package back to the current oss update version?

Can you also change the setting via;

gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action

gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action hibernate

Yes, it could be a valid attempt, however I red from link you posted that problem was present also with previous upower version, in any case it doesn't cost me nothing to try upower rollback. In addition to use critical-battery-action hibernate, could I put also critical-battery-action suspend I think, right? Cheers, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 11/07/2014 11:59, Malcolm ha scritto:

On Fri, 11 Jul 2014 11:46:50 -0300 Marco Calistri wrote:

...

Il 11/07/2014 11:21, Malcolm ha scritto:

...

On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri wrote:

...

Il 10/07/2014 01:19, Malcolm ha scritto:

...

zypper if pm-utils

Malcolm,

The output difference is related to upower and not to pm-utils which is same version as your while my upower is the one for Gnome 3.12:

marco@linux-turion64:~> zypper if pm-utils

Informazioni per pacchetto pm-utils: ------------------------------------ Repository: openSUSE-13.1-Update Nome: pm-utils Versione: 1.4.1-33.5.1 Arch: x86_64 Fornitore: openSUSE Installato: Sì Stato: aggiornato Dimensione installata: 184,1 KiB Sommario: Strumenti per sospendere e ibernare computer Descrizione: pm-utils provide simple shell command line tools to suspend and hibernate computers that can be used to run vendor or distro supplied scripts on suspend and resume.

marco@linux-turion64:~> zypper if upower

Informazioni per pacchetto upower: ---------------------------------- Repository: GNOME-3.12 Nome: upower Versione: 0.99.0-1.3 Arch: x86_64 Fornitore: obs://build.opensuse.org/GNOME Installato: Sì Stato: aggiornato Dimensione installata: 270,3 KiB Sommario: Struttura di enumerazione dei dispositivi energetici Descrizione: UPower is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus. Some operations (such as suspending the system) are restricted using PolicyKit.

Cheers,

Hi So what about downgrading the upower package back to the current oss update version?

Can you also change the setting via;

gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action

gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action hibernate

Yes, it could be a valid attempt, however I red from link you posted that problem was present also with previous upower version, in any case it doesn't cost me nothing to try upower rollback.

In addition to use critical-battery-action hibernate, could I put also critical-battery-action suspend I think, right?

Cheers,

Hi I would assume suspend would work, maybe try on the current version first?

Hi Malcolm, suspend works both from console command and through gnome-shell extension I installed recently. Regards, -- Marco Calistri (amdturion) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

Il 11/07/2014 13:20, Marco Calistri ha scritto:

Il 11/07/2014 12:09, Marco Calistri ha scritto:

...

Il 11/07/2014 11:59, Malcolm ha scritto:

...

On Fri, 11 Jul 2014 11:46:50 -0300 Marco Calistri wrote:

...

Il 11/07/2014 11:21, Malcolm ha scritto:

...

On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri wrote:

...

Il 10/07/2014 01:19, Malcolm ha scritto: > zypper if pm-utils

Malcolm,

The output difference is related to upower and not to pm-utils which is same version as your while my upower is the one for Gnome 3.12:

marco@linux-turion64:~> zypper if pm-utils

Informazioni per pacchetto pm-utils: ------------------------------------ Repository: openSUSE-13.1-Update Nome: pm-utils Versione: 1.4.1-33.5.1 Arch: x86_64 Fornitore: openSUSE Installato: Sì Stato: aggiornato Dimensione installata: 184,1 KiB Sommario: Strumenti per sospendere e ibernare computer Descrizione: pm-utils provide simple shell command line tools to suspend and hibernate computers that can be used to run vendor or distro supplied scripts on suspend and resume.

marco@linux-turion64:~> zypper if upower

Informazioni per pacchetto upower: ---------------------------------- Repository: GNOME-3.12 Nome: upower Versione: 0.99.0-1.3 Arch: x86_64 Fornitore: obs://build.opensuse.org/GNOME Installato: Sì Stato: aggiornato Dimensione installata: 270,3 KiB Sommario: Struttura di enumerazione dei dispositivi energetici Descrizione: UPower is an abstraction for enumerating power devices, listening to device events and querying history and statistics. Any application or service on the system can access the org.freedesktop.UPower service via the system message bus. Some operations (such as suspending the system) are restricted using PolicyKit.

Cheers,

Hi So what about downgrading the upower package back to the current oss update version?

Can you also change the setting via;

gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action

gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action hibernate

Yes, it could be a valid attempt, however I red from link you posted that problem was present also with previous upower version, in any case it doesn't cost me nothing to try upower rollback.

In addition to use critical-battery-action hibernate, could I put also critical-battery-action suspend I think, right?

Cheers,

Hi I would assume suspend would work, maybe try on the current version first?

Hi Malcolm,

suspend works both from console command and through gnome-shell extension I installed recently.

Regards,

Done:

Daemon: daemon-version: 0.9.23 can-suspend: yes can-hibernate: yes on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no

gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action 'hibernate'

Let's wait the critical threshold...

Cheers,

Dear Malcolm, Nothing to do: with Gnome 3.12 I have to use upower 0.99, otherwise I lack other functionalities as the battery icon and management into the top right corner of Gnome Desktop. I am now able to make the system don't simply shutting down by setting the parameter plugins.power to 'suspend': gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action 'suspend' Definitely by setting the plugin to 'hibernate' doesn't works never! Now I'm almost satisfied because I finally have both a notification on desktop whenever battery level goes low and a system suspension at critical level. Regards, -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.15.5-1.g01d2774-default Gnome 3.12.2 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

On 30 July 2014 21:10, Gerald Pfeifer wrote:

I am running this now and am pleased about the improvements I am seeing. Nothing revolutionary, but network management for wired connections seems improved, some visual improvements (somewhat approaching Android in terms of messages boxes, interestingly), a detail here, a detail there.

I just got back from GUADEC, I'm expecting us to see more tweaks and tunings in 3.14 and 3.16 in this area..they're still not happy with how notification works, though they seem pleased with the general direction of travel

However, I have not been able to run down batteries with two batteries installed to see whether upower/GNOME now cooperate more nicely, but may get a chance next week.

Please let us know how it goes

...

Is there a reason the system can't hibernate? the default behavior for critical battery power shortage is hibernate, which, while imperfect especially in your case, should at least result in work being maintained.

Firefox consumes so much (virtual) memory that my 2GB swap partition that I've had for a couple of years is not sufficient any more, now that my notebook features 8GB of RAM. With the right swap/suspend strategy that should be easily sufficient (I do not have > 2GB of dirty pages), but that's not a GNOME problem.

No, but the 'fix' is already in Factory (and I think it might have even shipped in 13.1) - YaST has a tickbox in the partitioner during installation to 'Expand Swap for Hibernate' That's no good for those of us who have it too small and who upgrade..but I guess you could get creative with shrinking partitions and creating a second swap partition to make up the difference

Noooow, a curious question: If, after the change above, I run

gsettings get org.gnome.settings-daemon.plugins.power critical-battery-action

that shows 'nothing' as expected. In the graphical settings, the Power module shows "When battery power is critical" "Power off", however.

Bug or "feature"?

I imagine "feature" - Settings modules can only show settings it's aware of (even if theres 'hidden' values in gsettings).. I did speak to somebody at GUADEC however who understood the problems this causes, I'm hoping we see changes in upcoming versions. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org

...

...

On 7/30/2014 at 01:10 PM, Gerald Pfeifer wrote: Hi Richard, If you're willing to go for a 'shot in the dark', you might have luck adding the following repository and running zypper dup (of course, I'd recommend backups/snapshots, etc, just in case it doesn't work)

http://download.opensuse.org/repositories/GNOME:/STABLE:/3.12/openSUSE_13.1/

I am running this now and am pleased about the improvements I am seeing. Nothing revolutionary, but network management for wired connections seems improved, some visual improvements (somewhat approaching Android in terms of messages boxes, interestingly), a detail here, a detail there.

However, I have not been able to run down batteries with two batteries installed to see whether upower/GNOME now cooperate more nicely, but may get a chance next week.

btw - If you want to test the interaction without waiting to run your batteries all the way down you can do this (I tested this on SLED12 that has the new upower) jump onto battery and then see how much estimated time you have left. For this lets say 2 hours (7200 seconds) set the times to be slightly lower than your current time left gsettings set org.gnome.settings-daemon.plugins.power time-low 7000 gsettings set org.gnome.settings-daemon.plugins.power time-critical 6800 gsettings set org.gnome.settings-daemon.plugins.power time-action 6600 Just make sure after testing you remember to set these back to real values or be ticked off when you queue up some stuff to look at, unplug and then watch in horror as your system happily shuts down when it drops below these high values a few minutes into the commute home :) -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org