Pairing a bluetooth Intsun/Terios T3 gamepad on Linux

These instructions are mostly for my later convenience but if you have an Intsun or Terios T3 bluetooth gamepad that you want to pair with Linux via the command line they might help you out.

These instructions assume you have a bluetooth dongle that is recognised by your kernel. I’ve had success with this one. These steps worked for me on Ubuntu 16.04 LTS.

  1. Install the following packages:
    $ sudo apt-get install bluez joystick
  2. Put the gamepad in bluetooth pairing mode by holding down the X and Home buttons simultaneously. The LED ring around the home button should now start blinking rapidly.
  3. Start the interactive command-line interface to the bluetooth stack bluetoothctl
    $ sudo bluetoothctl
    [NEW] Controller XX:XX:XX:XX:XX:XX live-0 [default]

    For readability I’ll put the typed commands in blue from here on.
  4. Next power on your bluetooth interface and make it discoverable (maybe not strictly necessary):
    [bluetooth]# power on
    Changing power on succeeded
    [bluetooth]# discoverable on
    Changing discoverable on succeeded
    [CHG] Controller XX:XX:XX:XX:XX:XX Discoverable: yes
  5. Register as the default agent:
    [bluetooth]# agent on
    Agent registered
    [bluetooth]# default-agent
    Default agent request successful
  6. Start scanning to look for discoverable devices:
    [bluetooth]# scan on
    Discovery started
    [CHG] Controller XX:XX:XX:XX:XX:XX Discovering: yes
  7. After a few seconds the devices command should list your gamepad:
    [bluetooth]# devices
    [NEW] Device YY:YY:YY:YY:YY:YY Bluetooth Gamepad
  8. It seems that PIN-less pairing requires that the device be trusted first:
    [bluetooth]# trust YY:YY:YY:YY:YY:YY
    [CHG] Device YY:YY:YY:YY:YY:YY Trusted: yes
    Changing YY:YY:YY:YY:YY:YY trust succeeded
  9. Try to pair with the gamepad:
    [bluetooth]# pair YY:YY:YY:YY:YY:YY
    Attempting to pair with YY:YY:YY:YY:YY:YY
    [CHG] Device YY:YY:YY:YY:YY:YY Connected: yes
    [CHG] Device YY:YY:YY:YY:YY:YY Modalias: usb:v1949p0402d011B
    [CHG] Device YY:YY:YY:YY:YY:YY UUIDs: 00001124-0000-1000-8000-00805f9b34fb
    [CHG] Device YY:YY:YY:YY:YY:YY UUIDs: 00001200-0000-1000-8000-00805f9b34fb
    [CHG] Device YY:YY:YY:YY:YY:YY Paired: yes
    Pairing successful
  10. Connect to the gamepad:
    [bluetooth]# connect YY:YY:YY:YY:YY:YY
    Attempting to connect to YY:YY:YY:YY:YY:YY
  11. Quit bluetoolctl:
    [bluetooth]# quit
    Agent unregistered
    [DEL] Controller XX:XX:XX:XX:XX:XX live-0 [default]

All being well the gamepad LEDs will now stop flashing and a single one will be illuminated.

You can test the gamepad using the jstest command:
jstest /dev/input/js0
(your device name may vary)

Virtually unplug USB devices under Linux

A USB cable lies unplugged next to a laptop

My laptop has a built-in webcam which I don’t normally want enabled. The immediately obvious solution to this would be to blacklist the usb webcam kernel module (uvcvideo). However, I sometimes want to plug in an external USB webcam and use that. So how do you unplug/disable a built-in USB device under Linux?

After a bit of poking about it turns out to be possible to do via sysfs, but it’s a bit fiddly. So I wrote a script that I can run from rc.local to disable (or enable) a device with a specific vendor and product id.

Example usage:

$ lsusb
[...]
Bus 003 Device 005: ID 04ca:7034 Lite-On Technology Corp. 
[...]
usbEnableDisable.sh 04ca 7034 disable

Reject DOS line-endings at Git pre-commit

All *nix devs seethe with rage when DOS line-endings (CRLF) end up in your beautiful source code, right? If you use Git for your version control you’re in luck, use this local pre-commit hook to kick those CRLFs to the kerb before they can even make it into your local commit.

Install by copying the pre-commit file to the .git/hooks directory of your checkout. Ask your Windows using colleagues nicely to do the same.

Dropbox on Ubuntu Server

I’ve been using the Dropbox Linux client on my server for a while now, it’s very handy for sync’ing files to & from my various systems.

I recently installed a new server and hit the problem that following the usual instructions:


cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -
~/.dropbox-dist/dropboxd

resulted in Dropbox not starting.

The problem (according to its crash log) was that it was trying to link against libgtk which I didn’t have installed on my (headless) Ubuntu Server 14.04 installation.

After a bit of messing around I realized that the problem was that I had enabled ForwardX11 on my PuTTY sessions and so dropboxd thought that I had an X11 session available. When I disabled X11 forwarding the problem went away & dropboxd ran as normal.

Network remote for Onkyo A/V Receivers

I recently purchased an Onkyo TX-NR515 A/V receiver & amplifier. One of my main reasons for choosing this amp was that it supports network remote control via its ethernet port. This enables me to shut the amp away out of sight in an A/V cabinet and control it using the Onkyo Remote Android app.

Being a geek though it wasn’t sufficient for me to be able to control it via app. I wanted to make the amp “magically” turn itself on & select the correct input source when I turned on my HTPC or Squeezebox Touch (more on this soon).

Thanks to Tom Gutwin‘s excellent work of finding Onkyo’s protocol specification & documenting his efforts to produce a Java eISCP client it was pretty easy to produce a little Linux command-line utility which sends remote commands to an Onkyo amp.

The utility is written in C and should compile cleanly with GCC on Linux (it may work on other platforms, I haven’t tried it). Usage is as follows:

./onkyo-iscp <amp hostname or ip> <ISCP command> <command parameter>

For example:

./onkyo-iscp onkyo.home.lan PWR 01

will send a “power on” message to the amp. There’s currently no error checking on the command or parameters, it assumes you know what you’re sending to the amp (read the protocol spec for a list of commands & parameters). It also doesn’t read any data from the amp, I might get around to implementing this eventually (if it turns out that I need it).

Source tarball is here: onkyo-iscp.tar.gz