3

There is tutorial like texys-2-8-inch-touchscreen-with-raspicamcorder-step-1 that use a tool that copy framebuffer rpi-fbcp.

After installation of notro firmware and loading PiTFT module :

sudo REPO_URI=https://github.com/notro/rpi-firmware rpi-update
sudo modprobe fbtft_device name=pitft

The camera could be displayed on PiTFT using the commands :

fbcp &
raspivid -t 0

raspivid write on /dev/fb0 and fbcp takes snapshots from /dev/fb0 screen and copy them to /dev/fb1.

How to allow raspivid (or omxplayer) to use directly the PiTFT screen ?

Improve this question

1 Answer 1

Reset to default
3

I don't know for certain, but I suspect the answer is "you can't" for the reasons given in their reply to a user requesting OpenGL support. Just in case that URL changes/disappears, I'll quote the relevant bits below;

  1. Why does the PITFT not support OpenGL?
  2. Are there technical limitations that prevent the screen from supporting OpenGL?

Because it's not directly interfaced to the video circuitry; it's a "dumb" framebuffer connected via the SPI bus on the GPIO header, and only runs so fast. GL requires a high speed interface between the GPU and display, which we don't have here.

  1. Will OpenGL be supported in future versions of hardware/firmware?

Not the PiTFT. If you're patient though, at some point the Raspberry Pi Foundation will release their own display that connects via the LVDS header. In theory anyway, they've talked about it. Perhaps if it's well-documented others can offer displays in other sizes and form-factors, but I have no idea if that aspect will be open and I'm really talking out my rear at this point.

Another alternative is to use either the HDMI or composite interfaces to connect a small external display, driven by the video circuitry and thus GL compatible. Before the PiTFT I'd seen some other emulation projects using such displays...the wiring isn't as tidy and the composite displays won't be razor-sharp due to interpolation...but there you go.

Also also, there are utilities that continually copy the main framebuffer (under GPU control) to the secondary buffer used by the PiTFT. The performance is really quite underwhelming though, and this is why we didn't use that approach for the Cupcade project.

Improve this answer
3
  • I am sure you are correct here; raspivid and oxmplayer are written specifically to exploit the pi's GPU and must use it, but the piTFT is not directly connected to the GPU.
    – goldilocks ♦
    Jan 26, 2015 at 21:20
  • Indeed - it's telling that the raspivid preview works even when one is simply SSH'd into the Pi, in which case the session launching raspivid won't (necessarily) have access to whatever framebuffer is available. In other words, the preview system must get the GPU to overlay the camera's output directly on the video output.
    – Dave Jones
    Jan 26, 2015 at 21:51
  • @mpromonet and Dave: It's possible that this might be of interest. I haven't tried it though.
    – Dennis Williamson
    May 11, 2016 at 19:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.