Apple Wireless keyboard needs a manual disconnect before reconnecting.

[Dennis]

Binary package hint: gnome-bluetooth

Hello,

I bought me four days ago the small Apple Wireless Keyboard and tried to
get it working. The best part was that I couldn't get it working under
Windows XP ^^. To get it running with Hardy cost me 5 min! Really cool!
The last problem is that if the keyboard goes to sleep gnome doesn't
recognize that the connection is down. So I believe gnome doesn't allow
a reconnect, cause it seems from his perspective connect. If I
disconnect the keyboard via gnome-bluetooth and start typing everything
works again!

Since my bluetooth adapter blinks with an LED when it receives or
transmits I know that it receives something (the keyboard is curently
the only bluetooth device near by).

dennis@x90:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

gnome-bluetooth:
  Installed: (none)
  Candidate: 0.11.0-0ubuntu1
  Version table:
     0.11.0-0ubuntu1 0
        500 http://de.archive.ubuntu.com hardy/universe Packages

My version of gnome-bluetooth:

> root@x90:/tmp# apt-cache showpkg gnome-bluetooth
> Package: gnome-bluetooth
> Versions:
> 0.11.0-0ubuntu1 (/var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_hardy_universe_binary-i386_Packages)
> Description Language:
> File: /var/lib/apt/lists/de.archive.ubuntu.com_ubuntu_dists_hardy_universe_binary-i386_Packages
> MD5: 4c4a1fcafc0db7bd8ff81a5754e0c65b
>
>
> Reverse Depends:
> blueproximity,gnome-bluetooth
> nautilus-sendto,gnome-bluetooth
> Dependencies:
> 0.11.0-0ubuntu1 - gconf2 (2 2.10.1-2) libart-2.0-2 (2 2.3.18) libatk1.0-0 (2 1.20.0) libbluetooth2 (2 3.14) libbonobo2-0 (2 2.15.0) libbonoboui2-0 (2 2.15.1) libbtctl4 (2 0.8.0) libc6 (2 2.7-1) libcairo2 (2 1.5.14) libfontconfig1 (2 2.4.0) libfreetype6 (2 2.3.5) libgconf2-4 (2 2.13.5) libglade2-0 (2 1:2.6.1) libglib2.0-0 (2 2.12.0) libgnome2-0 (2 2.17.3) libgnomebt0 (2 0.5.1) libgnomecanvas2-0 (2 2.11.1) libgnomeui-0 (2 2.17.1) libgnomevfs2-0 (2 1:2.17.90) libgtk2.0-0 (2 2.12.0) libice6 (2 1:1.0.0) liborbit2 (2 1:2.14.10) libpango1.0-0 (2 1.20.0) libpixman-1-0 (2 0.9.4-2) libpng12-0 (2 1.2.13-4) libpopt0 (2 1.10) libsm6 (0 (null)) libx11-6 (0 (null)) libxml2 (0 (null)) libxrender1 (0 (null)) zlib1g (2 1:1.2.3.3.dfsg-1) bluez-gnome (2 0.17)
> Provides:
> 0.11.0-0ubuntu1 -
> Reverse Provides:

So far Hardy rocks! :D

Greetz

Dennis Guse

[Onkar Shinde (onkarshinde)]

gnome-bluetooth does not handle input device connectivity from UI. The right package is bluez-gnome.

[Robert Lange (rcl24)]

32-bit Hardy, upgraded from Gutsy. Using a diNovo Media Desktop Laser keyboard and mouse in hci-mode, not hid-mode. Each device is paired and trusted in bluetooth-properties and appears to work normally, for the most part.

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

I have a very similar problem. After a long break (15-20 minutes or so, I don't know for sure as I have not timed it), when I move my mouse, I get no response. If I use another device to open bluetooth-properties, I see that the mouse is connected, but it is non-responsive to my movements or clicks. If I use the bluetooth-properties dialog to disconnect the mouse, the next time I move the mouse, it reconnects.

Note: my bluetooth dongle provides no lights to indicate whether it is receiving data.

This is a big problem for me, because I bought my Bluetooth keyboard and mouse set with the intention of eliminating my wired keyboard and mouse.

Fortunately, it *appears* as though the diNovo keyboard is not affected by this. It always seems to reconnect as soon as I hit a key, regardless of how long I have left the system unattended. So currently, my workaround is to use the keyboard to navigate to the bluetooth-properties dialog and disconnect the mouse, thereby restoring service to the mouse.

This gets the job done, but is very annoying, as I have frequent interruptions throughout the day. I would be glad to help fix this, but I don't know where to start.

[Robert Lange (rcl24)]

I believe that this bug is a symptom of the underlying bug from Bug #175743. My comment #8 describes the current status of my research into this bug.

I believe this bug should be marked as a duplicate of that bug.