I spent way too much time last week at work trying to get a Linux kernel touchscreen driver to work.
The screen vendor supplied the source for the driver with no documentation at all, after poking through the code I discovered it took it’s configuration parameters from a Device Tree overlay.
Device Tree
So started the deep dive into i2c devices and Device Tree. At first it all seemed so easy, just a short little overlay to set the device’s address and to set a GPIO pin to act as an interrupt, e.g. something like this:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target = <&i2c1>;
__overlay__ {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
pn547: pn547@28 {
compatible = "nxp,pn547";
reg = <0x28>;
clock-frequency = <400000>;
interrupt-gpios = <&gpio 17 4>; /* active high */
enable-gpios = <&gpio 21 0>;
};
};
};
};All the examples are based around a hard wired i2c device attached to a permanent system i2c bus, this is where my situation differs. Due to “reasons” too complicated to go into here, I have no access to either of the normal i2c buses available on a Raspberry Pi so I’ve ended up using a Adafruit Trinket running the i2c_tiny_usb firmware as a USB i2c adapter and attaching the touchscreen via this bus. The kernel driver for the i2c_tiny_usb devices is already baked into the default Raspbian Linux kernel so meant I didn’t have to build anything special.
The problem is that USB devices are not normally represented in the Device Tree as they can be hot plugged. After being plugged in they are enumerated to discover what modules to load to support the hardware. The trick now was to work out where to attach the touchscreen i2c device, so the interrupt configuration would be passed to the driver when it was loaded.
I tried all kinds of different overlays, but no joy. The Raspberry Pi even already has a Device Tree entry for a USB device, because the onboard Ethernet is actually a permanently wired device and has an entry in the Device Tree. I tried copying this pattern and adding an entry for the tiny_i2c_usb device and then the i2c device but still nothing worked.
I have an open Raspberry Pi Stack Exchange question and an issue on the tiny-i2c-usb github page that hopefully somebody will eventually answer.
Userspace
Having wasted a week and got nowhere this morning I decided to take a different approach (mainly for the sake of my sanity). This is a basic i2c device with a single GPIO pin to act as an interrupt when new data is available. I knew I could write userspace code that would watch the pin and read from the device, so I set about writing a userspace device driver.
Python has good i2c and GPIO bindings on the Pi so I decided to start there.
import smbus
import RPi.GPIO as GPIO
import signal
GPIO.setmode(GPIO.BCM)
GPIO.setup(27, GPIO.IN, pull_up_down.PUD_UP)
bus=smbus.SMBus(3)
def callback(c):
ev = bus.read_i2c_block_data(0x38,0x12,2)
x = ev[0]
y = ev[1]
print("x=%d y=%d" % (x, y))
GPIO.add_event_detect(27,GPIO.FALLING,callback=callback)
signal.pause()
This is a good start but it would be great to be able to use the standard /dev/input devices like a real mouse/touchscreen. Luckily there is the uinput kernel module that exposes an API especially for userspace input devices and there is the python-uinput module.
import smbus
import RPi.GPIO as GPIO
import uinput
import signal
GPIO.setmode(GPIO.BCM)
GPIO.setup(27, GPIO.IN, pull_up_down.PUD_UP)
bus=smbus.SMBus(3)
device = uinput.device([
uinput.ABS_X,
uinput.ABS_Y
])
def callback(c):
ev = bus.read_i2c_block_data(0x38,0x12,3)
down = ev[0]
x = ev[1]
y = ev[2]
if down == 0:
device.emit(uinput.BTN_TOUCH, 1, syn=False)
device.emit(uinput.ABS_X, x, syn=False)
device.emit(uinput.ABS_Y, y)
else:
device.emit(uinput.BTN_TOUCH, 0)
GPIO.add_event_detect(27,GPIO.FALLING,callback=callback)
signal.pause()
This injects touchscreen coordinates directly into the /dev/input system, the syn=False in the X axis value tells the uinput code to batch the value up with the Y axis value so it shows up as an atomic update.
This is a bit of a hack, but it should be more than good enough for what I need it for, but I’m tempted to keep chipping away at the Device Tree stuff as I’m sure it will come in handy someday.
