I've tried to experiment with /usr/bin/btui and the /usr/bin/btd daemon...
The btui program declares to be a test program, when launched, it says :
Code:
*** Welcome to TESTUI :) ***
Available commands:
1. TurnOnBluetooth
2. TurnOffBluetooth
3. Scan
4. A2DPDiscovery
5. CancelScan
6. Pair
7. CancelPairing
8. Unpair
9. Connect
10. Disconnect
11. Play
12. Pause
13. Stop
14. SetDiscoverable
15. SetNonDiscoverable
16. SetConnectable
17. SetNonConnectable
18. ShowPaired
19. ShowConnected
20. ShowDiscovered
21. ShowAllDevice
22. Disable_auto_connect
23. Enable_auto_connect
24. Disable_PTS_Mode
25. Enable_PTS_Mode
26. Enable_BT_Perf_Logging
27. Enable_BT_Snoop_Logging
28. Disable_BT_perf_logging
29. Disable_BT_Snoop
30. Disable_BT_all_trace
31. Enable_BT_all_trace
32. Enable_BT_log_to_file
33. Disable_BT_log_to_file
Enter a command:
If the Bluetooth daemon hasn't been launched, any number typed at the prompt only seems to display the name of the command invoked, without any further effect...
Code:
Enter a command: 1
TurnOnBluetooth...
Enter a command: 14
SetDiscoverable...
Enter a command: 16
SetConnectable...
Enter a command: 3
Scan...
Enter a command: 20
ShowDiscovered...
Enter a command: 0
"0" is not a recognized command
Enter a command: ^C
During these "actions", I had a phone with bluetooth activated, and couldn't detect the Kindle, so it seems the commands aren't effective...
Starting btd with -? parameter gives the following usage :
Code:
Usage: btd [OPTION]...
-f, --foreground
Run in foreground mode instead of daemon mode. Runs until
terminated with SIGTERM, SIGTRAP, SIGUSR1. Outputs
additional messages.
-d, --debug
Enable LLOG-based diagnostics at level 0 (LLOGS_DEBUG, LLOGS_DEBUG0).
-dn, --debug=n
Enable LLOG-based diagnostics at level n (LLOGS_DEBUGn).
-t, --trace
Enable trace level 0 (low).
-tn, --trace=n
Enable trace level n (0 low, 1 med, 2 high, 3 all)
-ofname, --traceout=fname
Redirects trace output to file 'fname' without changing trace
level (can repeat -t option as needed).
-n, --noop
Launch, print a message, and then immediately exit.
-wn, --watchtime=n
Set watchdog timer for n sec (default: 40). n=0 disables
watchdog timer (for debugging).
-?, --help
Display usage information.
When the btd daemon runs, the btui test program seems to interoperate with the btd daemon (a slightly disturbing thing is that the prompt returns before the command is really executed... maybe each command is executed in a separate thread) :
Code:
Enter a command: 1
TurnOnBluetooth...
Enter a command:
BT_EnableCallbackResult = 0
3
Scan...
Enter a command:
BT_StartDiscoverCallbackResult = 0
BT_SetPowerModeCallbackResult = 0
BT_DiscoverCallback
BD_Name = Bluetooth Keyboard
BD_Address = 0C:FC:83:1A:84:AB
Class Of Device = Peripheral
Vendor ID = 0
Product ID = 0
Version = 0
Services = 0
RSSI = -72
Paired = 0
Connected = 0
BT_DiscoverCallback
BD_Name = SMA002d SN: 20015216
BD_Address = 00:80:25:15:98:81
Class Of Device = Unknown device type
Vendor ID = 0
Product ID = 0
Version = 0
Services = 0
RSSI = -95
Paired = 0
Connected = 0
BT_DiscoverCompleteCallbackResult = 0
BT_EnableAutoConnectCallbackResult = 0
However, trying command #6 (Pair) did not report anything nor asked any parameter...
Anyway, this btui is only a test program, not the way to programmatically use the bluetooth driver...
Finally, when I closed the session, a VoiceView dialog could be seen on the graphical interface, saying that the bluetooth audio device could not be found... this interaction between the text commands and the graphical interface is strange...