Page 1 of 1

RPi2: SPI display 320x240

Posted: Thu Apr 23, 2015 2:08 pm
by peepo
Is there a link for RPi2 specific issues? hint...

I'm struggling to find how I might use Adafruit SPI display with RPi2

I already have similar 320x240 usb display using Nostro framebuffer with RPI2: ... vanced/594
might both might run together?
or would it be essential to run on different builds?



Re: RPi2: SPI display 320x240

Posted: Fri Apr 24, 2015 6:14 pm
by texy
Hi, I am not sure what you are asking. Why would it be a RPI2 issue?
You have 2 different displays and they need different configurations?
PS, I have locked your other thread,
Please don't duplicate.

Oh, and it's notro, not nostro ;)

Re: RPi2: SPI display 320x240

Posted: Fri Apr 24, 2015 6:42 pm
by DougieLawson
There's support for PiTFT with Notro's drivers in the stock kernel with a device tree overlay. See if that's in /boot/overlays and documented in /boot/overlays/README on your system.

Code: Select all

File:   pitft28-resistive-overlay.dtb
Info:   Adafruit PiTFT 2.8" resistive touch screen
Load:   dtoverlay=pitft28-resistive,<param>=<val>
Params: speed                    Display SPI bus speed

        rotate                   Display rotation {0,90,180,270}

        fps                      Delay between frame updates

        debug                    Debug output level {0-7}

Re: RPi2: SPI display 320x240

Posted: Sat Apr 25, 2015 11:49 am
by peepo

unfortunately this build does not have /boot/overlays,
as per link above special kernel for usb display...

is there an easy workaround?
I'd like the option to use either and both displays if possible.

$ uname -a
Linux RPi2usbDisplay 3.19.2-v7+ #1 SMP PREEMPT Sat Mar 14 14:38:35 GMT 2015 armv7l GNU/Linux

Re: RPi2: SPI display 320x240

Posted: Sat Apr 25, 2015 11:51 am
by DougieLawson
Replace the kernel and /lib/modules with a kernel that does support the DT.

Re: RPi2: SPI display 320x240

Posted: Sat Apr 25, 2015 11:56 am
by peepo
easily said...

adafruit easy-install instructions are rather lengthy: ... sy-install

which seems at variance with your suggestion?


Re: RPi2: SPI display 320x240

Posted: Sat Apr 25, 2015 11:59 am
by DougieLawson
Forget that old, out of date crud.

Building kernels is trivial (it's long winded). ...

If you can run rpi-update you can get to 3.18.11-v7+ #781 which includes the DT stuff you need.

Re: RPi2: SPI display 320x240

Posted: Sat Apr 25, 2015 12:05 pm
by peepo
I received that response from admin today: ... 14#p368214

as noted, 3.19 kernel is already installed
iirc rpi-update overwrote kernel, breaking usb display function.

for these reasons I think it may be helpful do have clear simple instructions,
that provide known functionality.
its already quite easy to break.


Re: RPi2: SPI display 320x240

Posted: Sun Nov 22, 2015 2:04 pm
by mikeharpe
For what it's worth my own weekend of figuring this out has produced the following.

I will say up front that I am not claiming to be an expert. If there something unacceptably incorrect here please let me know so others don't spend a weekend on this.

Make sure you understand how to orient the module on the RPi2 connector. Hint: it should cover the RPi2 board with the RPi2 connector on the lower right as you look at it. Connect the display to the rightmost pins leaving a few to the left uncovered.

"You've just got to know that" is not a good answer. These boards are for people who are just getting started in this world. I have been playing around with stuff like this for many, many years and it was not obvious to me at all. It's a few extra lines of documentation.Making the connector larger was a good thing but maybe something on the silk screen of the board showing which end is the legacy end might help people out.


My environment is a RPI 2 with the PID 1601 Adafruit 2.8" display.

My first suggestion is for all of us to agree on what to call these things. The various supposedly authoritative sources on using the fbtft driver have at least three different ways to refer to the display. That's just going to generate support requests. My suggestion is to call it something like ada-28-1601 or something similar. Adafruit should also put the PID (really isn't it a SKU?) right on the board where you can read it. I had to go back to my sales order to find which display I actually bought since there are a couple of versions that look identical. That's especially important in this case when the only difference between the units is the touchscreen it employs.

The numerous documentation sources are not, repeat, not dealing well with the integration of fbtft into the Linux kernel. The nearest I can tell the most authoritative place is

The overall documentation situation needs work. I'm hoping that this note is a starting point. I don't have the expertise to do a thorough job.

I have the display mostly working with my RPi2 using the following....

Base Jessie distro downloaded from the Raspian site. Here's my 'uname -a' info....
Linux raspberrypi 4.1.7-v7+ #817 SMP PREEMPT Sat Sep 19 15:32:00 BST 2015 armv7l GNU/Linux
Here's the relevant part of my /boot/config.txt...

Code: Select all

/etc/modules is unchanged. I have no idea if that's right or wrong. It looks to me like the Device Tree overlay makes this unnecessary but I could be wrong about that.

Set the RPi2 up to boot to a console with the user logged in. Follow the procedure documented here...
This will get X setup such that the 'startx' command will work and X will come up on the display. I'm still figuring out how to get everything right here because it's trying to cram everything onto that tiny screen. Obviously I need to learn how get everything scaled properly.

That Wiki is the most authoritative site which makes sense because it's the site maintained by the person who wrote the driver. Lots of good information however the assumption is that you're a pretty literate Linux user with some knowledge of how Linux works at a systems level rather than just a hardware enthusiast level.

I love Adafruit but they need to seriously work on how they present the setup for these things. Yes, their image will get the display to work but I think the warning about not using the update tools after the installation is a show stopper. We're just adding another display and doing so should still allow us to work within the maintenance infrastructure that's out there.

Where I am now:

X works with the display although not optimally.
I can't get mplayer to run any videos on it.

I hope this is helpful. I felt compelled to write this because I have taken advantage of a lot of work by other people who work very hard to make all of this information available. It didn't seem right to not share my notes from my workbench.

Re: RPi2: SPI display 320x240

Posted: Mon Nov 23, 2015 11:20 am
by texy
mikeharpe wrote: X works with the display although not optimally.
You are dealing with a display with a resolution of 320 x 240 - that's pretty restrictive for a desktop GUI environment ;)
mikeharpe wrote: I can't get mplayer to run any videos on it.

I would recommend omxplayer over mplayer, but neither can direct video to /dev/fb1/ which these displays utilise. Search for 'fbcp' which is a background app that copies the contents of /dev/fb0 to /dev/fb1 very efficiently.


Re: RPi2: SPI display 320x240

Posted: Tue Nov 24, 2015 6:46 pm
by Keith Robinson
I'm currently trying to get video onto a small display too. I wrote the device driver for my 128x128 display.
mplayer can play video from a file to this small display (fb1)
mplayer can play video from a webcam to the main display (fb0)
mplayer can't play video from a webcam to the small display (fb1)

I thought it should be able to, a webcam is simply a source of video, same as the file.
I believe there are technical reasons for this, but I can't find an explanation anywhere.

So I'm stuck with the fbcp program in the middle.
This simply grabs the whole desktop and shrinks it to the OLED size.
This is useless for as a GUI, everything is shrunk as to be unreadable.
The aspect ratio is not preserved, so everything looks taller and thinner.

A trivial change to fbcp code creates a 128x96 image on the OLED.
This is the same aspect ratio of my webcam's 384x288 pixels.

If I could stretch the webcam image to be full screen, that would fill my OLED window.
Alas, mplayer does not stretch the image to fit the window on the Pi.
Perhaps it can't spare the processing power on the Pi, because it happily does full-screen webcam on my Linux desktop PC.
I suspect the Pi can stretch video but that mplayer hasn't got round to harnessing the GPUs yet.

Meanwhile I need to change fbcp to take 384x288 webcam pixels and shrink it to 128x96 pixels on the OLED.

fbcp makes calls to the OpenMax API, which I discover is being deprecated. Partly due to poor documentation.
People a lot cleverer than me, e.g. dom and jamesh, find OpenMAX hard going, so that does not well for me.

I think it will be less work to mod the OpenMAX code than to re-write the whole lot in OpenGL.

Re: RPi2: SPI display 320x240

Posted: Mon Nov 30, 2015 7:56 pm
by Keith Robinson
I've modified fbcp to capture the frame buffer at 1/3rd size, and copy 128x128 pixels to my OLED screen. However, the dispmanx_snapshot function does not seem to be grabbing all the screen pixels required. I only see the top half of my camera image.

I am wondering if this function is only meant for grabbing screen thumbnails, and has an upper limit for the snapshot size. Taking a 128x128 snapshot works, but a 640x400 snapshot is over 14 times bigger...