Ok, I can't tell you folks how glad I am right now. Bluetooth mouse, with scrollwheel working! I have had these Bluetooth Desktop sets, 2 Microsoft and 1 Logitech, laying around unused since I've been using Knoppix full time. Not your run of the mill $25 keyboard set. Some time back, I decided to make them work in linux, and I wound up getting the bluez kernel patch, and rebuilding the kernel... and it was one big hassle to get to work. I changed my installation and never bothered again.

Today, testing out my Knoppix 5.3.1 0wn installation(Klaus' latest installer which btw stands for Zero Work Needed)... I decided I wanted to see how far things had come along... Bluetooth wise. First thing I found... there is no kbluetoothd to start up. There is a kbluetooth, under Settings on the K menu. So I fired that up... and it looked different than earlier stuff. Same icon in the system tray though. I tried using it... and I got alot further than I thought I would... but it was not able to connect my keyboard all by itself. If you right click the kbluetooth icon in the tray, and select Configuration... there are a few choices that pop out... Input Devices was the one I was interested in. I will save you all some headaches... don't bother trying to use it to establish a new connection yet.

Here's a bug on... kmobiletools.org describing what I got... when I tried to use kbluetooth to get my keyboard and mouse working.
http://bluetooth.kmobiletools.org/ui...ad&ThreadID=30

Instead, open a Konqueror file browser(the Home icon) and go to /usr/share/doc/bluez-utils/
Click the README.Debian.gz file and ark opens README.Debian.

First point...
PIN (or passkey) management
---------------------------

For asking a PIN when necessary a passkey agent is required, the
bluez-gnome provides one, another one is provided as an example in
/usr/share/doc/bluez-utils/examples/passkey-agent.c
The old infrastructure /etc/bluetooth/passkey has been removed since the agent
is supposed to be started by a user session. It is not meant to be system-wide.
Second point...
Keyboard and mouse support
--------------------------

The hidd daemon allows keyboards and mice to be connected to your
system. Ensure you have the hidp patch for Linux 2.6.6 or better
from http://www.bluez.org/patches.html.

Then change HIDD_ENABLED in /etc/default/bluetooth to 1 and restart
bluetooth. That enables the hidd server. Discover you mouse or
keyboard bluetooth address (bdaddr) by running "hcitool scan". You
must then connect to your keyboard or mouse using hidd --connect
<bdaddr>. On first connection, pairing is likely and you should press
"connect" button on mice/keyboard, if any. Mice normally have a
preset PIN which should be in the manufacturer's documentation, try
0000. For keyboards, type the PIN on the Bluetooth keyboard and hit
enter, and then type it in on a cable-attached keyboard to pair. In
future your keyboard or mouse should reconnect to your computer
automatically. You must invoke hidd as root.
Now the 2 points. You have the info you need already... but I have a few things to add.

You will need to run "hcitool scan", and press the connect button to see your device's mac address first.
You will need that information to setup your device. (It is printed on the label on the bottom of my mouse.)

I created a file, which has my keyboard's mac address as it's name here.
/etc/bluetooth/passkeys/00:07:61:41:AD:A3
It says inside:
1234
No linefeed, carriage returns. nothing.

Then for my mouse,
/etc/bluetooth/passkeys/00:07:61:31:BD2
with nothing inside. 2 bytes are probably 2 linefeeds. (Yes, I used Konqueror's Create New->Text File.)
-rw-r--r-- 1 root root 2 Jun 30 02:43 00:07:61:31:BD2
-rw-r--r-- 1 root root 6 Jun 30 02:20 00:07:61:41:AD:A3
The point is... I am trying to show bluez that device is approved, and has no pin.
( The README.Debian says it is ignored... so later I will start removing things and see when it breaks things.)

Now to the beef...
Enable HID in /etc/default/bluetooth with a single change... hidd_enabled=0 to a 1
############ HIDD
#
# HID daemon
HIDD_ENABLED=1
Then type:
/etc/init.d/bluetooth restart
Now we are ready to connect...
(Press the connect button on the mouse first...)
hidd --connect 00:07:61:31:BD2
followed by... ( press the connect button on the keyboard and then...)
hidd --connect 00:07:61:32:E4:23

Abrief pause and no error messages, meant I should try and move my mouse... Bingo!

After I got my connections working...
sudo cat /var/log/syslog
shows...
Jun 30 02:45:20 knoppix hidd: New HID device 00:07:61:31:BD2 (Logitech Bluetooth Mouse)
Jun 30 02:45:20 knoppix kernel: input: Logitech Bluetooth Mouse as /class/input/input9
Jun 30 02:47:19 knoppix hidd: New HID device 00:07:61:32:E4:23 (Logitech Bluetooth Keyboard)
Jun 30 02:47:19 knoppix kernel: input: Logitech Bluetooth Keyboard as /class/input/input10
Now since I am not sure where things went right... at this point... I will also include this, and if it is not related to getting it to work, I'll come back and touch this up.

Here is my /etc/bluetooth/hcid.conf file.
#
# HCI daemon configuration file.
#

# HCId options
options {
# Automatically initialize new devices
autoinit yes;

# Security Manager mode
# none - Security manager disabled
# auto - Use local PIN for incoming connections
# user - Always ask user for a PIN
#
# JW default security user;
security auto;

# Pairing mode
# none - Pairing disabled
# multi - Allow pairing with already paired devices
# once - Pair once and deny successive attempts
pairing multi;

# Default PIN code for incoming connections
passkey "1234";
}

# Default settings for HCI devices
device {
# Local device name
# %d - device id
# %h - host name
name "%h-%d";

# Local device class
class 0x000100;

# Default packet type
#pkt_type DH1,DM1,HV1;

# Inquiry and Page scan
iscan enable;
pscan enable;

# Default link mode
# none - no specific policy
# accept - always accept incoming connections
# master - become master on incoming connections,
# deny role switch on outgoing connections
lm accept;

# Default link policy
# none - no specific policy
# rswitch - allow role switch
# hold - allow hold mode
# sniff - allow sniff mode
# park - allow park mode
lp rswitch,hold,sniff,park;

# These are no longer supported... in hcid.conf
# Authentication and Encryption
# auth enable;
# encrypt enable;
}

device 00:07:61:32:E4:23 {
name "Logitech MX5000 Keyboard";
# auth enable;
# encrypt enable;
}

device 00:07:61:31:BD2 {
name "Logitech MX1000 mouse";
# auth disable
# encrypt disable
}
I changed my security mode to auto, from user... to eliminate some problems in getting it to work.
Later I will set that back to defaults, and everything else too... and try and locate exactly which changes are needed.
( Right now, I am enjoying my new keyboard and mouse too much.)

Next up... tomorrow maybe... those Microsoft Desktop Elite for Bluetooth.
(They do not even work at the Dos/Bios level except after they have sat for a while... and then a cold bootup.
They Really need Windows... too bad all they will ever get is VirtualBox from now on.)

Enjoy your Bluetooth input devices folks. It's been a long time coming.
So far, I have not had any problem with the devices going to sleep and not working...
the mouse has more buttons than the 2 main mouse buttons... and they are all doing something. I may need to add more configurations to get them to do what I want them to do. Is there an X def for my keyboard, mouse...? Later.

There is another way to get this to work, using hci... but that was not working for me tonight.
Once I enabled the hidd, it seems that kbluetooth is not as functional as it was trying to be beforehand.(It didn't work so I haven't lost anything.) Kbluetooth does seem to know what is connected... and even pops up a balloon saying what is connected. It has stayed on, a nice dark blue, throughout my session. Cool.