PiBox

The driver appears to support this device (whish is a hy28a). So all that's needed, initially, is to get the driver into the kernel build. I can do this either by adding a patch to the kernel build or by making an opkg that cross compiles the module. The latter seems more reasonable as some users of PiBox Development Platform may not have or want a TFT touch screen attached via SPI/GPIO.

The driver source is built around kconfig's menu system to enable/disable multiple displays. So this code is more easily built by integrating it into the kernel build of the PiBox Development Platform. That makes sense, too, since it would be nice for the generic platform to have the option of supporting a variety of touch screen TFT displays.

According to this table on LCD Modules the HY28A module uses the ILI9320 chip, so the latter is what I need to enable for my display.

In the PiBox Development Platform it may make sense to enable all of the supported chips as modules.

I've updated the kernel build in my sandbox to include the FBTFT module source and configured the ILI9320 as a test. When it's done I'll try it out on the hardware using info from the fbtft wiki.

According to the original post the display was supposed to be a HY28A, but configuring "that driver" didn't work. Running

dmesg | grep -i spi

returned that the device was actually a sainsmart32_spi. So I need the SSD1289 driver instead. Back to recompiling the kernel modules....

Loading the drivers with the attached script gets the correct hy28a loaded, but I'm missing an entry for fb1 in /sys/class/graphics.

Texy responded to the forum question I posted asking for more info. I provided the attached notes.

notro's wiki (they guy who wrote the fbtft drivers) had a page discussing how the binary drivers are built directly on an RPi using raspbian. I followed those directions, including patching a driver to remove a couple of lines but none of that helped. I still had the same problem that the probe was not occurring.

1. CONFIG_FB (and associated config options)
2. CONFIG_FB_BCM2708
3. CONFIG_FRAMEBUFFER_CONSOLE

This worked. Neither the console nor the hy28a showed anything on boot, but after loading the fbtft drivers the hy28a went black (from white) and I was able to start an X session on it. However, the console was no longer working. The touchscreen was not working but that's another driver loading issue (and possibly some user space tools). I'll get to the touchscreen later.

So there is some combination and/or order of driver loading to get both framebuffer devices created. And I need to get the driver loaded early enough to be able to get the splash screen to work.

But at least I know the drivers work for the hy28a now.

A little more progress today.

I put the following module loading into S00dev, in this order:

modprobe spidev
modprobe bcm2708_fb 
modprobe fbcon 
modprobe spi_bcm2708
modprobe fbtft_device name=hy28a verbose=3

Now I get both framebuffer devices (fb0, fb1). I can run the following command to get X started on the hy28a after it's running on the HDMI display:

xinit /etc/X11/xinitrc -- /usr/bin/X :2 -xf86config /etc/X11/xorg.conf.tft

Where xorg.conf.tft looks like this:

Section "Device" 
    Identifier "TFT" 
    driver "fbdev"         
    Option "fbdev" "/dev/fb1"    # You have to use the correct framebuffer device here
EndSection

Problems:
1. The screen size of the fbcon (hdmi) is incorrect. I have big fonts and the X display no longer fits. The xterm takes up the whole display. This is likely a problem with how I load fbcon.
2. When I run X on the second display (hy28a), the first display (hdmi) goes blank. When I kill X on the second display the first comes back. I'm guessing but this might get fixed with a more complete xorg.conf.tft.

Module loading in S00dev is not really what I want. I want to load the modules via /etc/modules.conf. I think mdev will do that but I'm not sure of the file format for modules.conf or if /etc is the right place to put that.

This issue is on hold until I can get a 3.10.y kernel working to see if the drivers work better there than under 3.2.27+.

Changing to a lower priority until RM #176 is completed.

Retargeting for 0.9.0.

Integrated fbtft driver into kernel build. The driver builds correctly and when loaded manually after boot appears to be working. However, if I load the correct drivers with modules.conf at boot time the driver doesn't work. I have to reload the driver after X starts. This will need some additional research.

I'll also need to find a way to get two X servers running at the same time. A few of the tests listed in earlier posts for this issue do get an X session running but the main X session goes away. Also, I might be able to get a GTK+ app running on the framebuffer but I'm not sure how to do that yet. This will be a separate issue once I have two X sessions running at once or some other test that show both the HDMI and TFT displays running at the same time.

Got it working with X.org today. Attached is the config file that is used to create 2 independent screens. The HY28A screen must be rotated 90 degrees when the driver is loaded in order to width longer than height. I may want to increase the FPS too (it's defaulting to 20) for video playback, if that's ever used.

Applications that are defined for use with the TFT display must set DISPLAY to :0.1 to specify the second screen then there are two monitors or :0 if the TFT is the only device. Knowing this requires the S90UI script to create a stamp file on boot with the correct setting.

1. Have S90UI test for two fb devices and use this config instead of the default config if found.
2. Have S90UI test if one fb device if the fbtft_device is loaded. If it is then the TFT is loaded and only a separate TFT-only config would need to be used.
3. Otherwise have S90UI use the current default config.

Also, I still need to figure out why the loading of the drivers doesn't allow access to the device at boot time, but only after I remove the modules and reload them. Maybe S90UI can do that if it sees two fb devices.

I'll add some images of the two monitors working at the same time a little later.

This is what I get with tvservice with the HDMI plugged in:

# /opt/vc/bin/tvservice -s
state 0x120016 [DVI DMT (83) RGB full 16:9], 1600x900 @ 60Hz, progressive

And this is what I get with the HDMI unplugged.

# /opt/vc/bin/tvservice -s
state 0x40002 [NTSC 4:3], 720x480 @ 60Hz, interlaced

This isn't really enough to tell if its plugged in or not. So I tried -? to see what other options there are and found -n, which gives this when the HDMI is plugged in:

# /opt/vc/bin/tvservice -n
device_name=DEL-DELL_ST2010

which gives the following with the HDMI unplugged

# /opt/vc/bin/tvservice -n
[E] No device present

So the -n option is what I need to determine if the HDMI is plugged in or not. I don't have a similar option for the fbtft, I don't think. I'll have to look at the fbtft_tools to see if there is anything in there I can use. Or maybe I can just try to load the driver and have it fail cuz its not there or look at something under /sys/module/fbtft.

There doesn't appear to be any difference in the /sys tree when the TFT is connected or not. I might try looking at the output of the log but it looks like the device is there when its not:

1. grep fbtft_device /var/log/messages | cut f11 -d" "
   fbtft_device: SPI devices registered:
   fbtft_device: spidev spi0.0 500kHz 8 bits mode=0x00
   fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
   fbtft_device: 'fb' Platform devices registered:
   fbtft_device: bcm2708_fb id=-1 pdata? no
   fbtft_device: Deleting spi0.0
   fbtft_device: GPIOS used by 'hy28a':
   fbtft_device: 'reset' = GPIO25
   fbtft_device: 'led' = GPIO18
   fbtft_device: SPI devices registered:
   fbtft_device: spidev spi0.1 500kHz 8 bits mode=0x00
   fbtft_device: fb_ili9320 spi0.0 32000kHz 8 bits mode=0x03

So that doesn't help either. I don't think there is a way to enumerate the device at boot. So the only alternative is to allow enabling the device manually through an admin interface. If enabled. the drivers are loaded and the multi monitor xinitrc is used.

So this becomes and admin problem now. See RM #281. When that issue is complete, including support for enabling the TFT, then this issue can be closed.

I've finally got this working. One caveat: X and fbtft can't be run together. And while I can test for an HDMI connection I can't test for the fbtft's presence. The solution is to use a stamp file for the fbtft (which can be added through an administrative UI to be developer later for the HDMI). If it's there, the fbtft is configured properly. If it's not the X UI is configured.

I've adjusted the init scripts to deal with this and the drivers all seem to work as expected now.

Using the fbtft will require writing DirectFB applications that utilize the tslib for touchscreen input. Those issues are being tracked separately. This issue can be closed.