注意:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "Bluetooth made easy"

From Funtoo
Jump to navigation Jump to search
(→‎Custom Tips: updated startup commands)
(Added kernelop's, file's and {{c}}'s - - formatted the page to 'conform' more to wiki standards.)
 
Line 1: Line 1:
== Kernel Support ==
== Kernel Support ==
You must have bluetooth support in your kernel if you are going to use bluetooth.  Enable the following in your kernel config:
You must have bluetooth support in your kernel if you are going to use bluetooth.  Enable the following in your kernel config:
<console>
{{kernelop|title=Networking Support|desc=
##i##Networking support →
Bluetooth subsystem support →
  ##i##Bluetooth subsystem support →
    <m> RFCOMM protocol support
  <m> RFCOMM protocol support
    <*> RFCOMM tty support
    <y> RFCOMM tty support
    <m> BNEP protocol support
  <m> BNEP protocol support
    <*> Multicast filter support
    <y> Multicast filter support
    <*> Protocol filter support
    <y> Protocol filter support
    <m> HIDP protocol support
  <m> HIDP protocol support
}}
</console>
I find no difference in choosing built-in modules vs. loading modules with the exception that someday you may wish to use out-of-tree drivers directly from wireless.kernel.org.  Just adding all the modules guarantees you can do anything bluetooth in the future, not worth worrying about saving a tiny bit of space.
I find no difference in choosing built-in modules vs. loading modules with the exception that someday you may wish to use out-of-tree drivers directly from wireless.kernel.org.  Just adding all the modules guarantees you can do anything bluetooth in the future, not worth worrying about saving a tiny bit of space.


Also be sure and select your bluetooth device driver:
Also be sure and select your bluetooth device driver:
<console>
{{kernelop|title=Networking Support|desc=
##i##Networking support →
Bluetooth subsystem support →
##i##  Bluetooth subsystem support →
    Bluetooth device drivers →
##i##    Bluetooth device drivers →
         <m> HCI USB driver
         <m> HCI USB driver
</console>
}}
Make sure you choose at least the HCI USB driver.  Others may be applicable to your setup too, for example, if you have a Broadcom BCM203x device you'll want the driver for that which loads the appropriate firmware.
Make sure you choose at least the HCI USB driver.  Others may be applicable to your setup too, for example, if you have a Broadcom BCM203x device you'll want the driver for that which loads the appropriate firmware.
== Userspace Programs ==
== Userspace Programs ==
There was a big change in the transition from bluez4 to bluez5, namely support for HandsFree Profile/Headset Profile (HFP/HSP) was dropped.  Pulseaudio was supposed to begin supporting those profiles but there was a _____long wait.  However, the wait is over and you can now once again use headsets for Skype, Sip, etc.
There was a big change in the transition from bluez4 to bluez5, namely support for HandsFree Profile/Headset Profile (HFP/HSP) was dropped.  Pulseaudio was supposed to begin supporting those profiles but there was a _____long wait.  However, the wait is over and you can now once again use headsets for Skype, Sip, etc.
If you plan to use headsets you'll want to add use changes to pulseaudio, as the default usage profile in the Funtoo tree does not support headsets.  headset-native and headset-ofono are needed.  One example would be
If you plan to use headsets you'll want to add use changes to pulseaudio, as the default usage profile in the Funtoo tree does not support headsets.  headset-native and headset-ofono are needed.  One example would be
<console>
{{console|body=
echo ">=media-sound/pulseaudio-5.99 headset-native headset-ofono">>/etc/portage/package.use
###i## echo ">=media-sound/pulseaudio-5.99 headset-native headset-ofono" >> /etc/portage/package.use
</console>
}}
A2DP and other protocols work fine in bluez-5 without help from pulseaudio, so if you don't intend to use headsets the above doesn't apply.
A2DP and other protocols work fine in bluez-5 without help from pulseaudio, so if you don't intend to use headsets the above doesn't apply.


Add “bluetooth” to your USE flags in /etc/portage/make.conf
Add “bluetooth” to your USE flags in /etc/portage/make.conf


And then: emerge -aND @world
And then: {{c|emerge -aND @world}}


If you need firmware for your bluetooth receiver be sure and get that too.  Sys-kernel/linux-firmware is always a safe bet to have on hand.
If you need firmware for your bluetooth receiver be sure and get that too.  {{c|Sys-kernel/linux-firmware}} is always a safe bet to have on hand.


Unless you prefer controlling your devices at the command line you'll need either Blueman or Gnome-bluetooth, handy GUI applets, just click on the device you want to control.
Unless you prefer controlling your devices at the command line you'll need either Blueman or Gnome-bluetooth, handy GUI applets, just click on the device you want to control.


You'll want to add bluetooth to your startup:
You'll want to add bluetooth to your startup:
<console>
{{console|body=
# rc-update add bluetooth default
###i## rc-update add bluetooth default
</console>
}}


== Usage ==
== Usage ==
While it's rumored that some high-profile Funtoo users refuse to even run X server, for the rest of us a handy GUI can be nice.  However, be aware that all operations can be done from the command line as well.
While it's rumored that some high-profile Funtoo users refuse to even run an X server, for the rest of us a handy GUI can be nice.  However, be aware that all operations can be done from the command line as well.


Pair up your devices, you're ready to go!  With either Blueman or Gnome-bluetooth it's intuitive, they'll steer you in the right direction.  There's a ton of info on the web if for some reason you wish to use the command line rather than a GUI.
Pair up your devices, you're ready to go!  With either Blueman or Gnome-bluetooth it's intuitive, they'll steer you in the right direction.  There's a ton of info on the web if for some reason you wish to use the command line rather than a GUI.
Line 50: Line 48:
{{fancynote|Some of the following requires installation of net-wireless/rfkill, a handy thing to have anyway}}
{{fancynote|Some of the following requires installation of net-wireless/rfkill, a handy thing to have anyway}}
Bluez-5.x starts with your bluetooth device (receiver) powered off.  For those that would like their bluetooth active on machine start, the following code passing around the web added to /etc/udev/rules.d/10-local.rules is purported to work:
Bluez-5.x starts with your bluetooth device (receiver) powered off.  For those that would like their bluetooth active on machine start, the following code passing around the web added to /etc/udev/rules.d/10-local.rules is purported to work:
<console>
{{console|body=
##i###/etc/udev/rules.d/10-local.rules
###i## /etc/udev/rules.d/10-local.rules
##i### Set bluetooth power up
###i## Set bluetooth power up
##i##ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"
###i## ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"
</console>
}}
Those generic Debian-based instructions do not work for me at all with Bluez5.x in Funtoo.  It starts with rfkill bluetooth soft blocked and hci down.  If you want it that way, you're good to go.  If you want bluetooth enabled on start what does work for me is this:
Those generic Debian-based instructions do not work for me at all with Bluez5.x in Funtoo.  It starts with {{c|rfkill bluetooth}} soft blocked and hci down.  If you want it that way, you're good to go.  If you want bluetooth enabled on start what does work for me is this:
<console>
{{console|body=
##i###/etc/local.d/*.start
###i## /etc/local.d/*.start
##i##rfkill unblock bluetooth
###i## rfkill unblock bluetooth
##i### you may need a sleep command here, I just put it further down the list after other things
###i## You may need a sleep command here, I just put it further down the list after other things
##i##/usr/bin/hciconfig hci0 up
###i## /usr/bin/hciconfig hci0 up
</console>
}}
 
Your bluetooth device will be physically powered down (no electricity even) when {{c|rfkill}} blocks it.  Most desktop environments, Gnome, KDE, etc. have some way to assign a hotkey to a command.  However, these commands are limited to the unprivileged user.  Since {{c|rfkill}} must be run by root I use the following method.
Your bluetooth device will be physically powered down (no electricity even) when rfkill blocks it.  Most desktop environments, Gnome, KDE, etc. have some way to assign a hotkey to a command.  However, these commands are limited to the unprivileged user.  Since rfkill must be run by root I use the following method.


First, we need toggle action, so one hotkey can turn  bluetooth either off or on.  The following code accomplishes that.
First, we need toggle action, so one hotkey can turn  bluetooth either off or on.  The following code accomplishes that.
I have a /home/<username>/bin directory with many “helper” programs.  In there, create a file owned by root, with chmod 744 permissions called bluetooth.
I have a {{c|/home/<username>/bin}} directory with many “helper” programs.  In there, create a file owned by root, with chmod 744 permissions called bluetooth.
<console>
{{console|body=
##i##$ cd ~
$##bl## cd ~
##i##$ mkdir bin
$##bl## mkdir bin
##i##$ cd bin
$##bl## cd bin
##i##$ touch bluetooth
$##bl## touch bluetooth
##i##$ sudo chown root: bluetooth
$##bl## sudo chown root: bluetooth
##i##$ sudo chmod 744 bluetooth
$##bl## sudo chmod 744 bluetooth
</console>
}}
Paste the following code into the file with your favorite editor, taking care to change the device name as noted.
Paste the following code into the file with your favorite editor, taking care to change the device name as noted.
<pre>
{{file|name=~/bin/bluetooth|lang=bash|desc=|body=
#/home/<username>/bin/bluetooth
#/home/<username>/bin/bluetooth
#keyboard shortcut set to <your choice>, toggles bluetooth on & off
#keyboard shortcut set to <your choice>, toggles bluetooth on & off
Line 102: Line 99:
# Display the desired text
# Display the desired text
echo "$BLUETOOTH_STRING" | aosd_cat -n "Georgia Italic 120" -u 1000 -o 200 -R $DISPLAY_COLOR -S black -f 0 -e 4 -p 3 -x 300
echo "$BLUETOOTH_STRING" | aosd_cat -n "Georgia Italic 120" -u 1000 -o 200 -R $DISPLAY_COLOR -S black -f 0 -e 4 -p 3 -x 300
</pre>
}}
As you can see, I also have a display that prints huge colored letters across my screen telling bluetooth status for a few seconds as I enable/disable it.  To have the display you must install x11-libs/libaosd with USE=pango, it's disabled by default.  That's it, the code in the bluetooth program shows how to use this handy library, you can tweak font size, etc. to your liking.
As you can see, I also have a display that prints huge colored letters across my screen telling bluetooth status for a few seconds as I enable/disable it.  To have the display you must install {{c|x11-libs/libaosd}} with USE={{c|pango}}, it's disabled by default.  That's it, the code in the bluetooth program shows how to use this handy library, you can tweak font size, etc. to your liking.


This one-liner will list out the available rfkill named devices on your computer:
This one-liner will list out the available {{c|rfkill}} named devices on your computer:
<console>
{{console|body=
for file in /sys/class/rfkill/* ; do echo "$(cat ${file}/name)"; done
###i## for file in /sys/class/rfkill/* ; do echo "$(cat ${file}/name)"; done
</console>
}}
You may have to snoop around a bit in /sys to find what you're looking for.  The name of your device may be something as simple as hci0.  I actually use /sys/devices/platform/hp-wmi/rfkill/* on my system, but this generic method should work for you.  A static directory usually doesn't work, it's often different on every startup, hence the search code.
You may have to snoop around a bit in {{c|/sys}} to find what you're looking for.  The name of your device may be something as simple as {{c|hci0}}.  I actually use {{c|/sys/devices/platform/hp-wmi/rfkill/*}} on my system, but this generic method should work for you.  A static directory usually doesn't work, it's often different on every startup, hence the search code.


Since this program is owned by root, and in fact, rfkill itself must be run as root, simply put the following line in your sudoers file:
Since this program is owned by root, and in fact, {{c|rfkill}} itself must be run as root, simply put the following line in your sudoers file using the {{c|visudo}} command:
<console>
{{file|name=/etc/sudoers|desc=Edit only with {{c|visudo}}|body=
##i##<username> ALL = NOPASSWD: /home/<username>/bin/bluetooth
...
</console>
<your username> ALL = NOPASSWD: /home/<username>/bin/bluetooth
...
}}
Now just add the following command to your hotkey assignment, and you can toggle bluetooth on & off to your heart's content:
Now just add the following command to your hotkey assignment, and you can toggle bluetooth on & off to your heart's content:
<console>
{{console|body=
##i##sudo /home/<username>/bin/bluetooth
$##bl## sudo /home/<username>/bin/bluetooth
</console>
}}


== Yet Another Trick ==
== Yet Another Trick ==
Another handy thing that can be done.  I have 2 computers at my desk, 1 is rarely used and somewhat underpowered.  I sometimes use it though to talk on voip, leaving my main machine free to compile, restart, whatever.
Suppose that I have two computers at my desk, one is rarely used and somewhat underpowered.  I sometimes use it, though, to talk on voip, leaving my main machine free to compile, restart, whatever.


The problem: I wish to use the same headsets on both computers.  In practice, this is a bit of a hassle, because you must pair the headsets with only one machine, so as I switch back and forth, I have to change the pairing.  Not the end of the world, but we can end that hassle.
The problem: I wish to use the same headsets on both computers.  In practice, this is a bit of a hassle, because you must pair the headsets with only one machine, so as I switch back and forth, I have to change the pairing.  Not the end of the world, but we can end that hassle.


{{fancynote|Some newer headsets can be paired to as many as 3 different receivers, great if you have them}}
{{fancynote|Some newer headsets can be paired to as many as 3 different receivers, great...if you have them}}
The first task is to acquire the bdaddr program.  It's on the Backtrack Linux distros, you can probably find it out there in cyberspace somewhere, but it gets confusing on a search because bluez uses the bdaddr abbreviation a lot, creating a lot of noise in your search.
The first task is to acquire the {{c|bdaddr}} program.  It's on the Backtrack Linux distros, so you can probably find it out there in cyberspace somewhere, but it gets confusing on a search because bluez uses the {{c|bdaddr}} abbreviation a lot, creating a lot of noise in your search.
I just put it in /usr/bin.
I just put it in {{c|/usr/bin}}.


To accomplish this, one machine must be the “Master Record” and the other machine pretends to be that machine with pairing.  Not as complicated as it sounds.
To accomplish this, one machine must be the “Master Record” and the other machine pretends to be that machine with pairing.  Not as complicated as it sounds.


Now pair all of your devices on the “Master Record” machine.  The secret link codes are stored at (shhhh!) /var/lib/bluetooth in a directory named with your receivers bluetooth address, let's say AA:AA:AA:AA:AA:AA.  After this is done you are ready to start on the Pretender machine.  It will fool bluez into thinking that it's bluetooth address is AA:AA:AA:AA:AA:AA, even though it has a different address. Copy the AA:AA:AA:AA:AA:AA directory from /var/lib/bluetooth on the “Master Record” machine to /var/lib/bluetooth on the “Pretender”.  The Pretender will now have two directories in /var/lib/bluetooth,  AA:AA:AA:AA:AA:AA and it's own receiver's address directory.  (Unless you have more than 1 receiver, but let's keep it simple).
Now pair all of your devices on the “Master Record” machine.  The secret link codes are stored at (shhhh!) {{c|/var/lib/bluetooth}} in a directory named with your receivers bluetooth address, let's say {{c|AA:AA:AA:AA:AA:AA}}.  After this is done you are ready to start on the Pretender machine.  It will fool bluez into thinking that it's bluetooth address is {{c|AA:AA:AA:AA:AA:AA}}, even though it has a different address. Copy the {{c|AA:AA:AA:AA:AA:AA}} directory from {{c|/var/lib/bluetooth}} on the “Master Record” machine to {{c|/var/lib/bluetooth}} on the “Pretender”.  The Pretender will now have two directories in /var/lib/bluetooth,  {{c|AA:AA:AA:AA:AA:AA}} and it's own receiver's address directory.  (Unless you have more than 1 receiver, but let's keep it simple).


Then simply modify the code in /home/<username>/bin/bluetooth, only the “turn on” section is shown below, because that's all we are changing:
Then simply modify the code in {{c|/home/<username>/bin/bluetooth}}, only the “turn on” section is shown below, because that's all we are changing:
<console>
{{file|name=~/bin/bluetooth|lang=bash|body=
#/home/<username>/bin/bluetooth (partial)
...   
...  else
else
      rfkill unblock bluetooth
rfkill unblock bluetooth
##i### add these 4 lines
### add these 4 lines
##i##        sleep 2
sleep 2
##i##        /usr/bin/bdaddr -i hci0 AA:AA:AA:AA:AA:AA  2&>1>/dev/null #of course, you must change this to "Master Record's" receiver address
/usr/bin/bdaddr -i hci0 AA:AA:AA:AA:AA:AA  2&>1>/dev/null #of course, you must change this to "Master Record's" receiver address
##i##        /usr/sbin/hciconfig hci0 reset
/usr/sbin/hciconfig hci0 reset
##i##        /etc/init.d/bluetooth restart
/etc/init.d/bluetooth restart
##i### end of addition
### end of addition
BLUETOOTH_STRING="  Bluetooth powered on"
BLUETOOTH_STRING="  Bluetooth powered on"
DISPLAY_COLOR="blue"   ...
DISPLAY_COLOR="blue"
</console>
...
}}
And that's it!  Now both machines will use the same headsets and you won't constantly have to re-pair.  When the Pretender bluetooth is toggled on it has the other machines bluetooth address for it's receiver.  Note that I always start my bluetooth powered off, so it always starts in pretend mode, if you start with yours powered on it won't spoof the other address until you toggle it off & then on unless you add the above code to your /etc/local.d/*.start file as well.
And that's it!  Now both machines will use the same headsets and you won't constantly have to re-pair.  When the Pretender bluetooth is toggled on it has the other machines bluetooth address for it's receiver.  Note that I always start my bluetooth powered off, so it always starts in pretend mode, if you start with yours powered on it won't spoof the other address until you toggle it off & then on unless you add the above code to your /etc/local.d/*.start file as well.



Latest revision as of 17:09, June 24, 2015

Kernel Support

You must have bluetooth support in your kernel if you are going to use bluetooth. Enable the following in your kernel config: Under Networking Support:

Bluetooth subsystem support →
    <m> RFCOMM protocol support
    <*> RFCOMM tty support
    <m> BNEP protocol support
    <*> Multicast filter support
    <*> Protocol filter support
    <m> HIDP protocol support

I find no difference in choosing built-in modules vs. loading modules with the exception that someday you may wish to use out-of-tree drivers directly from wireless.kernel.org. Just adding all the modules guarantees you can do anything bluetooth in the future, not worth worrying about saving a tiny bit of space.

Also be sure and select your bluetooth device driver: Under Networking Support:

Bluetooth subsystem support →
    Bluetooth device drivers →
        <m> HCI USB driver

Make sure you choose at least the HCI USB driver. Others may be applicable to your setup too, for example, if you have a Broadcom BCM203x device you'll want the driver for that which loads the appropriate firmware.

Userspace Programs

There was a big change in the transition from bluez4 to bluez5, namely support for HandsFree Profile/Headset Profile (HFP/HSP) was dropped. Pulseaudio was supposed to begin supporting those profiles but there was a _____long wait. However, the wait is over and you can now once again use headsets for Skype, Sip, etc. If you plan to use headsets you'll want to add use changes to pulseaudio, as the default usage profile in the Funtoo tree does not support headsets. headset-native and headset-ofono are needed. One example would be

root # echo ">=media-sound/pulseaudio-5.99 headset-native headset-ofono" >> /etc/portage/package.use

A2DP and other protocols work fine in bluez-5 without help from pulseaudio, so if you don't intend to use headsets the above doesn't apply.

Add “bluetooth” to your USE flags in /etc/portage/make.conf

And then: emerge -aND @world

If you need firmware for your bluetooth receiver be sure and get that too. Sys-kernel/linux-firmware is always a safe bet to have on hand.

Unless you prefer controlling your devices at the command line you'll need either Blueman or Gnome-bluetooth, handy GUI applets, just click on the device you want to control.

You'll want to add bluetooth to your startup:

root # rc-update add bluetooth default

Usage

While it's rumored that some high-profile Funtoo users refuse to even run an X server, for the rest of us a handy GUI can be nice. However, be aware that all operations can be done from the command line as well.

Pair up your devices, you're ready to go! With either Blueman or Gnome-bluetooth it's intuitive, they'll steer you in the right direction. There's a ton of info on the web if for some reason you wish to use the command line rather than a GUI.

Custom Tips

   Note

Some of the following requires installation of net-wireless/rfkill, a handy thing to have anyway

Bluez-5.x starts with your bluetooth device (receiver) powered off. For those that would like their bluetooth active on machine start, the following code passing around the web added to /etc/udev/rules.d/10-local.rules is purported to work:

root # /etc/udev/rules.d/10-local.rules
root # Set bluetooth power up
root # ACTION=="add", KERNEL=="hci0", RUN+="/usr/bin/hciconfig hci0 up"

Those generic Debian-based instructions do not work for me at all with Bluez5.x in Funtoo. It starts with rfkill bluetooth soft blocked and hci down. If you want it that way, you're good to go. If you want bluetooth enabled on start what does work for me is this:

root # /etc/local.d/*.start
root # rfkill unblock bluetooth
root # You may need a sleep command here, I just put it further down the list after other things
root # /usr/bin/hciconfig hci0 up

Your bluetooth device will be physically powered down (no electricity even) when rfkill blocks it. Most desktop environments, Gnome, KDE, etc. have some way to assign a hotkey to a command. However, these commands are limited to the unprivileged user. Since rfkill must be run by root I use the following method.

First, we need toggle action, so one hotkey can turn bluetooth either off or on. The following code accomplishes that. I have a /home/<username>/bin directory with many “helper” programs. In there, create a file owned by root, with chmod 744 permissions called bluetooth.

user $ cd ~
user $ mkdir bin
user $ cd bin
user $ touch bluetooth
user $ sudo chown root: bluetooth
user $ sudo chmod 744 bluetooth

Paste the following code into the file with your favorite editor, taking care to change the device name as noted.

   ~/bin/bluetooth (bash source code)
#/home/<username>/bin/bluetooth
#keyboard shortcut set to <your choice>, toggles bluetooth on & off
#this file must be added to sudoers ;)

# we need to find which rfkill applies to bluetooth, there can be one for wifi, one for bluetooth, I have a 3rd , don't even know what it is

for file in /sys/class/rfkill/*
do
	if [ "$(cat ${file}/name)" = "hp-bluetooth" ]; then   ### you'll have to snoop around in there, rename to what your device is called
		BT_STATE=$(cat ${file}/state)
	fi
done
if [[ ${BT_STATE} -eq 1 ]]; then
	rfkill block bluetooth
	BLUETOOTH_STRING="  Bluetooth powered off"
	DISPLAY_COLOR="red"
else
        rfkill unblock bluetooth
	BLUETOOTH_STRING="  Bluetooth powered on"
	DISPLAY_COLOR="blue"
fi
# Clean up any running aosd_cat processes
killall aosd_cat &> /dev/null
# Display the desired text
echo "$BLUETOOTH_STRING"

As you can see, I also have a display that prints huge colored letters across my screen telling bluetooth status for a few seconds as I enable/disable it. To have the display you must install x11-libs/libaosd with USE=pango, it's disabled by default. That's it, the code in the bluetooth program shows how to use this handy library, you can tweak font size, etc. to your liking.

This one-liner will list out the available rfkill named devices on your computer:

root # for file in /sys/class/rfkill/* ; do echo "$(cat ${file}/name)"; done

You may have to snoop around a bit in /sys to find what you're looking for. The name of your device may be something as simple as hci0. I actually use /sys/devices/platform/hp-wmi/rfkill/* on my system, but this generic method should work for you. A static directory usually doesn't work, it's often different on every startup, hence the search code.

Since this program is owned by root, and in fact, rfkill itself must be run as root, simply put the following line in your sudoers file using the visudo command:

   /etc/sudoers - Edit only with visudo
...
<your username> ALL = NOPASSWD: /home/<username>/bin/bluetooth
...

Now just add the following command to your hotkey assignment, and you can toggle bluetooth on & off to your heart's content:

user $ sudo /home/<username>/bin/bluetooth

Yet Another Trick

Suppose that I have two computers at my desk, one is rarely used and somewhat underpowered. I sometimes use it, though, to talk on voip, leaving my main machine free to compile, restart, whatever.

The problem: I wish to use the same headsets on both computers. In practice, this is a bit of a hassle, because you must pair the headsets with only one machine, so as I switch back and forth, I have to change the pairing. Not the end of the world, but we can end that hassle.

   Note

Some newer headsets can be paired to as many as 3 different receivers, great...if you have them

The first task is to acquire the bdaddr program. It's on the Backtrack Linux distros, so you can probably find it out there in cyberspace somewhere, but it gets confusing on a search because bluez uses the bdaddr abbreviation a lot, creating a lot of noise in your search. I just put it in /usr/bin.

To accomplish this, one machine must be the “Master Record” and the other machine pretends to be that machine with pairing. Not as complicated as it sounds.

Now pair all of your devices on the “Master Record” machine. The secret link codes are stored at (shhhh!) /var/lib/bluetooth in a directory named with your receivers bluetooth address, let's say AA:AA:AA:AA:AA:AA. After this is done you are ready to start on the Pretender machine. It will fool bluez into thinking that it's bluetooth address is AA:AA:AA:AA:AA:AA, even though it has a different address. Copy the AA:AA:AA:AA:AA:AA directory from /var/lib/bluetooth on the “Master Record” machine to /var/lib/bluetooth on the “Pretender”. The Pretender will now have two directories in /var/lib/bluetooth, AA:AA:AA:AA:AA:AA and it's own receiver's address directory. (Unless you have more than 1 receiver, but let's keep it simple).

Then simply modify the code in /home/<username>/bin/bluetooth, only the “turn on” section is shown below, because that's all we are changing:

   ~/bin/bluetooth (bash source code)
...   
else
rfkill unblock bluetooth
### add these 4 lines
sleep 2
/usr/bin/bdaddr -i hci0 AA:AA:AA:AA:AA:AA  2&>1>/dev/null #of course, you must change this to "Master Record's" receiver address
/usr/sbin/hciconfig hci0 reset
/etc/init.d/bluetooth restart
### end of addition
BLUETOOTH_STRING="  Bluetooth powered on"
DISPLAY_COLOR="blue"
...

And that's it! Now both machines will use the same headsets and you won't constantly have to re-pair. When the Pretender bluetooth is toggled on it has the other machines bluetooth address for it's receiver. Note that I always start my bluetooth powered off, so it always starts in pretend mode, if you start with yours powered on it won't spoof the other address until you toggle it off & then on unless you add the above code to your /etc/local.d/*.start file as well.

The only caveat is I'm not sure what would ever happen if I had both bluetooth receivers on at the same time and turned on a headset. But far short of a nuclear meltdown I'm sure, I suspect one machine would grab the headset before the other? Anyhow, with hotkey controlled bluetooth it's never been an issue.