GNOME Bugzilla – Bug 659908
Power/battery icon: does not get updated after suspend
Last modified: 2011-10-14 09:34:05 UTC
My power icon shows an empty battery after I suspended, while my battery is now full (the laptop was plugged while it was suspended). upower has the right information, and g-s-d also (I manually looked with the dbus interface). So it's an issue on the gnome-shell end. I was thinking we simply don't get the Changed signal after resuming from suspend, but it's possibly a larger issue as unplugging doesn't help at all -- it sounds as if we're completely disconnected from dbus. Quickly looking at ~/.xsession-errors, I see nothing related to this (the shell issues I see there are related to the on-screen keyboard).
Actually, calling GetPrimaryDevice() fails: 'org.gnome.SettingsDaemon.Power.Failed: There is no primary device.' I guess it's not supposed to fail?
GetPrimaryDevice() works fine when the battery is discharging: (u'/org/freedesktop/UPower/devices/battery_BAT0', 2L, u'. GThemedIcon battery-full-symbolic gpm-battery-080 battery-full ', 84.74241608328846, 2L, 9792L) So yeah, looks like an issue on the gnome-shell side.
Is it conceivable that GetPrimaryDevice fails temporarily, and the shell doesn't recover/retry ?
Is this reproducible for you ? I've suspended a lot, lately, and never noticed the battery icon giving up its ghost.
It's 100% reproducable for me (or at least, it feels like 100% since I'm hit by this nearly every time I suspend).
Ok, I'm not even sure it's related to suspend since I had this issue after a fresh boot this morning. I'll see if I can do proper debugging...
I am seeing this too now (not updating battery icon in the shell).
actually, not entirely clear what I am seeing here. Somewhat byzantinic behaviour from the gsd power plugin. After adding a log('error getting primary device ' + error); in the error path of power.js:_readPrimaryDevice, I see this after going on ac: JS LOG: error getting primary device Error: DBus error: org.gnome.SettingsDaemon.Power.Failed: There is no primary device. and after that, the percentage in the menu doesn't seem to get updated anymore and I don't see the _devicesChanged handler getting called anymore.
On the gsd side, plugging in a cable yields a bunch of: (gnome-settings-daemon:6491): power-plugin-DEBUG: using original device as only one primary battery
The reason for the 'no primary device' error is that engine_get_primary_device skips charging batteries, for reasons that are entirely unclear to me.
(In reply to comment #10) > The reason for the 'no primary device' error is that engine_get_primary_device > skips charging batteries, for reasons that are entirely unclear to me. The primary device has always returned with an error if there is no device discharging. The original logic was that the primary device was the way that the computer was getting power, so that if on backup power, the UPS would be the primary device, and if on battery, then that would be the primary device. Of course, if we're on AC, there is no primary device. This has been working for me since the battery applet was added to the shell. Has something changed in the shell code recently? Of course, if we want the GetPrimaryDevice to "return the device used in the tray" then we'd need logic changes to engine_get_primary_device() as that's not what I was asked for, and I hope that's not what it's doing. Richard.
One thing I notice is that the power plugin has "<method name='GetPrimaryDevice'>" "<arg name='device' type='(susdut)' direction='out' />" "</method>" "<method name='GetDevices'>" "<arg name='devices' type='a(susdut)' direction='out' />" "</method>" while the shell has { name: 'GetDevices', inSignature: '', outSignature: 'a(susdut)' }, { name: 'GetPrimaryDevice', inSignature: '', outSignature: '(susdut)' }, susbut != susdut but changing that in the shell didn't change things...
I filed that one as bug 660122.
Another thing I noticed is that gsd sometimes emits Changed while handling a GetDevices or GetPrimaryDevice call, so we can run into some unexpected reentrancy. But preventing that didn't seem to fix my issue either...
Vincent, do you have toolkit-accessibility turned on ? Turning that off seems to make things go back to normal for me.
(In reply to comment #15) > Vincent, do you have toolkit-accessibility turned on ? > > Turning that off seems to make things go back to normal for me. I thought it was turned on, but I checked earlier today (while playing with caribou), and it was turned off. I turned it on again since then, though.
@Vincent: What is the output of upower -d?
(In reply to comment #17) > @Vincent: > > What is the output of upower -d? upower gives the expected results. It works fine. gnome-settings-daemon also works fine (since I get a notification of low battery). With dbus-monitor, I was able to see that the power plugin in g-s-d does emit the Changed signal. But gnome-shell doesn't see it. It's really an issue in gnome-shell (or gjs) as far as I can tell.
Created attachment 198979 [details] Minimal js test I'm extremely confused: I've taken the power indicator code and minimized to this. And I still don't receive any Changed signal from g-s-d with that code (while I see the signals in dbus-monitor). To make sure the code was working fine, I changed it to listen to upower on the system bus instead, and in that case, it works fine. So I'm lost.
Created attachment 198994 [details] [review] g-s-d patch: Emit Changed to all listeners I found the root cause: g-s-d power emits the signal only to itself. From dbus-monitor: signal sender=:1.4 -> dest=org.gnome.SettingsDaemon serial=233 path=/org/gnome/SettingsDaemon/Power; interface=org.gnome.SettingsDaemon.Power; member=Changed The destination is g-s-d, so no one can receive the signal except itself :-)
Doh! Confirming the patch fixes the issue.
(In reply to comment #21) > Doh! Confirming the patch fixes the issue. Great, thanks. I've pushed the patch to gnome-3-2 and master. Thanks to all.