Microsoft bluetooth stack for windows

Installing a Bluetooth Device

This topic is for programmers. If you are a customer experiencing Bluetooth device installation issues see Pair a Bluetooth device in Windows

There are two installation types for Bluetooth profile drivers:

Client-side installation for remote devices where the remote device advertises its services and the computer connects to it. Examples include: mouse devices, keyboards, and printers.

Server-side installation where the computer advertises services and remote devices can connect to the computer to use those services. For example, a vendor could author a server-side installation to enable a PDA to print to a printer attached to the computer.

These two installation types require different installation procedures.

Installing a Client-side Profile Driver

A user that wants to use a Bluetooth-enabled device will bring the device within range of the computer and initiate a connection from the computer to the remote device using the following installation sequence for a client-side profile driver.

Launch Bluetooth Devices in Control Panel to find all devices within range of the computer.

Select the device to pair with.

Pair (or bond) the device with the local radio. This may or may not involve a PIN exchange.

The local radio issues an SDP inquiry to identify the services supported on the remote device.

The Found New Hardware Wizard searches for appropriate drivers on the local hard disk drive, and/or on Windows Update.

If the Found New Hardware Wizard does not find an appropriate driver for the device, it prompts the user to insert the profile driver installation media that contains the profile driver’s device setup information file (INF file).

Installing a Server-side Profile Driver

The Bluetooth driver stack supports service GUIDs as defined by the Bluetooth SIG, as well as custom GUIDs (that is, GUIDs that are not defined by the Bluetooth SIG).

The Guidgen.exe tool provided with the Microsoft Windows SDK can be used to create custom GUIDs.

A user-mode installation application must be written to expose computer functionality that remote Bluetooth devices can use.

The installation application must communicate with the Bluetooth driver stack to create a service GUID for the functionality to expose. Vendors specify the service GUID in the application and in their device installation INF file.

The installation application must call the user-mode API BluetoothSetLocalServiceInfo. Before the application can call this API the application must have the SE_LOAD_DRIVER_NAME security privilege. The following code example demonstrates how to obtain this privilege. Note that the example does not demonstrate error handling.

Profile Driver INF file

A profile driver’s INF file contains information about a Bluetooth device for client-side installation. For a server-side installation, the INF file specifies a device ID that corresponds to the service GUID created by the installation application. All Bluetooth devices are members of the Bluetooth class. The Bluetooth class installer (Bthci.dll) assists in installing profile drivers.

For more information about creating and distributing INF files and installing drivers, see Creating an INF File and INF File Sections and Directives.

Plug and Play IDs

The Bluetooth driver stack generates hardware IDs according to the following templates:

BTHENUM\< ServiceGUID>_VID& nnnnnnnn_PID& nnnn

The Bluetooth driver stack generates compatible IDs according to the following template:

ServiceGUID is a 16-bit GUID expanded into a 128-bit GUID, as defined by the Bluetooth specification. For example, <00001124-0000-1000-8000-00805F9B34FB>corresponds to an HID device.

The 8 digits following VID& correspond to the vendor ID code.

The 4 digits following PID& correspond to the product ID code.

The 4 digits following LOCALMFG& correspond to the manufacturer of the local Bluetooth radio.

The VID/PID and LOCALMFG tags are independent of each other.

The most generic device ID is a ServiceGUID by itself. For example:

The Bluetooth driver stack can be restricted to load your profile driver and software to run only on a specific release of a remote device by using Plug and Play IDs in both the remote device and the INF file. Note that the Bluetooth driver stack generates a VID/PID pair only if the device publishes a Plug and Play ID that the stack can detect using SDP. For example:

The Bluetooth driver stack can be restricted to load profile driver and software to run only on a specific local Bluetooth radio by specifying the LOCALMFG tag in the device ID in your INF file. For example:

Источник

Introduction to Bluetooth Profile Drivers

This section describes the support that Microsoft provides for the wireless Bluetooth protocol. Bluetooth is an industry standard protocol that enables wireless connectivity for a variety of devices including computers, mobile phones, handheld devices, mouse devices, keyboards, and printers. This section also provides guidelines on how to develop Bluetooth profile drivers for your Bluetooth-enabled device. Details of the Bluetooth protocol are available on the Bluetooth website.

Microsoft provides support for the Bluetooth protocol in Microsoft Windows XP with Service Pack 2 (SP2) and later. Bluetooth drivers, known as profile drivers, are written by independent hardware vendors (IHVs) to support various protocols defined in the Bluetooth specifications. Profile drivers should follow the Windows Driver Model (WDM) architecture.

To support the Bluetooth protocol, Microsoft supplies several drivers and support files, including:

IHVs must use Windows Vista or later to develop their profile drivers because earlier versions of Windows, including Windows XP with SP2, do not support profile driver development.

The Bluetooth driver stack provides device driver interfaces (DDIs) that enable profile drivers to access Synchronous Connection-Oriented (SCO) links and Logical Link Controller and Adaptation Protocol (L2CAP) links between the local system and remote Bluetooth devices.

SCO

Synchronous connection-oriented (SCO) links are point-to-point connections between two Bluetooth devices. They are defined primarily to support time-bounded information like voice.

The Windows Vista Bluetooth driver stack has been enhanced to provide SCO kernel-mode DDIs. By using these interfaces, profile drivers can use the SCO DDIs to open, update, and close SCO connections, as well as perform read and write operations over an open SCO connection.

L2CAP and SDP

The L2CAP is designed to support asynchronous connectionless link (ACL) Bluetooth links. The Bluetooth driver stack provides support for connection-oriented services. Profile drivers use the Bluetooth L2CAP DDIs to open, update, and close L2CAP connections, as well as to perform read and write operations over an open L2CAP connection.

The Service Discovery Protocol (SDP) provides a way for a profile driver to advertise the services or discover services offered by the device it manages.

SDP records are advertised in a complex byte stream. Profile drivers can use the SDP DDIs to find an SDP record and convert it to a tree-based representation that is more easily interpreted for parsing. Profile drivers can also use the SDP DDIs to build a tree-based representation of an SDP record and then convert it to a stream to advertise it.

For more information about the Bluetooth driver stack, see Bluetooth Driver Stack.

Источник

Bluetooth Registry Entries

This section describes the class-of-device (CoD) registry subkeys and entries that apply to the Bluetooth driver stack.

«COD Major» and «COD Type» Values

Original equipment manufacturer (OEMs) can use the COD Major and COD Type values to indicate the Class of Device for a Bluetooth-enabled Windows device. After the Bluetooth class installer sets the Class of Device based on these registry values, a remote device can determine whether it is connecting to a portable computer, a desktop computer, a phone, and so on.

The registry path to the COD Major and COD Type values is:

Note that setting these values changes the Bluetooth Class of Device for the system, regardless of which Bluetooth radio may be attached. You can set the COD Major and COD Type to DWORD values as defined for the Class of Device field values in the Bluetooth SIG Assigned Numbers.

The Bluetooth profile driver, BthPort.sys, reads the COD Major and COD Type values to determine how it should respond to a device inquiry. These values affect only the COD_MAJOR_XXX and COD_XXX_MINOR_XXX bits of the Class of Device. The COD_SERVICE_XXX bits are not affected by this registry entry.

If the COD Major and COD Type values are not set or are set to invalid values, the Bluetooth class installer will set these values to COD_MAJOR_COMPUTER and COD_COMPUTER_MINOR_DESKTOP , respectively.

Scanning Parameterization Settings

Profile drivers can specify scanning parameters settings for their device(s) in their profile driver’s INF file to tailor to the specific needs of a given device scenario.

You can override the default system scanning parameters by providing one or more of the following scanning parameters listed below into the AddReg directive. More information on how to use this directive can be found in INF AddReg Directive.

Changes to scanning parameters make a global impact on the performance of the Bluetooth stack. Making changes to scanning parameters programmatically is not permitted. Using Low Duty Cycle scanning parameters that are too aggressive can not only have a negative impact to the available bandwidth for other Bluetooth Low Energy connections, but also for Bluetooth BR/EDR connections.

Источник