Testing #240
closed
Integrate use of texy (hy28a) display (2.8inch TFT LCD + Touch screen)
Added by Hammel about 11 years ago. Updated over 10 years ago.
100%
Description
The texy display has arrived. He had forgotten to send it originally and, to make up for it, decided to send me a mounting case for free. I've mounted an RPi in the case with the display (see photo) but my initial boot doesn't seem to see the device. I only have fb0, which is the HDMI monitor.
The discussion on using the display can be found here:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=93&t=53144
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.
Building outside the kernel is available from kernel.org.
Files
| IMG_20131102_161222.jpg (504 KB) IMG_20131102_161222.jpg | Hammel, 02 Nov 2013 16:17 | ||
| IMG_20131102_161310.jpg (504 KB) IMG_20131102_161310.jpg | Hammel, 02 Nov 2013 16:17 | ||
| tft (172 Bytes) tft | loading the drivers manually | Hammel, 15 Nov 2013 07:56 | |
| notes.txt (1.56 KB) notes.txt | lsmod, dmesg grep spi and /sys entries. | Hammel, 15 Nov 2013 07:56 | |
| xorg.conf.tft (1.83 KB) xorg.conf.tft | HDMI + HY28A X.org configuraiton, no xinerama | Hammel, 22 Mar 2014 14:07 | |
| modules.conf (117 Bytes) modules.conf | Modules.conf that rotates image 90 degrees | Hammel, 22 Mar 2014 14:07 |
Updated by Hammel about 11 years ago
- Subject changed from Integrate use of texy display (2.8inch TFT LCD + Touch screen) to Integrate use of texy (hy28a) display (2.8inch TFT LCD + Touch screen)
- Description updated (diff)
- % Done changed from 0 to 10
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.
Updated by Hammel about 11 years ago
- % Done changed from 10 to 20
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.
Updated by Hammel about 11 years ago
- % Done changed from 20 to 30
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.
Updated by Hammel about 11 years ago
- % Done changed from 30 to 40
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....
Updated by Hammel about 11 years ago
It was the sainsmart32_spi driver that was needed. However, I also had to manually load the spidev and spi_bcm2708 drivers first. Even after loading all of these I don't have the new /dev/fb1 created. I'm missing one more thing, I think. I get all of the messages I should expect except this one:
graphics fb1: fb_hx8340bn frame buffer, 176x220, 75 KiB video memory, 16 KiB buffer memory, fps=20, spi0.0 at 32 MHz
I don't know where this comes from yet. Looks like it comes from fbtft somewhere but I'm not getting it. I have two modules loaded:
fbtft_device
fbtft
Asked for help on this on the Pi forums
Updated by Hammel about 11 years ago
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.
Updated by Hammel about 11 years ago
Here is a forum discussion that covers notro's fbtft drivers in more depth. This link is at the current end of the discussion (page 7).
Updated by Hammel about 11 years ago
- % Done changed from 40 to 50
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.
So I went back to my kernel config and changed a few things from compiled into the kernel to compiled as modules:- CONFIG_FB (and associated config options)
- CONFIG_FB_BCM2708
- 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.
Updated by Hammel about 11 years ago
- % Done changed from 50 to 40
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.
Updated by Hammel about 11 years ago
I just noticed the following when trying to run the second X server:
(++) Using config file: "/etc/X11/xorg.conf.tft" (EE) FBDEV(0): FBIOBLANK: Invalid argument (EE) FBDEV(0): FBIOBLANK: Invalid argument [config/dbus] couldn't take over org.x.config: org.freedesktop.DBus.Error.AccessDenied (Connection ":1.1" is not allowed to own the service "org.x.config.display2" due to security policies in the configuration file) blackbox: managing screen 0 using TrueColor visual 0x21, depth 16
So the blanking might be due to some stupid dbus configuration thing. I'll have to dig around to figure that out. I don't know anything about dbus config.
The other thing I tried was to append the following to cmdline.txt:
fbcon=map:10 fbcon=font:VGA8x8
That didn't seem to have any affect though I may try a smaller font next time, such as MINI4x6.
Updated by Hammel about 11 years ago
I've tried a number of different combinations of compiled-in drivers and loadable modules. In every test I ended up with an HDMI monitor that looked like it came from 1980: big blocky letters and an X session that was too large for the display.
Now I'm going back to my original kernel config - sans fbtft drivers - to make sure that still works on this hardware with the tft plugged in (the other RPi has no tft display and has the modified 0.6.0 release and still works as before). If this works, then I'll try adding the fbtft modules into S00dev, before mdev -s is run. That may be all that's required. If so, then my problem will simply be about RM #246.
Updated by Hammel about 11 years ago
The original 0.6.0 build was fine. The HDMI display comes up as expected, not in 1980's mode. So I added the fbtft drivers and the new module loading in S00dev. The drivers are loaded but I have no framebuffer for the hy28a. So the problem is simply that I can't compile in one or more of the following and still be able to dynamically load fbtft:
spidev
bcm2708_fb
fbcon
spi_bcm2708
I've already tried taking them all out but that just caused the 1980's display, so now I guess I should try taking them out one at a time, and in different combinations. Right now spidev is not compiled in but the others are. I'll take out bcm2708_fb first and try that.
Updated by Hammel about 11 years ago
Making bcm2708_fb a loadable module did not allow fbtft to load.
Next I'll put spi_bcm2708 into the kernel instead of using it as loadable module.
Updated by Hammel about 11 years ago
- spidev: loadable module
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
- fb on hdmi worked - could see the boot messages
- fbtft_device loaded, but device file not created and display did not go black.
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: loadable module
Updated by Hammel about 11 years ago
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: loadable module
- fb on hdmi worked - could see the boot messages
- fbtft_device loaded, but device file not created and display did not go black
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
Updated by Hammel about 11 years ago
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
- fb on hdmi worked - could see the boot messages
- fbtft_device failed to load, stating "invalid parameter"
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
- fbtft: kernel builtin
- fbtft_device: kernel builtin
- FB_TFT_ILI9320: kernel builtin
Updated by Hammel about 11 years ago
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
- fbtft: kernel builtin
- fbtft_device: kernel builtin
- FB_TFT_ILI9320: kernel builtin
- fb on hdmi worked - could see the boot messages
- fbtft drivers failed to load because you can't provide a "name=xxx" parameter if you compile into the kernel.
- spidev: loadable module
- bcm2708_fb: kernel builtin
- fbcon: loadable module
- spi_bcm2708: loadable module
Updated by Hammel about 11 years ago
- spidev: loadable module
- bcm2708_fb: kernel builtin
- fbcon: loadable module
- spi_bcm2708: loadable module
- boot messages don't show up on HDMI - I get a hicolor gradient visual which doesn't appear to be related to the expected linux logo (which should be the RPi logo).
- I never get the X session.
This one doesn't work at all but with fbcon not compiled in I didn't think it would work. I just didn't think it would fail that badly.
Next: bcm2708_fb a loadable module and spi_bcm2708 a kernel builtin- spidev: loadable module
- bcm2708_fb: loadable module
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
Updated by Hammel about 11 years ago
- spidev: loadable module
- bcm2708_fb: loadable module
- fbcon: kernel builtin
- spi_bcm2708: kernel builtin
- No boot messages on HDMI.
- Locked up. I put a valid wpa_supplicant.conf on the rootfs to try and get it and it never gets that far. The wifi dongle led lights up and stays solid.
- spidev: kernel builtin
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: loadable module
I may also need to look at CONFIG_FB as a loadable module. I haven't played with that one much.
Updated by Hammel about 11 years ago
- spidev: loadable module
- bcm2708_fb: kernel builtin
- fbcon: kernel builtin
- spi_bcm2708: loadable module
The we make the device node and load the modules:
mknod /dev/fb1 c 29 1 (in rc.modules)
modprobe spidev
modprobe spi_bcm2708
modprobe fbtft_device name=hy28a
Updated by Hammel almost 11 years ago
- Priority changed from Immediate to Normal
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.
Updated by Hammel almost 11 years ago
- Target version changed from 1.0 - Atreides to 0.9.0
Retargeting for 0.9.0.
Updated by Hammel over 10 years ago
- Priority changed from Normal to Immediate
- Severity changed from 04 - Low to 02 - High
Updated by Hammel over 10 years ago
- % Done changed from 40 to 50
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.
Updated by Hammel over 10 years ago
- File xorg.conf.tft xorg.conf.tft added
- File modules.conf modules.conf added
- % Done changed from 50 to 60
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.
To use this I would have to- Have S90UI test for two fb devices and use this config instead of the default config if found.
- 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.
- 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.
Updated by Hammel over 10 years ago
- HDMI only
- FBTFT only
- HDMI + FBTFT only
S90UI has been modified to support this by testing at boot if there are one or two /dev/fb* devices. This worked on first boot with both HDMI and TFT connected. But unplugging the HDMI on the next boot I still had two /dev/fb* devices.
One way to fix this is to use /opt/vc/bin/tvservice -s to test the status of the HDMI port. But this tool is not working. That may be due to having rev'd the kernel to 3.10.y but not rev'ing the RPi firmware at the same time. I've written a new issue for that (see RM #300).
I'll return to this issue after I complete that one.
Updated by Hammel over 10 years ago
- % Done changed from 60 to 70
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.
Updated by Hammel over 10 years ago
This seems to work better. The correct xorg.conf and xinitrc are started if only the TFT is connected. However there are always two fb devices when the TFT is connected and the server needs to be on the second one in that case. That's a minor change to the xorg.conf.tft config to point to /dev/fb1.
I now need to try this on the other RPi, the one without a TFT display.
Updated by Hammel over 10 years ago
- % Done changed from 70 to 90
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:
- 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.
Updated by Hammel over 10 years ago
I switched to using a stamp file that the user will configure. All updates are checked in and pushed upstream.
Updated by Hammel over 10 years ago
Update: fbturbo doesn't work well with fbtft drivers. So I'm disabling it in the current build.
Updated by Hammel over 10 years ago
- Status changed from In Progress to Closed
- % Done changed from 90 to 100
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.