As one of the first, non-Mint distros to feature Cinnamon as its main desktop environment, Cinnarch was a very interesting product when it was first announced. Based on the great Arch Linux, Cinnarch offered a rock solid, rolling base with a lot of customisation features, and a selection of decent pre-installed desktop applications on top of the Cinnamon desktop environment. It was in development for just over half a year before the team decided to change the name and focus of Cinnarch, and release to the world Antergos.

Antergos now uses GNOME as it’s default desktop environment, which is really the main difference between this and Cinnarch – hence the name change. It actually offers a number of desktops though during installation, and joining Cinnamon and GNOME are XFCE and the relatively unknown RazorQT, another fast and lightweight desktop. The graphical installer itself actually works now, where as in Cinnarch you could only use the command line version. The graphical one is very nice, and while they claim it was of their own creation, at the very least the interface heavily borrows from the Ubuntu installer. It’s quite fast, although the command line version can be a little quicker. That’s still pretty great as well, straightforward and easy to understand.

The GNOME desktop is your standard version, albeit with Antergos colouring, while the Cinnarch offering maintains the top panel orientation used in Cinnarch. This is of course customisable, especially as this is also the very latest version of Cinnamon that also comes with Linux Mint 15. All the packages are bang up-to-date, which is mostly down to the rolling Arch Linux base that it runs off. To access these packages, the simplistic PacmanXG graphical frontend to pacman is available by default, and allows you to search via keyword or category for other packages you may want like any good graphical package manager. There is no update function though, so you’ll need to enter the terminal to update pacman and the other packages manually.

Actually using the distro has somewhat improved over the development versions, and not just with the partitioning and installation issues that used to pop up. The desktop itself is a lot smoother, and the settings and such seem to work properly. There were some weird graphical glitches we encountered though, such as disappearing mouse cursors and temperamental wallpapers affecting the look of the Cinnamon menu. Also, if you’re using the Cinnamon desktop, a phantom GNOME option pops-up on the login screen that breaks the x server until you reboot.

In general we don’t think Antergos is quite ready yet. While it’s certainly an attractive prospect to have Arch pre-built with a decent selection of default software and a nice choice of desktop environments, it doesn’t quite seem worth the limitations yet, and doesn’t really add that much over taking Arch and installing your own desktop yourself. It’s definitely better than Cinnarch was though, and we’re very interested to see how the distro will develop over the year or so.

Verdict

3/5

Antergos has come on a fair bit since we last saw it as Cinnarch, however it’s still not the most stable of distros. With graphical glitches and weird hardware detection, we’d prefer to build up Arch from scratch. However, with a good selection of install options, it’s a shortcut to a decent Arch desktop.

Follow @LinuxUserMag

Zorin OS, the Windows look-a-like distro, is quite popular among people who need a distro for Windows users who are either trying to convert, or have to use Linux but don’t wish to. The Zorin team have been making some aesthetic changes to the distro, as well as some software upgrades, and the release candidate for Zorin OS 7 is out now.

Zorin OS 7 will come with Linux Kernel 3.8, and a couple of app replacements such as Pidgin for IM and Geary Mail for emails. The desktop environment has received as a face-lift to go with the style of the new Zorin OS logo as well.

Zorin OS 7 RC can be downloaded from the Zorin OS website, with the final version expected to launch soon.

Follow @LinuxUserMag

Google’s I/O 2013 keynote last week was very exciting, and while there was no specific Android OS update, there was enough new stuff to cram into the two hour conference that we didn’t specifically need it. During the talk, Google talked about upcoming features being added to Chrome, the browser built on top of open source Chromium, including an always-listening browser and better interaction.

Privacy concerns aside about a browser that can always “hear” what you’re saying, the new conversation element of the searches has just been added to Google Chrome 27. You can access this from a new microphone button that shows up on the Google homepage, and remembers the searches you type so you can make a string of related questions. A classic example being given is asking a question about an individual, and then not using his name in the next search. E.g., “how old is Linus Torvalds” and “where does he live”.

The update also improves page load speeds by 5%, and a number of minor bug fixes and upgrades. These changes haven’t made their way to Chromium yet, but some should do soon.

Follow @LinuxUserMag

The Pi Camera has been a long time coming, and if you’re still looking to get one of the highly sought-after Raspberry Pi cameras, you may want to check out the Road Trip competition being held by Element14.

The competition is open to anyone with a Raspberry Pi, and has you testing out the Pi Camera by submitting photos in four categories:

Your workshop / den

Your Pi project

People and Pets

Outdoors

The winners will win a whole host of brand new Raspberry Pi accessories throughout the year, and help test and promote the Pi Camera in the process.

Visit the Element14 website now to enter the competition, and get snapping today.

Follow @LinuxUserMag

It’s been another year since the last Mageia release, and it’s successor is finally here. Improving on the already stellar Mageia 2, Mageia 3 contains all the standard package and kernel updates, along with the inclusion of Steam for Linux and other applications.

The distro was originally delayed due to various problems with installation, from hardware detection issues to booting problems depending on how and where you were installing it. The issues have apparently been fixed, with a list of bug fixes supplied on the release notes for Mageia 3.

You can download the final release of Mageia 3 from the website, and you can also read our review of the release candidate in an upcoming issue of Linux User & Developer magazine.

Follow @LinuxUserMag

Like the last Linux Mint release, Linux Mint 15 is quick on it’s feet after Ubuntu, with the release candidate out a few weeks after Canonical’s distro hit. While Ubuntu 13.04 itself didn’t really receive any major updates, Linux Mint 15 is bringing with it a whole host of new features and upgrades to the core system and its preferred desktop environments.

The MDM display manager now has three different main login applications, including one that’s written in HTML 5 for a new way to create animated and interactive themes. Cinnamon has a new screensaver mode which allows you to write a lock screen message for colleagues, and a few desktop widgets as well. MATE has received a small overhaul, updating a lot of its core, and there have been other updates to the software manager and driver manager.

The release candidate can be found on the Linux Mint website, and the final version will likely be a week or so away.

Follow @LinuxUserMag

Firefox’s rapid development has pushed the browser over version 20, with 21 out now. The new version comes with built-in Facebook messenger for Firefox, and new social providers such as Cliqz, Mixi and msnNow. These social additions are part of what Mozilla sees relevant to the current usage of the internet.

Firefox for Android now comes with Charis and Open Sans, open source fonts that they think will make the web “more beautiful and easier to read on a user’s small screen” according to a press release. There’s also HTML 5 compatibility improvement, done in conjunction with HTML5test.com.

You can update your browsers now on your systems and Android devices if you haven’t already.

Follow @LinuxUserMag

The Raspberry Pi’s camera has been talked about for a long time it seems, but it’s now finally able to be purchased for use with your Raspberry Pi. The Raspberry Pi foundation explained in their announcement post that the release itself was delayed for a further month while software was sorted out for the device.

The Raspberry Pi foundation have also release a video on how you can go about setting up your camera.

There’s also some step-by-step instructions on the Pi website. You can buy the Pi Camera board from Element14 now for £16.56 (~$25), and the RS Components website will be updated shortly with a way to purchase it.

Follow @LinuxUserMag

Linus Torvalds has announced the first several 3.9 kernel release candidates, following the closing of the 3.9 ‘merge window’ (period of time during which disruptive changes to the kernel and new features are merged). Merge windows are typically up to two weeks in duration (and seldom longer), though Linus has gone to great pains over the past few years to push developers not to post patches for inclusion at the very end of the window. Features merged into the kernel should instead have received heavy testing in the linux-next kernel and elsewhere, be largely complete, and posted for inclusion as early as possible during the two-week window of frantic development for a given release cycle. This is the theory, at any rate.

In his mail simultaneously closing the merge window, and also announcing 3.9-rc1, Linus said, “I don’t know if it’s just me, but this merge window had more ‘Uhhuh’ moments than I’m used to. I stopped merging a couple of times, because we had bugs that looked really scary, but thankfully each time people were on them like paparazzi on Justin Bieber.” Those features that made it into 3.9 include support for Synopsys’s 32-bit ‘ARC’ architecture (following a third posting of reviewed patches from Vineet Gupta), which is designed for use in embedded and DSP applications, particularly those wherein the ability to extend the CPU pipeline with custom instructions is beneficial (though this author notes that butchering a CPU pipeline comes with its own hidden costs and so isn’t something recommended for non- embedded applications).

Another very interesting new feature in the 3.9 kernel is support for Intel’s ‘PowerClamp’ driver. PowerClamp aims to constrain the maximum amount of power used by the system by forcing the CPUs to enter an idle state for a certain percentage of their operating time. At first glance, this may seem to be less than useless. After all, having paid good money for a powerful modern CPU (with multiple cores), most users expect to get all the oomph they can out of it. There are some users, however, where this desire is balanced by overall power constraints – in particular in data centres where there is a hard limit (often 10 or 15kW) of available power for a given rack of server equipment. Exceeding the power available to a rack can cause all of the servers in it to shut down, which is generally not what data centre users want. Google and others have encountered such problems over the past few years, and have used their own custom solutions to (presumably) good effect.

PowerClamp helps to generally solve the problem of hard-limits at the rack level by allowing an administrator or software management tool (‘agent’) to configure the system such that it will inject a certain number of idle states onto a given CPU. Typically, the kernel’s idle thread (idle task or idle process) will run only when there is nothing else to do. It calls a special machine instruction that will efficiently transition the processor into a lower power state from which it can be woken when there is work to do (usually through an external interrupt). In the case of PowerClamp, additional kidle_inject threads are created to run at specific times when there is a need to inject additional idle states (over and above the regular idle thread) in order to remain overall idle for the percentage of time configured by the user. Typically, PowerClamp will be used with some higher-level management software that looks to the whole rack and dynamically tunes many different systems for optimal overall power use.

Ongoing development

David Howells announced that “The end is nigh!” for his ongoing UAPI work. UAPI is a near year- long effort by David to clean up the kernel’s internal header files (source code containing definitions and small inline code functions typically included into kernel or application code), splitting out those parts that pertain only to the API (application programming interface) used by non-kernel ‘user space’ applications, such as the Bash shell or Firefox web browser. A typical Linux system includes many such header files within the /usr/include/linux directory. These are installed as part of compiling the kernel, during the ‘make kernel-headers’ stage.

Until now, the process of building user application usable header files involved selective copying of a limited number of kernel headers (most are not intended to be used by application code) and judicious use of special conditionals within those files to ensure the right thing would happen when they were used by non-kernel code. After David’s work, the ‘user- space API’ is more clearly defined and these pieces are separated out into files specifically intended for direct use by non-kernel code. David’s latest email suggests that only a few changes pertaining to video framebuffers remain “now that the SCSI stuff has gone in”.

Miklos Szeredi posted patches implementing a new ‘overlayfs’ file system. Overlay and Union file systems have been a topic of much debate for many years, particularly because they never seem to work quite right. The problem they generally attempt to solve is one of allowing several distinct file systems to be joined together, with the net result being a virtual file system (only existing as a whole at runtime) that contains selective pieces of each of its constituent parts. A typical use case is one of embedded routers or live CDs. Both contain some storage (flash memory or optical media) that is read-only, and some storage (on a RAM disk or a separate piece of storage – a USB stick, another flash etc) that can be written to. A special file system is then used to present what appears to be a selection of the content of both of these underlying stores. As files from the read-only media are modified or deleted, deltas are written to the separate writable storage instead (including special markers that indicate a file has actually been deleted). Unlike other efforts to do overlays, Miklos’s code tries to be as small as possible by generally passing through operations on open files to the underlying file systems as quickly as possible. It will be interesting to see where this goes.

John Stultz (of Linaro) has posted an RFC patch-in-progress that would pull support for Android’s sync driver into the staging tree. Staging is a part of the kernel source tree where experimental and not-quite-baked drivers can sit inside the kernel source while they are being cleaned up. These drivers are available only if specifically configured for use. The sync driver provides a collection of synchronisation primitives (code routines that can be used by other code to ensure operations happen in the correct order) for use with drivers that provide different parts of the graphics pipeline used with the Android SurfaceFlinger compositor.

Anton Vorontsov posted the latest version of a memory control groups (memcg) patch implementing memory-pressure-level event support. With this patch, applications that “want to maintain the interactivity/memory
allocation cost can use the new pressure-level notifications”. What this means is that it is possible for an application to be aware of the overall pressure a system is under for memory. When Linux runs low on available free memory, it will do one of several things. This includes failing new memory allocations, swapping out certain parts of applications to disk, and freeing up internal caches. All of these have a cost in terms of overall system performance (particularly when the system hits a point of swapping large amounts of data out to slow rotational disks and is said to enter a state of ‘thrashing’) that has not historically been easily visible to end software. Now, applications can easily monitor a special event file descriptor within a memory control group and be made aware of ‘low’, ‘medium’ and ‘critical’ levels of memory as well as set specific limits at which a notification will be given. This allows an application to take steps to release unneeded in-memory caches (such as web browser pages) before the system grinds to a crawl.

Follow @LinuxUserMag

Today, we’ll be learning how to use a Raspberry Pi to act as a Bluetooth keyboard, and writing our own program to relay input to the client device. This will provide a useful insight into how a protocol like Bluetooth works, how sockets work, and how data is sent across simple protocols. We’ll also be learning a little bit about binary data and the different forms that it can take.

We’ll be using the latest Raspbian image as the operating system for our Raspberry Pi- based Bluetooth keyboard. The instructions for flashing an image to an SD card can be found on our original tutorial. You’ll only need to go up to the step where you write the image to the SD card. You’ll have to adapt the instructions slightly for using the latest Raspbian image rather than the Debian one. The image we used was‘2012-12-16-wheezy-raspbian.zip’.

There are multiple ways that you can do this tutorial depending on how comfortable you are with working in a console-based environment. For example, our expert did this tutorial over SSH. If you don’t want to do that then you could do it from the console on the Raspberry Pi, or use the LXDE environment, but you’ll need a USB hub because you’ll need three USB devices: a keyboard, mouse and Bluetooth dongle.

Resources

A Raspberry Pi with all necessary peripherals

A USB Bluetooth dongle

A USB hub – if you want to use a keyboard and
mouse at the same time as the Bluetooth dongle

A device to connect the virtual keyboard to – Liam tested it on an Android
smartphone and his Linux computer

PiTooth

Step by step

Step 01

Setting up the Pi

You’ll need to connect a power cable, network cable, the Bluetooth dongle and a USB keyboard. You’ll also need to connect a screen for the initial configuration and can use SSH from then on. Alternatively, you could use a console-based environment on the screen. If you want to use the LXDE environment then you’ll need a screen and mouse. Raspbian will boot and a configuration menu will be displayed. Choose the option to expand the root file system, as we need to install quite a few extra packages. Once you’ve done that, select Finish and then Yes to reboot the device.

Step 02

Logging into the Pi

A message will be displayed with the current IP address of the Pi during the boot process of Raspbian. This will be useful if you are using SSH, which is enabled by default on the latest Raspbian image. Open up a terminal on your Linux computer and type:

ssh pi@[your Pi’s IP address].

Type yes when asked if you want to connect and then enter the password raspberry. Alternatively, simply type the username pi, and password raspberry at the login screen.

Step 03

Installing the required packages

You need to run the following commands to install the required packages:

sudo apt-get update

sudo apt-get install python-gobject bluez bluez-tools bluez-firmware python-bluez python-dev python-pip

sudo pip install evdev

This may take a while to process, especially the second command.

The first command updates the list of packages available. The second command installs the required Bluetooth packages, as well as Python bindings for them. The remaining two packages are needed for installing a Python module called evdev, to capture keyboard input, that isn’t yet in the Raspbian package repositories. Instead, we need to have the Python development package present and use pip (a Python package manager) to compile the evdev module from source and then install it.

Step 04

Disabling the default Bluetooth plug-ins

By now, we’ve installed the Linux Bluetooth stack, BlueZ. By default, it comes with a bunch of services enabled that we don’t need and it will make debugging much more difficult if the need arises. You can see the list of default services using the command:

sudo sdptool browse local

The configuration file we need to edit is /etc/ bluetooth/main.conf. You can open that file in the nano editor using the command sudo nano /etc/bluetooth/main.conf. You need to change the following line:

#DisablePlugins = network,input

to…

DisablePlugins = network,input,audio,pnat,sap,serial

Then save the changes using Ctrl+O, followed by pressing Enter and pressing Ctrl+X. You need to restart the Bluetooth daemon for the changes to take effect. You can do this using:

sudo /etc/init.d/bluetooth restart

You can use

sudo sdptool browse local

to verify that there are no services remaining.

Step 05

Starting the project

It’s about time we got started on some code, so let’s create a project folder. Change directoryto/home/piusingcd /home/pi and make a directory for our project using the command mkdir PiTooth. You can then change into the PiTooth directory and make a project file using the command touch PiTooth.py. Make it executable using the commandchmod +x PiTooth.py.

Open the file in the nano editor and start the file with the line:

#!/usr/bin/python2.7

This tells the shell that it needs to run the using the Python 2.7 interpreter.

You can also add a short comment about what the program does:

#!/usr/bin/python2.7
#
# PiTooth allows the Raspberry Pi to act as a Bluetooth keyboard, and relays
# keypresses from a USB keyboard to a Bluetooth client. Written by Liam Fraser
# for a Linux User & Developer tutorial.
#

Step 06

Downloading necessary files

There are a couple of files that are needed for this project to work. You could create them yourself, but it would involve spending quite a lot of time reading various protocol specifications like our expert had to do to put this tutorial together. It’s outside of the scope of the tutorial. It will become clear what these files are used for shortly.

Save the changes to the file that you’ve made so far and exit nano. Download the required files using the command wget http:// liamfraser.co.uk/lud/PiTooth- Resources.zip.

Unzip the files from the zip archive using the command unzip PiTooth-Resources.zip. Use ls to verify that the new files have appeared. Once you have done this, you can remove the zip file using the command

rm PiTooth-Resources.zip
pi@raspberrypi ~/PiTooth $ ls keymap.py PiTooth.py sdp_record. xml

Step 07

The imports

It’s time to get back to nano. Our first job is to import the modules that we need, and there are quite a lot. We’ve placed a comment next to the non-obvious ones to explain what they are used for. SDP stands for Service Discovery Protocol. It will become clear what SDP and D-Bus are used for shortly.

import os # Used to call external commands
import sys # Used to exit the script
import bluetooth
from bluetooth import *
import dbus # Used to set up the SDP record
import time # Used for pausing the process
import evdev # Used to get input from the keyboard
from evdev import *
import keymap # Used to map evdev input to hid keycodes

Step 08

The Bluetooth class

We’re going to start our Bluetooth class with an initialisation function as usual. Remember that we’re not using a fancy development environment here, so you need to take care to format your code properly. Our expert typically uses four spaces to indent rather than a tab, as spaces are the same in every editor. We’re going to start off by preparing the Bluetooth dongle for use as a Bluetooth keyboard. We’ll do this using the hciconfig command, which is essentially the equivalent of ifconfig for Bluetooth devices.

So, we set the device class, which is a hexadecimal value representing a keyboard. We then set the device name to Raspberry Pi, replacing the space in the name with a backslash. Finally, we make the device discoverable so that other devices can pair with it.

class Bluetooth:
    def __init__(self):
        # Set the device class to a
keyboard and set the name
        os.system(“hciconfig hci0 class 0x002540”)
        os.system(“hciconfig hci0 name Raspberry\ Pi”)
        # Make device discoverable
        os.system(“hciconfig hci0 piscan”)

Step 09

Bluetooth sockets

Bluetooth HID devices use two sockets to communicate: a control socket and an interrupt socket. The control socket is for initiating the connection, sending handshakes and so on. The interrupt socket is used for sending low-latency data, such as input reports containing key presses, or output reports such as vibration feedback if the device were a gamepad. The standard ports for these sockets are 17 for the control socket and 19 for the interrupt socket.

Before we create the sockets, we’re going to declare a couple of constants to hold the port numbers. The constants can be put outside of the initialiser function as they will be the same for every instance of the class. The beginning of the Bluetooth class should now look like this:

class Bluetooth:
    # Define the ports we'll use
    P_CTRL = 17
    P_INTR = 1

Step 10

Create the certificates

We’re back in the initialisation function now. Once we’ve set up our Bluetooth dongle, we need to create a couple of sockets upon which we can accept connections from clients. We also need to bind them to the appropriate ports. L2CAP is simply a type of Bluetooth socket. When binding the sockets to a port, we pass through a tuple with the MAC address of the Bluetooth dongle to bind the socket to, which can be omitted because we only have one, and the port to bind the socket to. Notice that we access the port constants using the class name, rather than prefixing them with self, because the constants are class members rather than instance members.

# Define our two server sockets for communication
self.scontrol = BluetoothSocket(L2CAP)
self.sinterrupt = BluetoothSocket(L2CAP)
# Bind these sockets to a port
self.scontrol.bind((“”, Bluetooth.P_CTRL))
self.sinterrupt.bind((“”, Bluetooth.P_INTR))

Step 11

Using D-Bus

D-Bus is a framework used commonly on Linux that allows communication and remote procedure calls (calling a function in a different program) between different processes. The BlueZ Bluetooth stack exposes a D-Bus interface which allows access to a couple of things that the Python module doesn’t.

We’re going to use D-Bus to advertise a Bluetooth SDP record. SDP stands for Service Discovery Protocol. This record advertises the virtual keyboard and various information about it, such as the structure of the input reports (which are sent when a key is pressed) and also things such as the language of the keyboard. You’ve already downloaded an SDP record that our expert made earlier, as these are really outside of the scope of this tutorial.

We’re enclosing our D-Bus code with a try- except block because it could go wrong, and so it’s useful to include error messages. We start by getting an org.bluez.Manager interface, and the path to the default adaptor. With that, we can get the service interface for that adaptor, which is used for registering SDP records.

        # Set up dbus for advertising the service record
        self.bus = dbus.SystemBus()
        try:
            self.manager = dbus.Interface(self.bus.get_object(“org.bluez”, “/”), “org.bluez.Manager”)
            adapter_path = self.manager.DefaultAdapter()
            self.service = dbus.Interface(self.bus.get_object(“org.bluez”, adapter_path), “org.bluez.Service”)
        except:
            sys.exit(“Could not configure bluetooth. Is bluetoothd started?”)

Step 12

Reading the SDP record

Now that we’ve set up D-Bus, we need to read the contents of the XML file describing the SDP record into a variable. Again, we’re doing this inside a try-except block in case the file is missing. The sys.path[0] variable contains the path to directory containing the script:

        # Read the service record from file
        try:
            fh = open(sys.path[0] + “/sdp_record.xml”, “r”)
        except:
            sys.exit(“Could not open the sdp record. Exiting...”)
        self.service_record = fh.read()
        fh.close()

Step 13

Listening for a connection

The next thing we’ll do is define a listen function, which adds the SDP record we just read to the SDP server, and then waits for a connection from a client device. A client device will connect to the control socket first, and then the interrupt socket. The accept function of a socket returns a socket for that connection and a tuple containing the client’s MAC address followed by the port they connected on. Our expert created a couple of constants to make the code more readable when accessing the values in the tuple.

class Bluetooth:
     HOST = 0 # BT Mac address
     PORT = 1 # Bluetooth Port Number...
     def listen(self):
          # Advertise our service record
          self.service_handle = self. service.AddRecord(self.service_record)
          print “Service record added”
          # Start listening on the server sockets
          self.scontrol.listen(1) # Limit of 1 connection
          self.sinterrupt.listen(1)
          print “Waiting for a connection”
          self.ccontrol, self.cinfo = self.scontrol.accept()
          print “Got a connection on the control channel from “ + self.cinfo[Bluetooth.HOST]
          self.cinterrupt, self.cinfo = self.sinterrupt.accept()
          print “Got a connection on the interrupt channel from “ + self.cinfo[Bluetooth.HOST]

Step 14

Adding the main function

We now have basic code in place that will let us accept connections from devices. It will drop the connections straight away, but that doesn’t matter for now. We’re going to add a main function at the bottom of the file to create an instance of the Bluetooth class and call the listen function to wait for a connection. We’re going to check that the user executing the code has root privileges as part of the main function. Otherwise it’s pointless to continue, as the script won’t do anything.

if __name__ == “__main__”:
     # We can only run as root
     if not os.geteuid() == 0:
          sys.exit(“Only root can run this script”)
     bt = Bluetooth()
     bt.listen()

Step 15

Pairing with the client device

Before we can accept connections from client devices, we need to pair with them. We’re going to describe this process on an Android device. Now, it’s best to advertise the virtual keyboard’s SDP record while we are pairing, so at this point, you’ll need to open up a second shell on the Raspberry Pi. You can either do this by opening up another SSH session, or using Ctrl+Alt+F2 to switch to the next console if you’re using the Pi with a keyboard and screen connected (Ctrl+Alt+F1 will switch you back to the first console).

So, in the first shell, you need to start PiTooth with sudo ./PiTooth. It will print that the service record has been added and that it’s waiting for a connection from a client device. At this point, you need to go to the Bluetooth settings on your client device and make the device discoverable. Now, switch to the second shell. Once you’re there, run the command hcitool scan. This will tell you the MAC address of the device you want to pair with. Once you’ve found this, you need to use the command bluez-simple-agent hci0 [client MAC address].EnteraPIN,and then enter that PIN on your client device. You should now be paired with the Raspberry Pi.

Note that if you ever have to unpair your client device, you can use the command bluez-test-device remove [client MAC address].

Step 16

Testing the code so far

We might as well test the code we have so far while it’s waiting for a connection. Switch back to your other shell and then scroll down to the Raspberry Pi entry on your client device. Select the Connect option. Note that our expert sometimes had to reset the Bluetooth on his client device by turning it off and on again because it got upset when the code simply dropped the connections as soon as it connected. Our output looked like this:

pi@raspberrypi ~/PiTooth $ sudo ./ PiTooth.py
Service record added
Waiting for a connection
Got a connection on the control channel from [Client MAC]
Got a connection on the interrupt channel from [Client MAC]

Step 17

Input reports

It will be useful to learn about input reports before we start coding the Keyboard class. At the top of the page is a table describing an input report from the Bluetooth HID specification. An input report is 9 bytes long, and prefixed with a byte indicating that the remaining bytes are an input report. The first byte containing Report ID is always 0×01, which is the value for a keyboard input report.

It will help to understand a little about binary data. A byte is made up of eight individual bits which have a value of either 1 or 0. A byte can represent a numerical (decimal) value of up to 255. Anything in the form 0×00 is a hexadecimal value. For example, 0×01 is 00000001 in binary, and represents the decimal number 1. The size of a character, for example, the letter A, is also a byte. This knowledge will come in useful shortly when we need to convert between various data types.

The second byte indicates which modifier keys (Ctrl, Alt, Shift and the Windows key) are pressed. The bit for that key is set to 1 if the key is pressed, or set to 0 if the key isn’t pressed. The third byte is reserved, and the remaining bytes are for up to six key events.

Step 18

The Keyboard class

We’re going to start by defining the structure of an input report, with all of the keys turned off by default. Then we loop until we can get a keyboard device.

class Keyboard():
    def __init__(self):
        # The structure for an bt keyboard input report (size is 10 bytes)
        self.state = [
               0xA1, # This is an input report
               0x01, # Usage report = Keyboard
               # Bit array for Modifier keys
               [0,   # Right GUI - (usually the Windows key)
                0,   # Right ALT
                0,   # Right Shift
                0,   # Right Control
                0,   # Left GUI - (again, usually the Windows key)
                0,   # Left ALT
                0,   # Left Shift
                0],   # Left Control
               0x00,  # Vendor reserved
               0x00,  # Rest is space for 6 keys
               0x00,
               0x00,
               0x00,
               0x00,
               0x00 ]

        # Keep trying to get a keyboard
        have_dev = False
        while have_dev == False:
            try:
                # Try and get a keyboard - should always be event0 as we’re only
                # plugging one thing in
                self.dev = InputDevice(“/dev/input/event0”)
                have_dev = True
            except OSError:
                print “Keyboard not found, waiting 3 seconds and retrying"
                time.sleep(3)
            print "Found a keyboard"

Step 19

Changing the keyboard’s state

Before you continue, you’ll want to take a quick look at the keymap.py file our expert provided. This file contains a dictionary mapping evdev keys to Bluetooth keys, as well as mapping evdev modifier keys to the bit that needs to be set in the Input Report. The Bluetooth values are in decimal rather than hex, but that doesn’t matter since Python will convert hex to decimal anyway.

This function takes an evdev event and changes the keyboard’s state. Firstly, we check if the key is a modifier key (the function returns a negative number if it’s not) and if so, flip the appropriate bit in the bit array of our Input Report. If not, we get the Bluetooth code of the key and then loop through the key elements. If the key is being released (event value of 0) then we find the key and we depress it by setting the value back to zero. Otherwise, we set the first empty space to the key’s value and break out of the loop to be as efficient as possible.

    def change_state(self, event):
          evdev_code = ecodes.KEY[event.code]
          modkey_element = keymap.modkey(evdev_code)
          if modkey_element > 0:

          # Need to set one of the modifier bits
          if self.state[2][modkey_ element] == 0:
                self.state[2][modkey_element] = 1
          else:
                self.state[2][modkey_element] = 0
          else:
                # Get the hex keycode of the key
                hex_key = keymap.convert(ecodes.KEY[event.code])
                # Loop through elements 4 to 9 of the input report structure
                for i in range (4, 10):
                     if self.state[i] == hex_key and event.value == 0:
                            # Code is 0 so we need to depress it
                            self.state[i] = 0x00 elif self.state[i] == 0x00 and event.value == 1:
                            # If the current space is empty and the key is being pressed
                            self.state[i] = hex_key
                            break

Step 20

The event loop

The event loop is actually really simple; it takes an instance of the Bluetooth class as a parameter and reads input from the keyboard in a loop. Evdev keys have three states: press, depress or hold. We only want to deal with press or depress, because the Bluetooth protocol doesn’t require hold. It’s assumed the key is held if its value is not reset to zero again. We ignore the hold events with the ‘event.value < 2’ condition.

With that out of the way, we simply pass the event to the change state function and then call the send_input function of the Bluetooth class, which we are about to write.

     def event_loop(self, bt):
          for event in self.dev.read_loop():
                # Only bother if we hit a key and it’s an up or down event
                if event.type == ecodes. EV_KEY and event.value < 2:
                       self.change_state(event)
                       bt.send_input(self.state)

Step 21

Sending input

Scroll back up to the Bluetooth class and create the send_input function. This function may look a little complicated, but it’s actually just converting the Input Report from the Keyboard class to a string that can be sent with the Python Bluetooth module.

So, we accept an Input Report and define an empty string that we’re going to build up and then send. We then loop through each element in the Input Report and check if it’s an array. If it is the array, then it will be the array of individual bits that make up the modifier byte. We need to convert this array to a string of eight characters by looping through each element and appending it to the bin_str string. We then need to convert this binary data to an integer – using base 2, as a bit can only have two possible states. We then convert this integer (which will have a size of one byte) to a character (also one byte) that can be added to the hex_str string. If the type is not an array, then the element of the input report can be converted straight to a character and appended to the hex string. Once the hex string is complete, it’s sent down the interrupt channel.

     def send_input(self, ir):
          #  Convert the hex array to a string
          hex_str = “”
              for element in ir:
                   if type(element) is list:
                        # This is our bit array - convrt it to a single byte represented
                        # as a char
                        bin_str = “”
                        for bit in element:
                             bin_str += str(bit)
                             hex_str += chr(int(bin_str, 2))
                        else:
                             # This is a hex value - we can convert it straight to a char
                             hex_str += chr(element)
                   # Send an input report
                   self.cinterrupt.send(hex_str)

Step 22

The final piece

We need to finish off our code by initialising the Keyboard class and calling the event loop function, passing through the instance of the Bluetooth class.

    kb = Keyboard()
    kb.event_loop(bt)

Step 23

Testing the code

That’s it! This is a pretty primitive implementation, as you can probably tell. The performance could also be improved, but the proof of concept is there. We don’t even bother with anything on the control channel, and ignore any Output Reports on the interrupt channel that could contain instructions to set various LEDs on the keyboard. You simply need to run the code and start typing on the keyboard to send input to the client. You’ll probably type a load of rubbish into the console if you’re using the Pi with a screen.

Follow @LinuxUserMag

To ensure you can still make the most of the excellent distros, software and tutorial files intended for the issue, though, we’ve set up a direct download to the ISO.

Once downloaded, simply uncompress the Zip and either burn it to a writable DVD or USB stick (4GB or larger) as you would any normal distro. Please refer to page 96 of the magazine if you need any assistance burning an ISO to DVD.

We can’t apologise enough for the mistake and we’re sorry to have inconvenienced you.

Python Masterclass
Everything you need to start writing programs today

System Admin expert guide
Start a career in open source

Raspberry Pi Jamboree
Inside RasPi’s biggest ever event

Crazyflie Quadrotor
World’s first open source ‘copter reviewed

The ultimate RSS Reader revealed
RSSOwl, Liferea, Blam and Akregator reviewed

Also inside
- Make yout own Wiki
- Rock, Paper, Scissors code listing
- Bitcraze interview
- Reviews for the MiraBox, FLIRC, Rasplex, Webconverger 18, FreeNAS

…and much more!

Tutorial Files

Python for beginners tutorial files

Rock, Paper, Scissors tutorial files

Linux User and our sister mags are all available via Great Digital Mags on all major platforms!

Follow @LinuxUserMag