Bluetooth mouse doesn't work.

Bug #29506 reported by Lakin Wecker
26
Affects Status Importance Assigned to Milestone
bluez-utils (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

After a fresh Dapper-Flight-3 install and even after updating to the latest packages available, my bluetooth mouse doesn't work with my Acer Ferrari 4005 laptop.

The mouse is there and is properly detected. With my phone, I can connect fine and send files (once gnome-obex-server) is installed. So bluetooth drivers are properly installed and are working, just not my mouse.

I've even edited /etc/default/bluez-utils and changed the line:
HIDD_ENABLED=1

and then rebooted. Still no luck.

lakin@Zedd:~$ hcitool scan
Scanning ...
        00:16:20:44:BE:99 Lakin Z520a
        00:10:C6:54:02:72 Acer Bluetooth Optical Rechargeable Mouse
lakin@Zedd:~$ sudo l2ping 00:10:C6:54:02:72
Password:
Ping: 00:10:C6:54:02:72 from 00:0B:6B:5C:68:7F (data size 44) ...
0 bytes from 00:10:C6:54:02:72 id 0 time 28.82ms
0 bytes from 00:10:C6:54:02:72 id 1 time 9.65ms
0 bytes from 00:10:C6:54:02:72 id 2 time 10.81ms
3 sent, 3 received, 0% loss

Revision history for this message
meba (jakub-rtfm) wrote :

try hidd --search when connecting mouse

Revision history for this message
Lakin Wecker (lakin) wrote :

Yes, that command connects to my mouse and I can use it succesfully after that.

So in terms of bluetooth hardware compatilibity everything works well, but this should be automatic IMHO.

Revision history for this message
Charles Majola (chmj) wrote :

Please test if you still have that problem with the fixed package in the archive.

Revision history for this message
Lakin Wecker (lakin) wrote :

Testing with the latest dapper packages (from 20 minutes ago), I still can't use the mouse by default. If I run the hidd --search, then it connects and works.

Changed in bluez-utils:
status: Unconfirmed → Confirmed
Revision history for this message
loko (arph) wrote :

i also noticed the bug, with sudo hidd --connect i can connect to my mouse.

i also noticed gnomebluetooth does not find the mouse.

Revision history for this message
Lothar (lothar-tradescape) wrote :

hcitool scan does not work for me. It seems that disabling the whole bluez stuff helps (see bug #32415

lothar@janus$ sudo hcitool scan
Scanning ...
lothar@janus$

Revision history for this message
Andres Mujica (andres.mujica) wrote :

Hi, can you confirm if the behaviour off your problem is similar or the same of this bug report:

https://launchpad.net/distros/ubuntu/+source/bluez-utils/+bug/15263

Revision history for this message
Géraud Gratacap (amalsek-ro) wrote :

Same problem here, on Edgy. I've got the Logitech MX1000 mouse and Logitech MX5000 keyboard, which aren't automaticaly detected. This is very troublesome if you don't have any usb/ps2 keybord/mouse. I had to follow the howto here :

http://www.ubuntuforums.org/showthread.php?t=227057&highlight=bluetooth+keyboard

and force the connection with the MAC addresses /etc/default/bluetooth with the following option

HIDD_OPTIONS="--master --connect KEYBOARD_ADDR --connect MOUSE_ADDR --server"

After this, the mouse and keyboard connect without any problem ( with a reboot or sudo invoke-rc.d bluetooth restart ).

Note : If you only have bluetooth keyboard and mouse, disable ACPI with the kernel option "acpi=off", it seems they are taken like classical usb peripherals. Modify the configs and reboot normally. Should work.

Note : Excuse me for any mistake in my english, I'm french ;=)

Revision history for this message
Filip Palm (filip) wrote :

I can confirm this on Edgy to, the way bluetooth devices is handled now is not very userfriendly.

This should be done automatically not by editing /etc files.

Revision history for this message
stuart hayes (stuart-hayes) wrote :

This really needs to be changed--it is not at all usesr friendly right now.

As it is, it appears to the user that the Dell™ Desktop Bluetooth Wireless Keyboard and Mouse Bundle simply quits working after Ubuntu is installed and booted up. The user is not alerted to the fact that the keyboard/mouse receiver has been reconfigured to HCI mode and that the keyboard & mouse must be paired to the system for them to work. Most users are probably not even aware of the difference between HID and HCI modes, and just want their keyboard/mouse to work without configuration.

Either the wireless keyboard/mouse receiver should not be automatically put into HCI mode, or the user should be alerted of this fact and told how to pair their keyboard/mouse to the system so that they will continue to work.

Revision history for this message
Daniel Holbach (dholbach) wrote :

Marcel: can you think of a hassle free way to make this easier for users?

Revision history for this message
stuart hayes (stuart-hayes) wrote :

I would suggest either not running hid2hci by default in the bluetooth startup script, or else having some sort of blacklist for it so that it doesn't change this device to HCI mode by default. I don't think most people expect their Dell wireless keyboard/mouse to start behaving as a bluetooth controller. It would be preferable (in my opinion) for customers who want that to enable it, than it would be for customers who don't care about that to have to go re-enable their keyboard after they install Ubuntu.

Revision history for this message
Lothar (lothar-tradescape) wrote : Re: [Bug 29506] Re: Bluetooth mouse doesn't work.

On Thursday 26 April 2007 08:17, stuart hayes wrote:
> I would suggest either not running hid2hci by default in the bluetooth
> startup script, or else having some sort of blacklist for it so that it
> doesn't change this device to HCI mode by default.

That is NOT an option, as almost all modern mice NEED HCI mode to support the
scroll wheel. Ubuntu has simply to find a way, so that BT mice work out of
the box.

Lothar

Revision history for this message
stuart hayes (stuart-hayes) wrote :

Why would mice need HCI mode to support a scroll wheel? In HID mode, the wireless mouse should look like an ordinary USB mouse, which can support a scroll wheel.

Revision history for this message
Jose De la Rosa (jose-de-la-rosa) wrote :

Issue still seen on Gusty

Changed in dell:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Marcel Holtmann (holtmann) wrote :

The HCI versus HID mode has nothing to do with report mode versus boot mode. That are two total different things.

Revision history for this message
roderikk (roderikk) wrote :

I can confirm this on a fresh install of Gutsy as well. Also each time after it went to screensaver it would have lost the connection.

However, using the suggestion from: https://help.ubuntu.com/community/BluetoothMouse

More specifically:

   1. Edit the file /etc/default/bluetooth: sudo sensible-editor /etc/default/bluetooth
   2. Set the variable HIDD_ENABLED=1.
   3. Restart the bluetooth service with the command: sudo /etc/init.d/bluetooth restart

Fixed it. Maybe there should be an option in the Bluetooth settings whether you are using a bluetooth mouse/keyboard and then enable HIDD?

Revision history for this message
Hendrik De Graeve (hendrikdegraeve) wrote :

Also add this line...

HIDD_ENABLED=1
HIDD_OPTIONS="--connect 00:00:00:00:00:00 --server"

Instead of the 00:00:00:00:00:00 change the numbers to the numbers of your mouse or appliance.

You can find this MAC number with the following command: sudo hidd --search or just do "hidd" in the terminal.

Revision history for this message
mjbarker5 (barker-m) wrote :

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.

Microsoft Bluetooth Notebook Mouse 5000
Ubuntu Gusty 7.10 - Gnome 2.20.1
IBM ThinkPad X41 Tablet with integrated bluetooth.

I am running the stock version of Ubuntu (no changes since install, except for updates)

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.

When I reboot the computer the mouse is automatically detected and connected. But it still looses connection after a period of inactivity.

-Matt

Revision history for this message
mjbarker5 (barker-m) wrote :

I should have wrote this in my previous post.
While the mouse is connected and working, if I turn the mouse off then turn it on it will reconnect. After the mouse has lost it's connection from inactivity and I turn it off then turn it on, it does not reconnect. I need to press the connection button and type hidd --search in the terminal.

-Matt

Revision history for this message
mjbarker5 (barker-m) wrote :

Well, I seem to have fixed my problem of the disappearing mouse.
In the gnome bluetooth manager under preferences I had to select the radio button that says "visible and connectable for other devices" I had previously selected "other devices can connect"

I left the mouse untouched for 2 hours and it came back fine. Everything seems to work.

-Matt

Changed in dell:
status: Confirmed → Fix Released
Revision history for this message
Adam Niedling (krychek) wrote :

Based on the last comment. Please reopen or open a new bug if you have still this issue in Hardy.

Changed in bluez-utils:
status: Confirmed → Fix Released
Revision history for this message
Simone Malacarne (s-malacarne) wrote :

I have this issue on Hardy too (64bit).
Bluetooth mouse and keyboard work fine at startup but after some inactivity they lost connection.

I can reconnet them by going to "bluetooth manager" -> "preference" ->and manually click disconnect on mouse and keyboard.

In bt manager i have already "visible and connectable for other devices" but this not solve the problem.

Please reopen this bug.

Revision history for this message
Adam Niedling (krychek) wrote :

Simone: Isn't that just a power saving feature?

Revision history for this message
Simone Malacarne (s-malacarne) wrote :

Adam: i don't know. How can i check if this is a power saving problem?

Revision history for this message
Robert Lange (rcl24) wrote : agreed -- the bug still exists

32-bit Hardy, upgraded from Gutsy (32-bit). Using a dinovo media desktop laser keyboard and mouse. Both devices are paired and trusted.

I have the exact same problem as described by Simone Malacarne. I can reconnect the devices using the same workaround he described. I agree we need to reopen the bug.

My system has original Hardy bluetooth configuration files -- I have made no manual changes.

This is a huge problem for me, because I bought my Bluetooth keyboard and mouse set with the intention of eliminating my wired keyboard and mouse. Currently, whenever I leave the computer for a while, I would need to plug in a wired device for a moment just to resume using the Bluetooth devices. If that is the case, I might as well throw away the Bluetooth devices, because they are useless for me!

I would like to avoid kludgy workarounds if possible, like the suggestions above to hard-code device-specific connections or disable ACPI. Those seem like the sorts of things that will, in the long term, break more than they fix.

Adam: I am pretty sure that the Bluetooth devices shut down after a while as power-saving feature. The question is, once I move the mouse or hit a key on the keyboard, why does it not successfully re-connect, until *after* I use a wired device to manually "disconnect" the Bluetooth device from the Gnome bluetooth-properties applet?

Revision history for this message
Mario Limonciello (superm1) wrote :

Robert,

Please open another bug for this issue. It's completely separate (although I too see it w/ my mouse and keyboard). I started to try to look into it, and there was an indication that it's a bug in the X server, but no confirmation. I end up just unplugging/pluggin back in the USB BT adapter when I return to the comp.

Revision history for this message
Robert Lange (rcl24) wrote :

Mario Limonciello: I now agree that this bug is fixed and that Hardy's bluez-gnome package (bluetooth-properties program) works correctly to detect the mouse initially, without any kludgy hard-coded config files. I have found another Bug #175743 that describes the problem I am having with reconnecting. Anyone who finds my comments in this bug should refer to that bug, because that is the correct bug for those comments.

Changed in somerville:
importance: Undecided → Medium
status: New → Fix Released
no longer affects: dell
Revision history for this message
Timothy R. Chavez (timrchavez) wrote :

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1306150

no longer affects: somerville
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.