I'm using Debian Jessie (testing). I have a bluetooth mouse (Microsoft Sculpt Comfort) and I can pair it and use it ok, but after some time of inactivity (around 10 minutes) it stops working, I have to manually touch the set discoverable button on the mouse and re-pair it on the command line.

The same mouse I tried on OS X and it works, so it's not a hardware issue

Kernel 3.14.12-1 (2014-07-11)

I pair the mouse with this command:

sudo hidd --connect 30:59:B7:72:A5:A7

When paired correctly, this is the /var/log/syslog output

Jan  7 15:22:42 desktop hidd: New HID device 30:59:B7:72:A5:A7 (Microsoft Bluetooth Mouse        )
Jan  7 15:22:42 desktop kernel: [103877.102083] hid-generic 0005:045E:07A2.0009: unknown main item tag 0x0
Jan  7 15:22:42 desktop kernel: [103877.102481] input: Microsoft Bluetooth Mouse         as /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/bluetooth/hci0/hci0:42/0005:045E:07A2.0009/input/input51
Jan  7 15:22:42 desktop kernel: [103877.102884] hid-generic 0005:045E:07A2.0009: input,hidraw3: BLUETOOTH HID v1.29 Mouse [Microsoft Bluetooth Mouse        ] on 00:15:83:c8:52:19

After some idle time, this is printed on the same log file:

Jan  7 15:34:34 desktop acpid: input device has been disconnected, fd 20

If I click a mouse button or move it, this gets printed:

Jan  7 15:49:55 desktop bluetoothd[650]: Refusing input device connect: No such file or directory (2)
Jan  7 15:49:56 desktop bluetoothd[650]: Refusing connection from 30:59:B7:72:A5:A7: unknown device

Which seems to indicate that the mouse is still working and trying to tell the OS to re-connect, but it cannot.

This is the udevadm info -p response:

P: /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/bluetooth/hci0/hci0:42/0005:045E:07A2.0004/input/input22
E: ABS=100000000
E: DEVPATH=/devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/bluetooth/hci0/hci0:42/0005:045E:07A2.0004/input/input22
E: EV=10001f
E: ID_FOR_SEAT=input-pci-0000_00_02_0-usb-0_3_1_0
E: ID_PATH=pci-0000:00:02.0-usb-0:3:1.0
E: ID_PATH_TAG=pci-0000_00_02_0-usb-0_3_1_0
E: KEY=4837fff072ff32d bf54444600000000 1f0001 30f908b17c007 ffe77bfad9415fff febeffdff3cfffff fffffffffffffffe
E: MODALIAS=input:b0005v045Ep07A2e0129-e0,1,2,3,4,14,    k71,72,73,74,75,77,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8B,8C,8E,90,96,98,9B,9C,9E,9F,A1,A3,A4,A5,A6,A7,A8,A9,AB,AC,AD,AE,B0,    B1,B2,B5,B6,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,CE,CF,D0,D1,D2,D4,D8,D9,DB,DF,E4,E7,E8,E9,EA,EB,F0,F1,100,110,111,112,113,114,161,162,166,16A,1    6E,172,174,176,178,179,17A,17B,17C,17D,17F,180,182,183,185,188,189,18C,18D,18E,18F,190,191,192,193,195,198,199,19A,1A0,1A1,1A2,1A3,1A4,1A5,1A6,    1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1B0,1B1,1B7,1BA,r0,1,6,7,8,9,a20,m4,lsfw
E: MSC=10
E: NAME="Microsoft Bluetooth Mouse        "
E: PHYS="00:15:83:c8:52:19"
E: PRODUCT=5/45e/7a2/129
E: REL=3c3
E: TAGS=:seat:
E: UNIQ="30:59:b7:72:a5:a7"
  • 1
    I found solution to my bluetooth prob (no logitech mouse-PC auto sync/reconnection) adding parameters to gnome-bluetooth like disclosure here: ralphm.net/blog/2013/10 Feb 4 '15 at 15:39
  • the microsoft mouse was already in the pin-code-database.xml, still doesn't work, thanks for the info
    – AndresQ
    Feb 4 '15 at 18:28

There are 3 solutions for this problem. Maybe even combining 2 of them could fix your issue.

Solution 1

Edit the file /etc/bluetooth/input.conf and set the parameter IdleTimeout=0 inside the [General] block.

root@nwdesktop:~# vim /etc/bluetooth/input.conf

# Configuration file for the input service

# This section contains options which are not specific to any
# particular interface

# Set idle timeout (in minutes) before the connection will
# be disconnect (defaults to 0 for no timeout)

Restart the bluetooth service:

root@nwdesktop:~# /etc/init.d/bluetooth restart
 * Stopping bluetooth                                                    [ OK ] 
 * Starting bluetooth                                                    [ OK ]

This will prevent disconnections due to timeout from your bluetooth mice and keyboards.

Solution 2

Create an udev rule that will avoid your mouse to autosuspend

root@nwdesktop:~# vi /etc/udev/rules.d/91-local.rules

ACTION=="add", SUBSYSTEM=="bluetooth", ATTR{product}=="Microsoft Bluetooth Mouse        ", ATTR{power/control}="on"

root@nwdesktop:~# # udevadm control --reload-rules

Solution 3

This one does not makes me proud, but... Create a script with your hidd connect command:

user@nwdesktop:~# vi /home/user/recconect.sh

sudo hidd --connect 30:59:B7:72:A5:A7

Now, add to your crontab:

root@nwdesktop:~# vi /etc/crontab

*/10   *    *   *   *   root /home/user/recconect.sh


  • Tried this, with the same result as before :(
    – AndresQ
    Jan 7 '15 at 19:43
  • Does your notebook uses the module thinkpad-acpi ? (lsmod | grep acpi to check it).
    – user34720
    Jan 8 '15 at 12:22
  • no, I don't have that module loaded
    – AndresQ
    Jan 8 '15 at 12:23
  • Could you please post more details of your mouse running the following command and editing your question? udevadm info -p /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/bluetooth/hci0/hci0:42/0005:045E:07A2.0009/input/input51 . This path that starts with /device could change on your log...
    – user34720
    Jan 8 '15 at 12:29
  • Another question. Is the package laptop-mode-tools installed on your machine? Thanks for all this information your are mining ;)
    – user34720
    Jan 8 '15 at 12:51

The only thing that I had to do to enable (connect) wireless headphones Sony MDR-ZX550BN are in /etc/bluetooth/input.conf

add/uncomment line:

#Enable HID protocol handling in userspace input profile

#Defaults to false (HIDP handled in HIDP kernel module)


and naturally restart service /etc/init.d/bluetooth restart

P.S. I'm using Debian 8 Jessie

  • 1
    Could you please explain how this is relevant to the question? Jan 6 '16 at 12:01
  • 1
    because I had same symptoms like AndresQ (but with my wireless bluetooth headphones), and I found somewhere that you need to modify configuration, after which you don't have any issues "with repairing bluetooth connection". But hey, if you think that this might not help someone, feel free to check my comment as "non useful".
    – dovla0178
    Jan 11 '16 at 18:46

Looking at the logs I noticed that every disconnect threw a line with an UPower debug message. It appears that the xfce4-power-manager was using this daemon to poll the trackpad now and then for its battery level. What seems to have fixed the issue for me is to completely disable and uninstall UPower and xfce4-power-manager.

  • 1
    I presume by logs, you mean /var/log/syslog; this answer would be improved by editing it to mention this. It would also be useful to mention the disadvantages (if any) of removing UPower and xfce4-power-manager. May 29 '17 at 9:05
  • Not really. I jumped onto the systemd wagon long ago and check logs with journalctl. It might be different for other systems or distributions. And I think users are responsible for their systems and if they do decide to take my advice they should know what they're doing. I'm merely stating how I personally fixed the issue exposed in this question.
    – Ger
    May 30 '17 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.