[opensuse-gnome] How to avoid GNOME shutting down due to battery (allegedly) running low?
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) -- Dr. Gerald Pfeifer <gp@suse.com> Sr. Director Product Management and Operations, SUSE -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
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)
On Wed, 21 May 2014, Gerald Pfeifer wrote:
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)?
Even if there is not answer to this here..
- 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. :-( 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? Gerald -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
@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 <gp@suse.com> 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
Il 30/05/2014 04:14, Richard Brown ha scritto:
@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 :)
Hi Richard I am not making sweeping statements, in reality I'm disappointed because things are going to break after last biggest changes as sysvinit-->systemd and now gpm (older power managements used in Gnome) -->upower. 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
On 30 May 2014 07:48, Gerald Pfeifer <gp@suse.com> 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
-- 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 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
Ok Richard, I will try it again. Regards, -- Marco Calistri (amdturion) opensuse 12.2 (Mantis) 64 bit - Kernel 3.4.6-2.10-desktop Gnome 3.6.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
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
Il 30/05/2014 04:14, Richard Brown ha scritto:
@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 :)
BIG SNIP!
- Richard
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 This is one of the reasons why I stopped to open bug reports for Opensuse, the other is that I'm an cure-less lazy person, the last is that Linux usability is getting worse in last years (looks to Gnome3, power management for example) and I lost my hope to find a definitive substitute for Microsoft Windows. 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 27 June 2014 18:08, Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Dear Richard,
I opened a bug some time ago but I am sure nobody have take it to verify:
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
Il 27/06/2014 14:16, Richard Brown ha scritto:
On 27 June 2014 18:08, Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Dear Richard,
I opened a bug some time ago but I am sure nobody have take it to verify:
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?
Hello Richard! First of all this was not nothing personal directed to you, I named you simply and _just_ because you invited me to open a bug instead to simply complain about stuff which is not working. If you offer support to opensuse community in your spare time it is a great and generous commitment and I respect it, don't worry. Answering to your tech questions, my battery is healthy; I cannot reproduce the issue on different hardware because I have just the Lenovo Z470 with a running opensuse 13.1 installed; I have other hardware, including two laptop and one desktop but I'm using Ubuntu on these. 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. 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! For example I cannot use my Windows Phone to transfer a file into opensuse 13.1, the trasfer works just in one direction: from Linux to the phone. If the power management problem is an hardware problem, why on Windows 7 I don't notice it? If the problem is limited to just some brands or laptop model, why it is not documented into the opensuse Release Notes? 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. Cheers, -- Marco Calistri (amdturion) -- 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 17:09, Tobias Mueller ha scritto:
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
Hello, I never want to be offensive for anybody personally or via email or phone call as well as wont be for free software list users or free software developers. May be I appear as you wrote above but your definition is far away of my real will and intentions. I keep using Linux in general and Opensuse on particular because I like free software and *nix operating systems in general but this doesn't mean that since I like something I will praise it unconditionally, on the contrary: more I like something more I pretend and I would it being error and defect free. I have not time nor the claim to correct this kind of problems on my own, I hopefully wait for someone which could correct by reading mine or even others users complains or bug reports. Some time it happens and problems went corrected, sometime not and problem appears again, release after release, this is the life but not for this I will cry nor I will offend somebody, if it not works in Linux I try with Microsoft Windows or may be I don't make anything and let it go, it depends. 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 Fri, 2014-06-27 at 16:02 -0300, Marco Calistri wrote:
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!
All the above work perfectly for me, day in and day out, with openSUSE 13.1
If the problem is limited to just some brands or laptop model, why it is not documented into the opensuse Release Notes?
How on earth can they test every make and model? And people do not consistently file reports. -- Adam Tauno Williams <mailto:awilliam@whitemice.org> GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA -- 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 <marco.calistri@yahoo.com.br> wrote:
Dear Richard,
I opened a bug some time ago but I am sure nobody have take it to verify:
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
On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote: <snip>
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,
Hi 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).... -- 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:31, 3 users, load average: 0.02, 0.07, 0.15 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
* Malcolm <coyoteuser@gmail.com> [06-30-14 21:56]:
On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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 ??? -- (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 <paka@opensuse.org> wrote:
* Malcolm <coyoteuser@gmail.com> [06-30-14 21:56]:
On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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 <paka@opensuse.org> wrote:
* Malcolm <coyoteuser@gmail.com> [06-30-14 21:56]:
On Mon, 30 Jun 2014 21:59:55 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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
* Marco Calistri <marco.calistri@yahoo.com.br> [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. -- (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
Il 01/07/2014 17:10, Patrick Shanahan ha scritto:
* Marco Calistri <marco.calistri@yahoo.com.br> [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
On Tue, 01 Jul 2014 17:42:57 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Il 01/07/2014 17:10, Patrick Shanahan ha scritto:
* Marco Calistri <marco.calistri@yahoo.com.br> [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? -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 22:43, 3 users, load average: 0.30, 0.29, 0.23 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 01/07/2014 18:05, Malcolm ha scritto:
On Tue, 01 Jul 2014 17:42:57 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Il 01/07/2014 17:10, Patrick Shanahan ha scritto:
* Marco Calistri <marco.calistri@yahoo.com.br> [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
Il 01/07/2014 18:05, Malcolm ha scritto:
On Tue, 01 Jul 2014 17:42:57 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Il 01/07/2014 17:10, Patrick Shanahan ha scritto: SUPER SNIP!
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?
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, -- 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 <marco.calistri@yahoo.com.br> 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 12:46, Malcolm ha scritto:
On Mon, 07 Jul 2014 12:33:18 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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, -- Marco Calistri (amdturion) -- 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 <marco.calistri@yahoo.com.br> 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
On Tue, 08 Jul 2014 12:43:34 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote: <snip>
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,
Hi The output here for my daemon shows both suspend and hibernate, whereas yours doesn't.... Daemon: daemon-version: 0.9.23 can-suspend: yes can-hibernate: yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no I see this bug which is the same issue as you have; https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1296133 Downgrading to the 0.9.xx version seemed to work, what version of pm-utils is present? zypper if pm-utils Information for package pm-utils: --------------------------------- Repository: openSUSE 13.1 OSS UPDATE Name: pm-utils Version: 1.4.1-33.5.1 -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 2 days 2:11, 4 users, load average: 0.14, 0.22, 0.28 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 10/07/2014 01:19, Malcolm ha scritto:
On Tue, 08 Jul 2014 12:43:34 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
<snip>
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,
Hi The output here for my daemon shows both suspend and hibernate, whereas yours doesn't....
Daemon: daemon-version: 0.9.23 can-suspend: yes can-hibernate: yes on-battery: no on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no
I see this bug which is the same issue as you have; https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1296133
Downgrading to the 0.9.xx version seemed to work, what version of pm-utils is present?
zypper if pm-utils
Information for package pm-utils: --------------------------------- Repository: openSUSE 13.1 OSS UPDATE Name: pm-utils Version: 1.4.1-33.5.1
Wow! Malcolm, BEFORE TO PROCEED WITH THE TECH PART: I think you are definitely one of the best members of openSUSE list and a true free-software collaborator because through your suggestions and instructions you really help others and not just keep limiting yourself as someone else does, just to blame somebody because he is relating about something which doesn't works as expected. _Congratulations for your true helper spirit!_ Indications you have reported above are certainly important and I will verify ASAP, if I understood correctly the Daemon we are talking about depends upon pm-utils package, if it is the case I will install the same version as your and test again (crossing fingers). Best 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 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, -- 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 <marco.calistri@yahoo.com.br> 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 <marco.calistri@yahoo.com.br> 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
On Fri, 11 Jul 2014 11:46:50 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Il 11/07/2014 11:21, Malcolm ha scritto:
On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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? -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) openSUSE 13.1 (Bottle) (x86_64) 3.10.1 Kernel 3.11.10-17-desktop up 0:22, 3 users, load average: 0.11, 0.37, 0.29 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:59, Malcolm ha scritto:
On Fri, 11 Jul 2014 11:46:50 -0300 Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Il 11/07/2014 11:21, Malcolm ha scritto:
On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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 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 <marco.calistri@yahoo.com.br> wrote:
Il 11/07/2014 11:21, Malcolm ha scritto:
On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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, -- 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 <marco.calistri@yahoo.com.br> wrote:
Il 11/07/2014 11:21, Malcolm ha scritto:
On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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
Il 11/07/2014 11:21, Malcolm ha scritto:
On Thu, 10 Jul 2014 13:12:59 -0300 Marco Calistri <marco.calistri@yahoo.com.br> 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
Quoting Marco Calistri <marco.calistri@yahoo.com.br>:
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 <marco.calistri@yahoo.com.br>:
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
* Marco Calistri <marco.calistri@yahoo.com.br> [06-30-14 21:00]:
Il 27/06/2014 14:16, Richard Brown ha scritto:
On 27 June 2014 18:08, Marco Calistri <marco.calistri@yahoo.com.br> wrote:
Dear Richard,
I opened a bug some time ago but I am sure nobody have take it to verify:
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
Hi Richard, this reply comes a "bit" late. I was on vacation back then and given the environment could not experiment that much with computers (which, I'll admit, has it's benefits, too ;-). On Fri, 30 May 2014, Richard Brown wrote:
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. : 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.
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.
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 :)
Lovely. That worked like a charm. I have been able to test that back then, and it saved my running system more than once. Thank you so much! 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"? Gerald -- 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 <gp@suse.com> 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
Le mercredi 30 juillet 2014 à 21:10 +0200, Gerald Pfeifer a écrit :
Hi Richard,
this reply comes a "bit" late. I was on vacation back then and given the environment could not experiment that much with computers (which, I'll admit, has it's benefits, too ;-).
On Fri, 30 May 2014, Richard Brown wrote:
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. : 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.
On that particular topic, I've discussed yesterday at GUADEC with upstream for upower and he told me double batteries handling should work properly with upower 0.99 (ie GNOME 3.12 or upcoming SLE12). If not, please fill/reopen the bug report ;) -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- 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 <gp@suse.com> 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
participants (10)
-
Adam Tauno Williams -
Dominique Leuenberger a.k.a. Dimstar -
Frederic Crozat -
Gerald Pfeifer -
Malcolm -
Marco Calistri -
Patrick Shanahan -
Richard Brown -
Scott Reeves -
Tobias Mueller