Bluetooth Mouse looses connection after some time of inactivity

[dukat]

(Note: This is a direct copy of my bug KDE bug report at https://bugs.kde.org/show_bug.cgi?id=153877)

I have two Logitech Bluetooth Mice: One MX900 and one MX1000 on an HP Laptop with integrated Broadcom Bluetooth connectivity. I can pair both easily using the tray applet, and they both work flawlessly initially.
However, after some time of inactivity (Not using one mouse for some time, Going away from the System, etc) the connection is lost and won't be re-established, even after moving the mouse constantly.

I go to Configuration -> Input Devices and both Mice are listed. The mouse that hasn't been used for some time (don't know the exact amount), doesn't show the yellow star in front of its name any more (The other one in use still has the yellow star). Selecting the inactive mouse and pressing "Connect" doesn't help. I can only re-connect if I press the "Discoverable" Button on the mouse and then press "Connect" in the dialog.

The effect is the same with both mice. The disconnection happens always after mouse some inactivity time. This bug makes Bluettooth mice operation under KDE currently not usable at all.

-------
Bug Impact: Currently all users of bluetooth input devices will be unable to use their input device after leaving it idle for an extended period of time. The only workaround is to unplug and plug back in the device again.

Addressing: Upstream has a patch in CVS head that works around the issue.

Test Case:
1) Install Ubuntu on a system with a supported bluetooth controller.
2) Pair a BT mouse or keyboard with the computer. Verify that it works
3) Disable any suspend when idle options on the computer
4) Leave the computer idle for 30+ minutes.
5) Verify that the mouse and/or keyboard have stopped working.

[mjbarker5 (barker-m)]

This same thing happens to my mouse (Microsoft Bluetooth Notebook Mouse 5000) in Ubuntu Gusty 7.10 - Gnome 2.20.1

I have a IBM ThinkPad X41 Tablet with integrated bluetooth. I am pretty much running the stock version of Ubuntu (no changes since install, except for updates)

After a period of ~15-20 minutes of inactivity the mouse will loose connectivity and will not reconnect when I move it around or press buttons. It will never loose connectivity if I am using the mouse.

I did get the mouse to re-connect just once when I violently pressed every button in a moment of rage, but that has not worked twice.

the only thing that seems to reconnect the mouse is pressing the connection button on the mouse and typing
sudo hidd --search
in a terminal.

-Matt

[Bzt (joost-wish)]

I seem the have a similar problem. I am using a desktop computer with ubuntu gusty 7.10 gnome. And have bluetooth LT MX1000 leyboard and MX5000 mouse..

After about 15 min. my bluetooth mouse and keyboard lose connection and i am unable to reconnect other than sudo hidd --search.

Any thoughts?

[mjbarker5 (barker-m)]

if you right click on your gnome bluetooth manager. go to preferences, then under the first tab there is a section labeled "mode of operation"
Click on the button that says "visible and connectible for other devices."
Also the slider that says "make adapter invisible after" should be at "NEVER"

[dukat (dukat)]

The bug is still in the current hardy Kubuntu beta

[Simone Malacarne (s-malacarne)]

This bug is also in Ubuntu (Gutsy and Hardy).
After some minutes of inactivity mouse and keyboard stop responding.
In bluetooth manager they result always connected even when not working. I have to manual disconnect them to restart them.

[pug (pug-nerd)]

Apparently this bug consists after 8.04 release....

My bluetooth keyboard was working fine until I upgraded to the release (from the beta a few weeks ago), since then my bluetooth keyboard has not been working as it should.

I can pair the keyboard using the bluetooth manager, however nothing ever shows up in the trusted / paired list... meaning that when the bluetooth keyboard sleeps it won't autoconnect when it wakes up since its an untrusted device... GAH!

Seriously, how did they mess up the release and not the beta... weird.

Anyway, what is the command for manually disconnecting them? If there is such a command... I'm a bit tired of having to vnc into ubuntu using my laptop just to get my bluetooth working again.... just to have it disconnect and never work again the first time the keyboard goes to sleep to save battery... *sighs*

[Charlotte Curtis (c-f-curtis)]

I've got this bug too with an MX1000 mouse and MX5000 keyboard. The weird thing is that the bluetooth manager shows the keyboard and mouse as connected (when they are asleep), but if I manually disconnect and then wiggle the mouse or press some keys, they reconnect just fine. It seems as though the problem is that bluez doesn't recognize that the devices are disconnected when they go to sleep, as it is perfectly capable of automatically detecting and reconnecting them once I tell it that they are disconnected.

[Robert Lange (rcl24)]

I believe that Bug #220249 is another symptom of this same underlying bug, so it should probably be marked as a duplicate of this bug.

I have the same problem under Gnome on Hardy. I use a Logitech diNovo Media Desktop Laser keyboard and mouse combo. When one of the devices has been inactive for some time (20+ minutes, don't know how long for sure), that device will be disconnected as an X input device, but will still show up as connected according to bluez-utils and bluez-gnome programs (e.g., hcitool, bluetooth-properties, etc). Once I manually disconnect it via bluetooth-properties, then using the device again (i.e., pressing a key, if the BT keyboard fell asleep, or wiggling the BT mouse if the BT mouse fell asleep) will immediately cause the device to reconnect and be re-established as an X input device.

When both the BT keyboard and BT mouse are connected and active, `ls -l /dev/input/by-path` shows th the following symlinks to device files:

pci-0000:00:07.4-usb-0:aclXXYYXXYYXXYY- -> ../mouseX
pci-0000:00:07.4-usb-0:aclXXYYXXYYXXYY-event- -> ../eventY
pci-0000:00:07.4-usb-0:aclAABBAABBAABB-event- -> ../eventZ

where XXYYXXYYXXYY is the address of my BT mouse, AABBAABBAABB is the address of my BT keyboard, and ../mouseX, ../eventY, and ../eventZ are the device files for the mouse, the mouse events, and the keyboard events respectively.

If I let the BT keyboard fall asleep, then the keyboard event device file and the symlink are removed, but bluez-utils and bluez-gnome programs still shows the keyboard as being connected. Likewise, if I allow the BT mouse to fall asleep, its device files and symlinks are removed, but it is still listed as connected according to bluez-utils and bluez-gnome programs.

I hypothesize that some low-level bluez function detects that the device is asleep, and sends a dbus message to remove the device file, but that a higher-level function fails to get the signal, and therefore does not think that the device is disconnected; thus when the high-level function sees a request to re-connect, it drops it because it thinks the device is still connected. Alternatively, perhaps X somehow detects that no input has come in via a device, and removes the device file.

I am looking into the first possibility right now, but there are so many layers of frameworks and messages in the code that I am having a hard time figuring out what does what. Input from the bluez developers as to what dbus messages are sent and received in what modules would be greatly appreciated.

[Mario Limonciello (superm1)]

FYI:

http://article.gmane.org/gmane.linux.bluez.devel/15744

There may be a patch very recently committed to CVS that will resolve the issue. I've yet to find some time to verify however.

[Robert Lange (rcl24)]

I have backported the (temporary?) fix from bluez CVS to Ubuntu's bluez-utils 3.26-0ubuntu6 package that makes the IO timeout for input devices configurable via a conf file, including the default option of having no IO timeout. Attached is the diff of the package source.

I have tested it (using Gnome) and having no IO timeout for input devices appears to have solved the problem for me. However, I do not know what long-term effects, if any, this will have on things like mouse battery life, etc. Removal of IO timeouts for input devices may have other effects that I have not forseen. (I don't really understand why there was an IO timeout for input devices to begin with...) Also, I use a desktop computer, so I don't know what effects, if any, it has for laptop and other battery-powered computers.

Assuming you know how to build Debian/Ubuntu packages from source, you should only have to get the build-dep and source for the bluez-utils package and use the following commands:

patch -p0 <bluez-utils-3.26__input__.diff

The patch should apply with no errors or warnings. Then you need to:

cd bluez-utils-3.26
aclocal
automake

All should then be ready to build the package.

To experiment with the IO timeout, copy input/input.conf to /etc/bluetooth/input.conf and change the IdleTimeout parameter to however many minutes you want. No conf file, or a commented-out setting, means no IO timeout for input devices.

Based on the link in comment 9, it seems that bluez developers might work to find a better long-term solution that correctly disconnects all input devices when they timeout. However, this patch is here right now, and it seems to fix this problem without breaking anything else.

[Sir Nikon (omnineko)]

Sounds like the elimination of the timeout would definitely solve this issue.

However, what about those of us who really have no clue how to build modules or download source packages?

[Robert Lange (rcl24)]

I have been testing with my patched copy of blues-utils for a week now, and have noticed no ill effects. The mouse and keyboard reconnect within a second or two of pressing a key or moving the device, regardless of how long they have been idle.

Unless someone has a solid reason why this is no good, I recommend integrating this patch and testing it with a wider array of hardware, in preparation for release as an update. It should serve at least until the bluez upstream developers figure out a long-term solution.

[Mario Limonciello (superm1)]

I've verified that this fix works for me too. Makes bluetooth a much much nicer experience. Hopefully we can backport this to hardy for more folks to benefit :)

[Paulo Tanimoto (tanimoto)]

Hi,

I wanted to try this workaround here, but I'm having trouble compiling. Could you point to what I'm missing? (We can go to the forums if necessary.)

$ apt-cache show bluez-utils | grep Version
Version: 3.26-0ubuntu6

$ apt-get source bluez-utils
$ sudo apt-get build-dep bluez-utils
$ curl -O http://launchpadlibrarian.net/14659037/bluez-utils-3.26__input__.diff

$ patch -p0 < bluez-utils-3.26__input__.diff
patching file bluez-utils-3.26/input/Makefile.am
patching file bluez-utils-3.26/input/device.c
patching file bluez-utils-3.26/input/main.c
patching file bluez-utils-3.26/input/manager.c
patching file bluez-utils-3.26/input/manager.h

$ cd bluez-utils-3.26
$ aclocal
$ automake
$ fakeroot debian/rules binary
[...]
Making all in sbc
make[3]: Entering directory `/mnt/current/home/tanimoto/tmp/src5/bluez-utils-3.26/sbc'
make[3]: *** No rule to make target `sbc.lo', needed by `libsbc.la'. Stop.
make[3]: Leaving directory `/mnt/current/home/tanimoto/tmp/src5/bluez-utils-3.26/sbc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/mnt/current/home/tanimoto/tmp/src5/bluez-utils-3.26'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/mnt/current/home/tanimoto/tmp/src5/bluez-utils-3.26'
make: *** [debian/stamp-makefile-build] Error 2

Thanks

[Mario Limonciello (superm1)]

Attaching a patch against intrepid.

[Mario Limonciello (superm1)]

Attaching a patch against hardy-proposed.

[Marcel Holtmann (holtmann)]

The timeout change is only fixing a symptom. If you wanna disable the timeout you can have a one-line patch that does so. The real fix for this is a kernel patch to the hidp.ko driver that I posted to the bluez-devel mailing list.

[Dennis Heinson (dheinson)]

@Marcel: Could you maybe port that to Ubuntu Hardy/Intrepid for us?

[Mario Limonciello (superm1)]

This is the patch that Marcel is referencing:
http://article.gmane.org/gmane.linux.bluez.devel/15745

Disregard the previous two debdiffs then, and instead this one against the
kernel tree (still for an SRU).

On Mon, Jun 2, 2008 at 11:08 AM, Marcel Holtmann <email address hidden>
wrote:

> The timeout change is only fixing a symptom. If you wanna disable the
> timeout you can have a one-line patch that does so. The real fix for
> this is a kernel patch to the hidp.ko driver that I posted to the bluez-
> devel mailing list.
>
> --
> Bluetooth Mouse looses connection after some time of inactivity
> https://bugs.launchpad.net/bugs/175743
> You received this bug notification because you are a member of The Dell
> Team, which is a direct subscriber.
>

--
Mario Limonciello
<email address hidden>

[Tim Gardner (timg-tpi)]

SRU Justification:

Impact: Bluetooth devices lose connectivity after some idle time.

Patch Description: Force user space to reconnect.

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=3923c54f44b4e8d31118b8a8b096cc85013d859f

TEST CASE: See bug description

Email from Mario: "Tim, I just verified that this works with two BT mice and a Dell 370 BT controller. I let them go idle and waited 31 minutes before touching them again. They took a second to reassociate, and then worked properly."

[Tim Gardner (timg-tpi)]

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=3923c54f44b4e8d31118b8a8b096cc85013d859f

[Martin Pitt (pitti)]

ACK for SRU. Is this actually a problem in bluez-utils as well, or should that task be closed?

[Mario Limonciello (superm1)]

Closing the bluez-utils task. Although a workaround can be applied there, the proper fix is in the kernel package.

[Paulo Tanimoto (tanimoto)]

Thank you for the fix. I compiled the git kernel yesterday and will be able to test it tonight. I'll keep you posted.

[Paulo Tanimoto (tanimoto)]

It worked for me, what a relief. Thanks again.

Paulo

[Martin Pitt (pitti)]

Accepted into -proposed, please test and give feedback here

[Mario Limonciello (superm1)]

I've pulled the -proposed kernel and let a paired mouse sit idle for about 25 minutes. It is able to wake back up after low power mode, so the patch is working properly.

[jr00ck (jr00ck)]

It appears this bug is going to be fixed soon in a kernel update, but I don't know if that is the temporary fix or a long-term fix. I just thought I'd give my two bits in case it helps anyone working on this problem. I have a Logitech MX5000 keyboard and a Microsoft Bluetooth Notebook Mouse 5000 connecting to an internal bluetooth module of a Dell Vostro 1500 laptop. For me, after a period of inactivity, only the Logitech MX5000 keyboard cannot regain connectivity to the laptop. The mouse always works fine after any period of inactivity. So I have to open the bluetooth tray applet with the mouse and manually disconnect the keyboard (it shows as connected) and then press a few keys and it will reconnect up. This did NOT happen in 7.10 Gutsy and I still have Gutsy on a separate partition and when I boot to it, I never have disconnect problems. Only in Hardy and only my Logitech MX5000 keyboard.

What the difference between my keyboard and mouse is as far as sleep modes and connectivity, I don't know, but if there are any commands I can run and post the output here that might help somebody investigating the bug, let me know. I'd also like to note that my keyboard never disconnects if I am using the mouse for extended periods of time. In other words, it doesn't appear that it's the keyboard going to sleep and not able to reconnect, because if I am only using the mouse for hours and don't touch the keyboard, the keyboard never disconnects. The keyboard only disconnects if laptop screen powers off after a period of inactivity.

[fimbulvetr (fimbulvetr)]

I have been experiencing this annoying and extremely frustrating bug for some time. After updating to the proposed kernel yesterday, I can say with extreme happiness that it does indeed fix it. Even after being a away all night and having the connection drop, a simple move of the mouse and less than a second wait reestablished the connection.

[Martin Pitt (pitti)]

Copied to hardy-updates.

[dukat (dukat)]

I also can confirm that since the 8.04.1 update everything works as it should! :-)

[Leann Ogasawara (leannogasawara)]

This should be "Fix Released" for Intrepid as well.

[Susanna777 (kshsj777)]

It isn't fixed for me. I'm running Intrepid and I have a Dell Bluetooth Keyboard and Mouse. After a being away from the computer for a while, neither one of them will reconnect. If I try to set them up again, they fail to connect. I have to remove them from the paired devices list and then reconnect them.

[Susanna777 (kshsj777)]

I forgot to mention I'm running Ubuntu, not Kubuntu. I don't know if that makes a difference.

[fimbulvetr (fimbulvetr)]

I was one of the original experiencers of this bug, and can confirm it is still fixed. Perhaps it is something else causing the problem?

[Susanna777 (kshsj777)]

I wouldn't know what it would be. I just know that the mouse and keyboard refuses to reconnect until I delete them from the list and re-set them up. Maybe it could be the settings but I don't see anyplace to change anything.

[ECantona (ozaktash)]

I can confirm that there is a disconnection problem in Intrepid Ibex with linux 2.6.27-7-generic. I am using Speed-Link Notebook Laser Bluetooth Mouse. After a long period of inactivity, I have to switch the bluetooth off and on to get the connection reestablished. Although it generally works that way, sometimes I have to pair it again in order to restore functionality. The problem can also be a defect of my mouse or my bluetooth hardware since I experienced the same in windows too.

[Matt LaPaglia (mlapaglia)]

I have the same issue as Ecantona.

ECantona wrote:
> I can confirm that there is a disconnection problem in Intrepid Ibex
> with linux 2.6.27-7-generic. I am using Speed-Link Notebook Laser
> Bluetooth Mouse. After a long period of inactivity, I have to switch the
> bluetooth off and on to get the connection reestablished. Although it
> generally works that way, sometimes I have to pair it again in order to
> restore functionality. The problem can also be a defect of my mouse or
> my bluetooth hardware since I experienced the same in windows too.
>
>

[ECantona (ozaktash)]

The disconnection problem no longer occurs after uninstalling libbluetooth2 package.

[Loïc Minier (lool)]

ECantona, did the removal of libbluetooth2 cause the removal of other packages?

[ECantona (ozaktash)]

> ECantona, did the removal of libbluetooth2 cause the removal of other packages?

No it didn't. I think the package was there because I installed Ubuntu more than a year ago and made distribution upgrades since.

[ECantona (ozaktash)]

I should correct myself. The problem is still there. I don't know how and why it worked yesterday. Maybe timeouts were shorter than usual.

[lvlao (maurizio-lesmo)]

Same problem here.... Logitech bluetooth Travel Mouse V270, installed correctly, but not reconnected at startup...
Ubuntu 8.10 Intrepid Ibex.

Thanks for any suggestion.

[Brian Rogers (brian-rogers)]

With anyone still experiencing issues, does running "sudo hciconfig hci0 lp hold,park" before you turn on your mouse help?

[lvlao (maurizio-lesmo)]

Brian I can't try your workaround because now I have the problem anymore....
This is what I do:

(Bluetooth Preferences) -> (Visibility Setting) -> ALWAYS VISIBLE
RESTART
(Bluetooth Preferences) -> (Visibility Setting) -> HIDDEN
RESTART

I don't kowow why, but the problem is gone... I'll made more test...

Bye

[lvlao (maurizio-lesmo)]

Ok... I'm wrong.... with ALWAYS VISIBLE works, but with HIDDEN works only at first reboot........... :(

Brian I try your workaround and it works!
I put your string in a terminal and then turn on my mouse.

Great.... but what does it mean? :D

Thanks

[ECantona (ozaktash)]

>With anyone still experiencing issues, does running "sudo hciconfig hci0 lp hold,park" before you turn on your mouse >help?

Nope :/

[Fabián Rodríguez (magicfab)]

I am having this same problem with 3 different systems, using integrated Bluetooth or external dongles, using Intrepid with all updates as of today.

I tested with a Microsoft keyboard + mouse combo, as well as with a Microsoft Bluetooth Notebook Mouse 5000.

Here are USB IDs of 2 of the bluetooth radios:
ID 03f0:171d Hewlett-Packard Wireless (Bluetooth + WLAN) Interface [Integrated Module]
ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

The proposed workaround doesn't work. Even if it did I can't justify using it on laptops as it would expose the BT connection to third-parties, a security concern for many.

[ECantona (ozaktash)]

I have replaced my speedlink mouse with a wireless mighty mouse and it works flawlessly. I recommend it to everyone.

[mjhooker (mjhooker)]

I get exactly this issue with a bluetooth mouse on 9.04, has the issue resurfaced?

[Dave (muellerdave)]

I'm running the current version of Ubuntu Lucid Lynx and I'm having the same problems with the bluetooth connection.
After a restart or sleep the devices need to be repaired!
Is there any fix for this??

[cjrcl (cjrcl)]

I think Robert Lange (rcl24)'s speculation on 2008-05-21 is true. I have the same issus with my apple wireless keyboard but not the accompanying apple wireless mouse. I must manually disconnect the keyboard in the system (by using my mouse) and then touch it. If I touch the keyboard first, the first single key input will be recieved correctly by the system whereas the following key input are ignored - maybe the rejection of the keyboard's reconnecting request has happened immediately after the first key press.