PiBox

I got it working! There are only a few things I needed to do:

Enable the ft5406 driver in the kernel and firmware. The driver is enabled with this (which is part of the defconfig for RPI):

CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_RPI_FT5406=m

With these we need to load the following two drivers at boot time.

rpi-ft5406
rpi_backlight

The firmware was added with the following lines to the config.txt:

dtoverlay=rpi-ft5406-overlay
lcd_rotate=2

The first is required for the firmware to find the overlay image file, which needed to be copied into overlays/rpi-ft5406.dtbo. That file was part of the stock firmware build I'm doing with PiBox so it was already available.

The second line makes the screen flip 180 degrees. This is necessary because the power plug is on the bottom by default, making it hard to stand the display (the cable gets in the way). Flipping the display puts the cable out the top.

I'm not sure if these are needed, but I added them just in case:

framebuffer_width=800
framebuffer_height=480
fbwidth=800
fbheight=480

Then I had to set xorg.conf to have the smaller screen size:

Section "Screen"                                        
        Identifier          "Builtin Default fbdev Screen 0"     
        Device              "Builtin Default fbdev Device 0"            
        Monitor             "Builtin Default Monitor"               
        SubSection "Display" 
            Depth 24         # 24bit works fine but for USB 2.0 a lot of data
            Modes "800x480" 
        EndSubSection
EndSection  

Section "InputClass" 
   Identifier "calibration" 
   Driver "evdev" 
   MatchProduct "FT5406 memory based driver" 

   Option "EmulateThirdButton" "1" 
   Option "EmulateThirdButtonTimeout" "750" 
   Option "EmulateThirdButtonMoveThreshold" "30" 
EndSection

The screen section limits the X.org screen to the size of the display (which is 800x480). The input class sets up the touch screen so events get passed into applications, like the GTK+ launcher.

With these changes I was able to boot into the PiBox Media Center display. It just barely fit (the splash text was cut off) but it worked.

1. Provides a simple touch screen interface for starting a feature
2. Plays videos from a directory
3. Plays slideshow of images in a directory
4. Stops displays and shows a single image

Programming with the touchscreen can be done using the input system using ioctls. But that's not for X.org. For that, we use the evdev driver and then use GTK+ event handling to get X/Y coordinates on button presses. This is actually already designed into my GTK+ apps, like in the launcher.

This means the front end (launcher replacement) would offer a selection of playing videos or image slideshows as separate apps. Then the apps would exit on a button press. The image slideshow would be easy to handle like that. The video playback has to map a button press to the ESC key for omxplayer, just like the PiBox Media Center.

If the omxplayer keyboard config bindings don't work I might try using xbindkeys to map "b:1" (or :b:2 or b:3) to "killall omxplayer". That assumes that the button press while running omxplayer is passed through the X server. It's hard to tell who is getting the button press when omxplayer is running. All I can do is test it.

The omxplayer key config file didn't work and neither did setting up an XResource file for the xterm wrapping the call to omxplayer. In fact, even just doing ESC in omxplayer without these didn't work either (as it does in use with a standard monitor).

So now I think I'm down to monitoring the input device (/dev/input/eventX) manually. I can do this with tslib or I can do it manually (or here). Either will have to be done in VFE as part of the setup for running omxplayer. When an event is caught it needs to be translated into an omxplayer command. These can be piped to omxplayer through a fifo (or here). This has the advantage of being able to map different event types (such as dragging across the screen) to different commands (like skipping forward and back and changing the volume).

I got it working today. I used a new thread in videofe that runs a nonblocking tslib query on /dev/input/event3 (hardcoded for now). When an event comes in (any event from that device, which is the touchscreen in this particular setup) I kill omxplayer with a call to system("killall omxplayer"). Works perfectly. I can now exit omxplayer with a single tap to the screen.

Now I need a way to identify which input device to use. This has to be done by name. I'm looking for a device with a name of FT5406 memory based driver which can be queried by opening each eventX device and running the following ioctl to get it's name.

ioctl (fd, EVIOCGNAME (sizeof (name)), name);

See linux-input-codes.h and input.h for details on using the ioctl.

I would still want to map the events captured to commands piped to omxplayer. One simple way to do this is divide the display into 6 sections. Tapping in the top three would do stop/ff/vol up while the bottom three might do pause/rewind/vol down. That's pretty simple to do given the simplistic data returned from tslib. If I want something more complex I'll have to drop tslib in favor of getting input directly from device reads using the kernel input system structures.

So far all my changes are just hacks to get it working on the touchscreen. Later I'll clean them up, such as making them available only if the device is configured with a touchscreen, though I'm not sure that the moment how to know the touchscreen is being used and not the HDMI.

I can get the touchscreen (or HDMI) display size with this:

/opt/vc/bin/tvservice -s | cut -f4 -d" " 

The output for this command when run with the touchscreen display is:

800x480

state 0x400000 [LCD], 800x480 @ 60.00Hz, progressive

For HDMI displays the output is a little different:

state 0x120006 [DVI DMT (39) RGB full 16:9], 1360x768 @ 60.00Hz, progressive

So the real cut is the comma:

/opt/vc/bin/tvservice -s | cut -f2 -d"," | cut -f2 -d" " 

That should pull the resolution out for either HDMI or Touchscreen.

This has become a catch all for the in-memoriam project. I've finished adding touchscreen support to libpibox, added touchscreen support to videofe, and added a kiosk mode to videofe so it will play videos in sequence without a UI. This works quite well. I've regression tested against the original use-case of TV/desktop monitor displays and that still works. Interestingly, the SMB automount was running during testing and it picked up another Pi I had running with PiBox. The kiosk mode happily played the movies from that Pi too, though that isn't the intended use-case for In-Memoriam.

The next step is an image viewer app. This is just a variation of videofe, using feh as the image viewer. Feh is already in the core distro and it's easy to have it cycle through the images in a directory or via a filelist. To use it:

feh -r -F -D 2 --zoom fill path/

or

feh -r -F -D 2 --zoom fill -f filename

I just copy videofe to the new app, strip the video player component and replace it with an image viewer component. Pretty straight forward stuff. On, and feh support SIGUSR1 and SIGUSR2 to moving to the next/prev, respectively, image. That means the touchscreen support in this app can control the playback of the images. At least with respect to skipping forward and back.

After the image viewer comes touchscreen support for the launcher so the user can touch the app they want. This only requires converting widget coordinates to absolute coordinates. The libpibox touchscreen support provides absolute coordinates instead of regions, if desired. I just have to find out how to convert GTK+ widget x/y to screen coordinates, which should by easy I think.

Then it's just a matter of making an In-Memoriam distro with just the two apps. The user just plugs in a USB stick with images and videos and off they go.

This is nearly done. All for you, my little Reba.

1. The rpi modules are not being loaded. They get added to /etc/modules.conf but aren't loaded automatically at boot time.
2. After loading the modules PiPics just displays gray gradients where there should be a picture.

Drivers are loaded. Problem is that the device files in /dev/input are not readable except by privileged programs. So I need to fix the mdev.conf file for them.

The gradient file was an image found under /media/mmc* which was searched because the dbtop was set to /media/ instead of /media/usb.

The solution is probably to just leave /media as the dbtop and change the code to ignore /media/mmc* directories.

mdev.conf updated. PiPics default dbtop set to /media/usb.

All changes committed.

Now I'll make a disk image and push it to the release repo.