Mouse with no time remaining estimate showing in preference to battery being charged

Bug #1315434 reported by Marc Deslauriers on 2014-05-02
This bug affects 39 people
Affects Status Importance Assigned to Milestone
indicator-power (Ubuntu)
Matthew Paul Thomas

Bug Description

When my laptop battery is in a charging state, but is not fully charged, I expect it to be displayed in preference to my mouse, which has no time remaining estimate.

The spec here:


"If anything is discharging, the menu title should represent the component (not battery, but component) that is estimated to lose power first. For example, if your notebook battery is estimated to discharge in 1 hour 47 minutes, and your wireless mouse battery is estimated to discharge in 27 minutes, the menu title should represent the mouse. "

but there doesn't seem to be any guideline to what happens when a battery is being charged.

I suggest the time remaining to charge a battery should be displayed in preference to the power level in a wireless mouse.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: indicator-power 12.10.6+14.04.20140411-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: Unity
Date: Fri May 2 11:50:36 2014
InstallationDate: Installed on 2013-11-26 (156 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: indicator-power
UpgradeStatus: Upgraded to trusty on 2014-01-17 (104 days ago)

Related branches

Marc Deslauriers (mdeslaur) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in indicator-power (Ubuntu):
status: New → Confirmed
Jochen Fahrner (jofa) wrote :

The current logic is, that discharging has precedence over charging. But this is useles, sind mice normally have primary cells that cannot be charged. And I'm not interested in their status because they run monthes, even with a low status. The current logic is absolutely nonsens and not practical!

I changed the sorting algorithm in service.c so that laptop battery has always the highest precidence.
If others wish this to be the same, and want to recompile indicator-power, I attach a patch.

Alexey Kulik (doctor-rover) wrote :

I completely support this idea! Hope it will be implemented.

The attachment "Patch to give laptop battery always highest precedence" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Matthew Paul Thomas (mpt) wrote :

Jochen, thanks for the patch. But from your description, it seems like it wouldn't fix the problem, and it would need to be removed when the problem was fixed.

The problem isn't that we're treating laptop batteries the wrong way, it's that we're treating the mouse the wrong way. Specifically, we're treating a device that is discharging over weeks or months as more important than *anything* that's charging, whether it's a laptop battery or not.

With your patch, the mouse would still take precedence over anything charging quickly that wasn't a laptop battery, which would be inappropriate. And the laptop battery would take precedence over the mouse even when the mouse had only five minutes charge left, which would also be inappropriate.

So we need some other criteria for deprioritizing things that are discharging very slowly. I don't think whether something is rechargeable is relevant: if my mouse battery is going to die in 20 minutes, I want to know that regardless of whether the solution is docking it or buying new batteries.

Changed in indicator-power (Ubuntu):
assignee: nobody → Matthew Paul Thomas (mpt)
Jochen Fahrner (jofa) wrote :

Matthew, I don't think you will never find an algorithm that satifies all user needs.

My very personal opinion is, that the mouse battery status is irrelevant. Even if the mouse is going in 20 minutes, I still can use the touchpad of my laptop. I only want to see the status of my laptop battery.

If you want to satisfy all user needs, you should make it configurable.

My patch was only a quick workaround for people like me, that want the old behaviour of battery indicator.

maxwellcom (ndmaxwell) wrote :

@jofa: "If you want to satisfy all user needs, you should make it configurable."

Yes. Why does the power indicator display have to be decreed to users?

The mouse battery (along with any other battery besides the laptop) is irrelevant to me as well. By the current design, the "power indicator" on my laptop does not indicate the status of my laptop battery. While that seems like defective design to me, to someone else stubbornly displaying the laptop battery may seem like the wrong way to use a laptop.

Letting users set a static display option to override the default behavior would do the trick.

In any case, thanks for the patch.

Matthew Paul Thomas (mpt) wrote :

Making it configurable obviously wouldn't "satisfy all user needs", because only a small fraction of users who might benefit from it would even know the option exists. Fewer still would comprehend *why* it exists, and even fewer than that would be bothered changing it. Making things worse, the added UI complexity would dissuade people from using the more-useful options around it. And the code would be less reliable, because engineers and testers would be allocating the same total amount of time to more code paths. And, after all that, we'd still have to decide what the default setting should be!

So, no, we're not going to make this configurable. Instead let's concentrate on actually fixing the bug.

I don't know how I missed seeing before that the mouse in question "has no time remaining estimate". That should automatically exclude it from being considered as the device that will discharge most quickly.

Changed in indicator-power (Ubuntu):
status: Confirmed → In Progress
Alexey Kulik (doctor-rover) wrote :

Matthew, that's great! It looks absolutely reasonable.
Waiting for the fix. Thanks!

maxwellcom (ndmaxwell) wrote :


While I would disagree that "making it configurable obviously wouldn't 'satisfy all user needs'," the objections that follow in your post are nonetheless all reasonable concerns - and I can appreciate the desire to focus on fixing the bug.

One last plead: the preference to always display laptop battery data on a laptop isn't esoteric. What about a gsettings/dconf option to set "always display laptop battery in power indicator?" The "default" behavior could otherwise simply be the current spec. Would that allow a config while avoiding the UI setbacks and minimizing the code base impact? Those sorts of tweaks are routinely disseminated among the Ubuntu user base.

In any case, thank you for working on the power display and all the little details that are part of Unity's refinement.

Marc Deslauriers (mdeslaur) wrote :


So currently the algorithm in indicator-power uses the following sort order:

/* sort devices from most interesting to least interesting on this criteria:
   1. discharging items from least time remaining until most time remaining
   2. discharging items with an unknown time remaining
   3. charging items from most time left to charge to least time left to charge
   4. charging items with an unknown time remaining
   5. batteries, then non-line power, then line-power */

Could you confirm it should be this instead?

/* sort devices from most interesting to least interesting on this criteria:
   1. discharging items from least time remaining until most time remaining
   2. charging items from most time left to charge to least time left to charge
   3. charging items with an unknown time remaining
   4. discharging items with an unknown time remaining
   5. batteries, then non-line power, then line-power */

Jochen Fahrner (jofa) wrote :

ANY sort order does not fit my needs. If I want to see the status of mice and keyboard batteries, I can click on the indicator and see them all. What I need to see ALWAYS at a first glance, is the status of my laptop battery, regardless of discharging, charging or full and on ac.

Changed in indicator-power (Ubuntu):
importance: Undecided → Medium

"What I need to see ALWAYS at a first glance, is the status of my laptop battery, regardless of discharging, charging or full and on ac."

I agree on that 100%

Allan Barnes (allanebarnes) wrote :

I was under the impression my laptop was at 70% when it shut off just a few minutes ago, but what I was actually seeing was my mouse battery. Even now, it has just started charging and still the mouse shows up first. And even if I turn the mouse off it STILL overrides the laptop battery.

Need a way to force laptop charge considering the importance of it.

Alex (alex-ford-b) wrote :

I'm in agreement with Jochen. There will never be a situation where I want to see my mouse indicator. In my case I'm using a Targus mouse running on two AA batteries. Ubuntu seems to think my mouse is at 0% power and needs to be charged. It's not even a chargeable mouse. Even if it was rechargeable I wouldn't want this indicator to ever override my laptop battery status. My laptop is charging and I have to keep unplugging it to see the battery status because clicking the indicator only gives me a time to charged number when I'd rather see a percentage.

While my power cord is plugged in and the laptop is charging all I see is a red mouse icon in the place of my battery indicator. I was only mildly annoyed at first because I assumed there had to be an option somewhere to just disable showing my mouse battery. I was wrong, so now I'm slightly more annoyed.

Yura (ykuchinskiy) wrote :

+1 to support Matthew's comment.

I'm using my laptop a lot and to avoid pain in my wrist, I'm using BT vertical mouse and the mouse battery status is important for me...

Also, Ubuntu (more specifically user interface) is getting better and better, that now my wife, son (12 years old) and my MOTHER IN LAW are using it without big problems on their laptops. And I think that for them Matthew's idea will be more understandable and welcome.

At the same time to support use case for heavily tech users, I would recommend adding a config file to override the default behaviour to allow setup of specific behaviours.

In this case, from my personal opinion, Ubuntu/Linux can create the unique opportunities to serve needs of average/normal and heavily tech users.

Matthew, thank you once again for your willing and efforts to make Ubuntu/Linux more user friendly, and hope you will not forget about tech users with their needs.

peddanet (peddanet) wrote :

I agree with Jochen and his followers, the whole idea and the dealing with it seems a little bit too sophisticated. Let's make it simple, for me, after the discussion, the philosophy is clear, and I clearly disagree, but to most users that obviously did not read this bug report or the wiki, the behaviour is just STRANGE and unsatisfying...But if you would want to change it like for example the boot order, you should be able to do so. The default case SHOULD BE THE BATTERY of the laptop, so the main interesting thing that should always be in focus.

Suggestion for the future:
Better you could add colours to the icon to show if it is loosing of its capacitance over the time :-)...., like red for only half of the capacitance, or a coloir, when you should really discharge/charge to extend batteries life of the laptop. That ALL wouldn't be as annoying for the normal user like the solution you find for it now... and I am sure of it.

Please rethink this behaviour, it doesn't make the world a better place...

Dan L. (dlevings) wrote :

I also agree with these comments and this problem affects me. I constantly use a wireless mouse on my laptop, so essentially I can never see my laptop battery charge without either unplugging my mouse or having to click on the mouse icon on the top. This makes no sense- especially because my mouse charge lasts practically *forever* (going on like 1 year with the same batteries), so why would I care what the charge is 99.999999% of the time. Laptop charge should be shown all the time as default, and if you want to add options for looking at other charges fine, but laptop charge should take precedence since that's what 99% of users would prefer by my guess.

Lee Dixon (jleedixon) wrote :

I also much prefer to ALWAYS see my laptop battery state (charging, charged, or otherwise). The fact that my logitech mouse AA batteries are always at 55% is completely useless. My laptop power state is ALWAYS the most important thing.

Think of it this way: if the mouse battery dies, you replace or charge it, but the computer keeps working. If the laptop battery dies, you RISK DATA LOSS. Thus, the laptop battery status is ALWAYS more important.

Alexey Kulik (doctor-rover) wrote :

Lee Dixon,
By the way, there is a special bug report about the 55% charge level:
Bug #1296872 - Charge level and the remaining time are estimated incorrectly for the battery in Logitech Wireless Mouse with Unifying receiver

I agree with having the option to always see the laptop battery status in the notifications area, and having all other present batteries shown in the dropdown menu. Even when the laptop battery is fully charged, somebody (like me) could have a flaky AC connection and not see the battery status change because the mouse battery is being shown instead of the laptop battery.

Marc Deslauriers (mdeslaur) wrote :

Here is a patch that implements the preferred sorting order as described by mpt, and described in comment #12.

What file should this patch apply to? It was not specified in the file.

desrt (desrt) wrote :

Just to play devil's advocate a bit here:

The logic taken in this bug (that we should show the device that will run out of power first) seems perfectly sound, but it makes a very large assumption, which I suspect will often be untrue: that reporting of time remaining on mice will always be completely accurate.

I think there are two problems with the assumption.

The first is that there have been reports (one just now on IRC from jcastro) about faulty hardware/driver combos that report things like "1 minute remaining" all the time. Users with this hardware would probably like that fixed, but for lack of a fix, would probably prefer to be able to go on with their lives with the minimum amount of disruption.

Second issue is that I wonder if "estimated time left" reporting on a device which has a battery that lasts up to a year is _ever_ accurate to the hours or minutes that we would need it to be in order to meaningfully compare it against laptop battery life.

Those two point combined cause me to believe that the only case in which this feature would be engaged would be in the "wrong" case. Maybe it makes sense to just remove it entirely after all?

Marc Deslauriers (mdeslaur) wrote :

Devices that report a wrong time remaining need to be blacklisted, just like any other misbehaving hardware device. The fact that such devices exist is not a valid reason to get rid of a sane and elegant notification system.

Do you own a mouse with an incorrect "time remaining" estimate?

Ernesto Alejo (ernestoalejo) wrote :

My mouse is always 90% or 5% (no intermediate values) and it changes ~4-5 times a week; mostly when the laptop suspends. The mouse uses batteries and it's always the one showed in the notifications area. In fact I think the mouse does not even report the remaining time (it's not present in the dialog)

Jochen Fahrner (jofa) wrote :

It's very funny to see how Canonical justifies this stupid new "feature". In the meantime I switched to Debian Wheezy (one of the reasons was this "feature") and now I'm on FreeBSD (because of systemd taking over control of the whole linux world).

Good luck to all that stay on Ubuntu. ;-)

JW (jw-00000) wrote :

> Devices that report a wrong time remaining need to be blacklisted, just like any other misbehaving hardware device.

Even if this means most devices will need to be blacklisted? Wouldn't it require an extreme amount of effort to start blacklisting every mouse that doesn't work with this feature?

Marc Deslauriers (mdeslaur) wrote :

> Devices that report a wrong time remaining need to be blacklisted, just like any other misbehaving hardware device.

>Even if this means most devices will need to be blacklisted? Wouldn't it require an extreme amount of effort to start blacklisting every mouse that doesn't work with this feature?

I have never actually seen a mouse that gives an estimated time remaining, so I don't think it would be much of an issue. Most mice I've seen don't give a time remaining, they only give a percentage of battery left, which works fine with the latest commit.

Do you own a mouse that gives a time remaining, and that the time remaining is grossly inaccurate? If so, could you please attach the output of "upower --dump"?

JW (jw-00000) wrote :

Ah OK. My mouse only gives a percentage (0, 5, or 90%), although sometimes incorrect (it goes to 5 to go back to 90). I hope the last commit will fix behaviour on my machine.

Marc Deslauriers (mdeslaur) wrote :


It will, yes. If your laptop battery is charging, or is discharging, it will now be shown in preference to your mouse.
If your laptop battery is fully charged, your mouse will be shown.

asmoore82 (asmoore82) wrote :

I could not easily find this workaround from a google search so documenting it here:

Typical "use with caution" notice, may cause a (small) rift in the space-time continuum, etc.

Edit /lib/udev/rules.d/95-upower-csr.rules (with sudo), comment out (with #) the last set of lines at the bottom so that it's left like this:

# Unifying HID++ devices
#SUBSYSTEM!="hid", GOTO="up_unifying_end"
#ATTRS{idVendor}=="046d", ENV{UPOWER_VENDOR}="Logitech, Inc."
#ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", DRIVER=="logitech-djdevice", ENV{UPOWER_BATTERY_TYPE}="unifying"
#ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c532", DRIVER=="logitech-djdevice", ENV{UPOWER_BATTERY_TYPE}="unifying"
#ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52f", ENV{UPOWER_BATTERY_TYPE}="lg-wireless"

^Everything commented out but that last LABEL.

On the next reboot, UPower will completely ignore these Unifying devices!

Don McCants (2on) wrote :

I used nano to successfully edit the 95-upower-csr.rules in elementary OS Freya, as indicated by asmoore82.

I want to chime in and reiterate that mouse power management should take priority over OS power management. Battery usage tracking and management for laptops/netbooks should the primary, and dare I say only focus of the battery indicator.

I believe that this is the feeling of the majority. I don't mean to dismiss the feelings or opinions of those who like to manage their mouse battery power. However, if the indicator can not be easily fixed to prioritize laptop battery over mouse battery, then I think mouse support should be removed until it can be fixed.

Modern mouse power management is such that mice last for thousands of hours (many months) of constant use on a single set of batteries--in fact it is a selling point on the packaging of most mice. I also believe the lengths I had to go to to find this info is very anti-consumer, and it discourages wider adoption of Linux as an accessible, usable, OS.

Marc Deslauriers (mdeslaur) wrote :

FYI, I have a merge request pending review that makes the laptop battery have priority over the mouse battery here:

This will only display the mouse battery if it's below 10% so that the user will still get a notification that a battery change is required.

maxwellcom (ndmaxwell) wrote :

@Don McCants (2on)

In #34 above, you wrote:

    "I want to chime in and reiterate that mouse power management should take priority over OS power management."

Based on the rest of your post, I think you intended to write:

    "I want to chime in and reiterate that OS power management should take priority over mouse power management."

Is that correct?

Don McCants (2on) wrote :

Sorry, I just saw this. It should read:

"mouse power management should NOT take priority over OS power management"

And I'm leaving the word NOT in all caps. I find this to be one of the most frustrating laptop bugs ever, other than broken keys and poor touchpads. I could care less about mouse power--unless your mouse lights up like a xmas tree, that battery will last 2 years.

My laptop battery, on the other hand, runs out several times a day with heavy use.

Don McCants (2on) wrote :


The OS update this week overwrote the workaround, and the mouse was re-prioritized over laptop power.

Of course, my laptop ran out of power because the battery indicator said I had plenty of charge, because it was sensing my battery, not my laptop.

Please resolve this bug.

Don McCants (2on) wrote :

quote with correction:
it was sensing my "mouse" battery, not my "laptop's battery."

Don McCants (2on) wrote :

After the latest updates for elementary OS, my battery only shows 100%.

I have edited the file with Nano, but there has been no change in the functionality, even after commenting out the Logitech power monitor feature.


Don McCants (2on) wrote :

Found specifics around the new issue and a temporary fix.

The last patch/update from Elementary changed the referred file name to :

Where it had previously been:

Traditional .rules files are named with an "s" on the end. So any edits made as indicated in this thread did not work. Making changes to the .rule file followed by a restart fixed the issue.

Don McCants (2on) wrote :

2nd issue with this bug: battery indicator not updating status.

While editing the .rule file resolves the prioritization of mouse power over laptop power issue, the battery status indicator does not update in a frequent fashion.

Don McCants (2on) wrote :

The .rule file is the result of a problem between keyboard and chair. I'm going to stop wasting everyone's time here (and stop posting), and do a thorough examination of potential fixes and work-arounds before I post on this thread again. I'll document everything I try (CRON jobs, other battery indicators, potential GNOME conflicts with elementary OS, etc.) as well as notes on where I found solutions, and I'll post the results here only after I have resolved all potential avenues of resolution, after a couple of days of testing and retesting.

Moderators, please feel free to delete posts #
and this post, #43.

Vanessa (vanessakindell) wrote :

Just a heads up regarding this issue, running acpi -V returns the correct battery percentage even if the indicator shows the wrong one.

Nilesh (nilesh-comp-engg) wrote :

that bug bite me .........

Don McCants (2on) wrote :

Running acpi -V is a workaround (thank you), but not a solution :-(

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers