After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709110 - status area doesn't distinguish between laptop and mouse batteries
status area doesn't distinguish between laptop and mouse batteries
Status: RESOLVED DUPLICATE of bug 709572
Product: gnome-settings-daemon
Classification: Core
Component: power
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2013-09-30 15:26 UTC by Dan Winship
Modified: 2013-10-14 06:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Winship 2013-09-30 15:26:02 UTC
My laptop is plugged in, at full power, but my wireless mouse is about to die (well, actually it's not, but upower thinks it is). The shell status area shows an "about to die" battery icon, but then if I open the menu, the Battery section shows the same icon, but labeled "Fully Charged", and there's no indication (even in the submenu) that it's talking about two different batteries.

(I'm not sure it should show the "about to die" icon anyway... 99% of the time, the status area battery icon refers to my laptop battery, so it's confusing to have it suddenly switch to being about my mouse battery. Maybe it should show two battery icons in this case. Or not indicate the mouse battery state in the status area at all, and only do the notifications.)
Comment 1 Jasper St. Pierre (not reading bugmail) 2013-09-30 15:50:24 UTC
This is a bug in the composite battery / icon mismatch. I think we should just remove the composite battery and have the icon represent the primary battery.
Comment 2 Bastien Nocera 2013-10-01 16:50:45 UTC
(In reply to comment #0)
> My laptop is plugged in, at full power, but my wireless mouse is about to die
> (well, actually it's not, but upower thinks it is).

That's fixed in upower git IIRC.

>The shell status area shows
> an "about to die" battery icon, but then if I open the menu, the Battery
> section shows the same icon, but labeled "Fully Charged", and there's no
> indication (even in the submenu) that it's talking about two different
> batteries.
> 
> (I'm not sure it should show the "about to die" icon anyway... 99% of the time,
> the status area battery icon refers to my laptop battery, so it's confusing to
> have it suddenly switch to being about my mouse battery. Maybe it should show
> two battery icons in this case. Or not indicate the mouse battery state in the
> status area at all, and only do the notifications.)

What's the output of:
gdbus introspect --session --dest org.gnome.SettingsDaemon.Power --object-path /org/gnome/SettingsDaemon/Power
?
Comment 3 Dan Winship 2013-10-01 17:00:33 UTC
(In reply to comment #2)
> That's fixed in upower git IIRC.

yup, found that bug already

> What's the output of:
> gdbus introspect --session --dest org.gnome.SettingsDaemon.Power --object-path
> /org/gnome/SettingsDaemon/Power
> ?

trimming the dull introspection bits:

node /org/gnome/SettingsDaemon/Power {
  interface org.gnome.SettingsDaemon.Power {
    methods:
      GetPrimaryDevice(out (susdut) device);
      GetDevices(out a(susdut) devices);
    signals:
    properties:
      readonly s Icon = '. GThemedIcon battery-caution-symbolic gpm-mouse-000 battery-caution ';
      readonly s Tooltip = 'Mouse (1%)\nLaptop battery is charged';
      readonly d Percentage = 99.616858237547888;
  };
  interface org.gnome.SettingsDaemon.Power.Screen {
    methods:
      StepUp(out i new_percentage);
      StepDown(out i new_percentage);
    signals:
    properties:
      readwrite i Brightness = 100;
  };
  interface org.gnome.SettingsDaemon.Power.Keyboard {
    methods:
      StepUp(out i new_percentage);
      StepDown(out i new_percentage);
      Toggle(out i new_percentage);
    signals:
    properties:
      readwrite i Brightness = -1;
  };
};
Comment 4 Bastien Nocera 2013-10-14 06:53:58 UTC
Ended up fixing it in bug 709572. Thanks for the debug output.

*** This bug has been marked as a duplicate of bug 709572 ***