# kbluetoothd: The Core of the KDE Bluetooth Framework

KBluetoothD is a central piece of the KDE Bluetooth framework. It runs all the time in the system tray usually and starts other services like the OBEX Server or bemused on demand. Its system tray icon tells you about ongoing bluetooth connections and also gives you quick access to the service configuration, recently used services, devices in range and more.

Programmers who want to integrate their program with kdebluetooth, should take a look at the developers section for more information.

## Starting kbluetoothd

You can start KBluetoothD by typing `kbluetoothd` on the command line or by starting it from the K-Menu (usually System/kbluetoothd).

KBluetoothD displays and icon in the system tray, but if you don't like it you can disable "Always visible" in the context menu of the tray icon. Then kbluetoothd will run without any visible user interface, even after it's restarted. To re-enable the icon, simply start kbluetoothd again. If the icon was disabled, it will still appear for the duration of a bluetooth connection.

When kbluetoothd is running until the system is shut down, it will be started again automatically next time you log in. To keep kbluetooth from starting up automatically, just close it and tell it not to start when you log in the next time.

## What kbluetoothd does

The most important feature of kbluetoothd is its Bluetooth meta server. Since kbluetoothd is running all the time anyway, it also monitors your Bluetooth adaptor, tells you when there are connections and caches name requests. The idea is that kbluetoothd is the only bluetooth related program that needs to run all the time while still having access to all activated services.

### The meta server

If you know what the inetd is doing in a Linux system, then you already have an idea what the meta server of kbluetoothd is good for: It waits for incoming connections on behalf of the real service handlers and starts them when necessary. So you don't need to have an obex server running all the time, but when someone sends you a file via OBEX, then the OBEX-server will be started automatically.

There are several reasons for using such an indirection:

- It reduces the memory requirements when you use several services. The KDE Bluetooth Framework currently comes with four server programs: the obex server, the handsfree client, the bemused client and the serial chat tool. While you may need some of these services only rarely, you can still leave them enabled at no cost.

- Your system tray won't be cluttered with lots of rarely used icons.

- It improves security and makes access control easier to manage. KBluetoothD will by default pop up a dialog asking for permission if there is an incoming connection. The user can override this dialog and permanently allow or disallow connections for each service and device. This gives every application managed by kbluetoothd access control for free.

- It has the potential to make bluetooth services more reliable. Each server is started for every new connection, so if a server crashes, you can try again without having to restart it.

  For a webserver it may be a bottleneck to be managed by inted, but in the case of Bluetooth, connection setup takes several seconds anyway and every action is usually user initiated, which makes using a metaserver uncritical.

- Service registration with the SDP server is very simple. Please see the developer section for how kbluetoothd-managed application register with the SDP server.

- Simple server programs - even scripts - can be used to implement a bluetooth server without using Bluetooth-related functions at all.

You can enable/disable services used by kbluetoothd with it control center module under the "Local services" tab. There you can also configure service specific options by selecting a service and clicking on the "Configure..."-Button.

Under the "Confirmation" tab you can customize how kbluetoothd will react on incoming connections.

### The Device Discovery Service

For many applications it is important to know, if a given device is currently in reach or not, or even be notified if a device comes in reach or leaves. Unlike USB, where the hotplug framework notifies you about new devices, there is no such service for bluetooth.

kbluetoothd fills this gap with the Device Discovery Service. It will periodically search for nearby devices and keep a list of those which are currently in reach. To access a dicovered device, right click the kbluetoothd tray icon and take a look at the "Open recent"-menu. This menu consists of one section for recently accessed services (like "obex ftp on MyPhone") and - if there actually are already discovered devices - a second section above with a list of devices. Clicking one of them will show the services of that device in konqueror.

In the control center module of kbluetoothd you can configure if and how often kbluetoothd searches for devices ("Periodially update neighbor list"). I recommend not to use intervals smaller than one minute here, otherwise other applications might have occacional problems searching for devices. That is because most devices don't expect other applications to use bluetooth at the same time.

Many devices are non-discoverable by default for privacy/security reasons. In that case the device won't be detected when searching for devices. Instead, kbluetoothd has to try to access each of these devices individually. You can add a device to the list of non-discoverable devices by clicking on "Additional search options for non-discoverable devices". Please note that either you have to set your device to be discoverable temporarly or you have to know its hardware address to be able to add it to the list.

This will prevent other programs from searching for devices or even setting up a connection to another device for about 30 seconds per device if the device is not reachable currently. Therefore you should use rather long interval here. 10 minutes seems to be a reasonable value. Just try yourself and find out how small the interval can be until it start bothering you.

Having just a list of currently reachable devices isn't that useful. Instead you can use the device discovery service to execute Discovery Jobs when a device comes in reach or disappears. These discovery jobs are simple scripts. You can easily write your own script - see the developer section about discovery scripts. But kbluetoothd already comes with some scripts, including:

Discovery protocol

- This script will create a html page with some technical information for every device when it is discovered for the first time. You can use this script if you are curious to see who else is using bluetooth near your. Having this script activated all the time doesn't hurt much, since it will only try to access the device when it is disocvered for the first time or after you deleted the corresponding html page.

Kopete_AutoAway

- This will set the availability status of kopete depending on if you (together with your phone) are in reach or not.

Photo_Copy

- This script will check a folder on your phone via kio_obex for new files and copy them over to a local directory. It also renames them with the date of the file as the file name. I wrote this script for my Nokia 6230. If you want to use it for your own phone, you will most likely have to change the script in many places.

Screensaver

- Starts or kills the screensaver/screen locker every time one of the monitored devices come in reach or disappear.

Most scripts must be configured first to work correctly. Clicking "configure" will usually just pop up kedit with the settings part of the script. Also be aware that you may have to limit the devices reported to each job, if you don't want the script to be executed when someone else passes by with a Bluetooth phone turned on.

### The "most recently used services" list

You can quickly access services you've used before by finding them in the "Recently used"-submenu of kbluetoothd's tray icon. If you already sent some files to you mobile with the name "My phone" via kbtobexclient, then you will find a menu entry with the name "Obex push client - My phone", which will start kbtobexclient and immediately connect to your phone without a time consuming inquiry process.

Please note that kbluetoothd shows all recently used services, no matter if the respective device is currently in range or not.

This feature must be supported by the respective application.

### Connection monitor

You can see if there is currently a bluetooth connection by looking at the tray icon of kbluetoothd. It will bling if a connection is being established and turn blue once the connection is set up.

You can get more information about the current connection by right-clicking on the tray icon and selecting "Connection details...".

What kbluetoothd displays here are ACL-links, not Rfcomm-connection. If you are connected to a single device with several programs (handsfree and bemused for instance), this will still be displayed as one connection, since there can only be one ACL link to a single device at a given time.

## Configuring kbluetoothd

Usually, kbluetoothd and the servers managed by it should work out of the box. But there are still some options you can change. To configure kbluetoothd, you can either use the KDE control center and go to Internet & Network -> Bluetooth services, or right-click the kbluetoothd tray icon and select Configuration -> Services...

### Confirmation of incoming connections

In this tab you can change the confirmation settings for incoming connections. By default, kbluetoothd will pop up a confirmation dialog before the actual server program (like the OBEX Push Server) is started. Here you can disable this confirmation dialog for some devices/services or tell kbluetoothd to silently reject incoming connections.

New device entries will be added when you select the "Always accept"-checkbox of a confirmation popup.

### Local Services

In this tab you can enable or disable single Bluetooth services which are managed by kbluetoothd. Some services also provide some configuration options, like the bemused server for instance. In that case, the Configure... will be enabled when you select the respective service.

Since kbluetoothd automatically assigns rfcomm channels to the services, the channel used for one service might change when you are using other bluetooth servers. If you need to know, which channel was assigned to some service, this dialog will tell you.