The Gluster Blog

Gluster blog stories provide high-level spotlights on our users all over the world

Configuring a bluetooth keyboard system-wide from the command line


Recently I bought a new keyboard, which I intend to use when my laptop is placed in its docking station. There are two external monitors connected, making the display of the laptop rather useless (only two outputs are supported at the same time). In normal circumstances the laptop lid will be closed, so the keyboard is not accessible.

My new keyboard is a Logitech K760 and is connected through bluetooth. Pairing with help from the the XFCE/GNOME tools is easy enough, but this causes the keyboard to be available after login only. That is not very practical. After boot, I have to login through GDM and prefer to not need to use the keyboard of the laptop itself. For this, I needed to figure out how to make the bluetooth keyboard available on system level, and not per user. Descriptions on how to do this seem to be very sparse, and mostly depend on other distributions than RHEL or Fedora. I prefer to use standard tools as much as possible, adding custom scripts for these things makes it more difficult to move configurations between systems. Furthermore the keyboard can be paired to multiple (3) systems at the same time, the F1-3 keys can be used to select a system, similar to a KVM switch.

The most minimal and easy to use tools I could find, are included in the test suite of the BlueZ package. Unfortunately, these are not packaged for all I know, so installing or using these scripts is impractical. But, as these scripts are only needed for pairing once, I think they are a nice solution anyway. The advantage over other options, is that the scripts are updated with the bluez software itself, which causes the same scripts (well, different versions) to work regardless of changes to the bluez API.

Getting the scripts from the bluez test-suite that matches the available version in Fedora or RHEL, can be done with yumdownloader from the yum-utils package (all as normal unprivileged user):

$ yumdownloader --source bluez

Extract the source RPM by installing it:

$ rpm -ivh bluez-4.66-1.el6.src.rpm

Extract the sources which include the test-suite:

$ rpmbuild --nodeps -bp ~/rpmbuild/SPECS/bluez.spec

Note that the --nodeps parameter is used. The -bp argument causes all BuildRequires dependencies to be checked, most of them are not needed for the test-suite scripts.

After extracting the sources successfully, the test-suite is located under the BUILD directory:

$ cd ~/rpmbuild/BUILD/bluez-4.66/test/

Everything is now ready for pairing, so put the keyboard in discovery mode and scan for it:

$ sudo hcitool scan
Scanning ...
00:1F:20:3C:A2:03 Logitech K760

The keyboard will need ao authenthicate to the system. simple-agent can be used for that, like this:

$ sudo ./simple-agent hci0 00:1F:20:3C:A2:03
DisplayPasskey (/org/bluez/2117/hci0/dev_00_1F_20_3C_A2_03, 716635)
New device (/org/bluez/2117/hci0/dev_00_1F_20_3C_A2_03)

The simple-agent script will wait for a response of the keyboard, press the PIN that is shown (here 716635) and hit enter.

Obviously the keyboard is a device that supports the input-class. Hence test-input can be used to setup the connection:

$ sudo ./test-input connect 00:1F:20:3C:A2:03

If this worked without error message, mark the keyboard as a trusted device. This will make it possible for the keyboard to connect to the system without requesting for approval:

$ sudo ./test-device trusted 00:1F:20:3C:A2:03 yes

After these steps, verify that the keyboard connects automatically after a reboot. This worked for me on my RHEL-6 laptop, and a cubieboard installed with Fedora 18 ARM.


  • 06 Dec 2020
    Looking back at 2020 – with g...

    2020 has not been a year we would have been able to predict. With a worldwide pandemic and lives thrown out of gear, as we head into 2021, we are thankful that our community and project continued to receive new developers, users and make small gains. For that and a...

    Read more
  • 27 Apr 2020
    Update from the team

    It has been a while since we provided an update to the Gluster community. Across the world various nations, states and localities have put together sets of guidelines around shelter-in-place and quarantine. We request our community members to stay safe, to care for their loved ones, to continue to be...

    Read more
  • 03 Feb 2020
    Building a longer term focus for Gl...

    The initial rounds of conversation around the planning of content for release 8 has helped the project identify one key thing – the need to stagger out features and enhancements over multiple releases. Thus, while release 8 is unlikely to be feature heavy as previous releases, it will be the...

    Read more