Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 220152 - bluetooth mouse disconnects after idle time
Summary: bluetooth mouse disconnects after idle time
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Mobile Herd (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-03 19:59 UTC by Martin Meyer
Modified: 2012-02-16 03:18 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Meyer 2008-05-03 19:59:25 UTC
I have a recurring issue with my bluetooth mouse being disconnected after periods of inactivity. The time required for this to occur seems to be somewhere in the area of an hour or more, but I haven't been able to narrow it down much past that.

My mouse is a Logitech MX900, which is rechargeable when plugged into a dock. I've noticed this problem regardless of whether I've left the mouse plugged in (charging) or not. After the mouse has disconnected, the output of 'hcitool -i hci0 con' seems to indicate that bluez thinks the mouse is still connected.

I resolve this connection problem by restarting my bluetooth service, but I'm hoping it might be a known problem or a configuration issue. Any idea what might be causing this disconnection?

Reproducible: Always

Steps to Reproduce:
1. Configure and use bluetooth mouse
2. Leave system idle for 1+ hour
3. Come back and try to use your mouse

Actual Results:  
No mouse movements :-(

Expected Results:  
Mouse movements!
Comment 1 J Chang 2008-07-14 19:23:52 UTC
Having the same problem.

My dongle is an internal usb that came with the laptop. lsusb reports it as "Dell Computer Corp. Wireless 350 Bluetooth".
My mouse is a Microsoft Wireless Notebook Presenter 8000 (model: 1065)

It looks like there is a kernel patch to fix the problem; any idea when this will move into the portage tree?

http://article.gmane.org/gmane.linux.bluez.devel/15745
Comment 2 Martin Meyer 2008-07-14 23:39:35 UTC
My issue actually seems to have fixed itself... I suspect it had to do with an update to xf86-input-evdev. I think the 1.99.2 release was the first one that this "worked" for me.

That patch might be good to consider for inclusion in gentoo-sources... Are there others experiencing similar issues though? So far that's only one "me too", and it turns out that my problem appears to be fixed now.

What version of xf86-input-evdev (if any) are you using? Do you have gpm running and (if so) does it continue to work after idle time? What version of xorg-server? Are you running arch or ~arch?
Comment 3 J Chang 2008-07-15 04:02:52 UTC
Still not working for me.

I tried the kernel patch, and it /sort of/ worked. It managed to get enough responsiveness to wake up a screen that's gone to sleep, but it won't move the cursor and there is no button response; very odd...

I'll try unmasking evdev 1.99.2


using:
tuxonice-sources 2.6.24-r9
xf86-input-evdev 1.1.5-r1
xorg-server 1.3.0.0-r6
bluez-utils 2.25-r1
bluez-libs 2.25


looks like there's some ubuntu folks having the same issues over here:
https://bugs.launchpad.net/ubuntu/intrepid/+source/linux/+bug/175743
Comment 4 Pacho Ramos gentoo-dev 2012-02-14 10:55:13 UTC
Still valid with latest stable tree?
Comment 5 Martin Meyer 2012-02-16 03:18:06 UTC
I've stopped using both that mouse and Gentoo, so I can't tell if this is still an issue. Closing for now.