LoveBootCaptain / WeatherPi_TFT

a weather display for a raspberry pi and a TFT display written in python3 and pygame
Other
78 stars 24 forks source link

libSDL and framebuffer display #39

Open mattblovell opened 3 years ago

mattblovell commented 3 years ago

I have a Raspberry Pi 3 Model B v1.2 running the latest (32-bit) version of Raspberry Pi OS:

Linux raspberrypi 5.4.51-v7+ #1333 SMP Mon Aug 10 16:45:19 BST 2020 armv7l GNU/Linux

and Python 3.7.3. For a display, I have a SPI-attached ILI9341-based TFT LCD panel, specifically this one:

http://www.lcdwiki.com/3.2inch_SPI_Module_ILI9341_SKU:MSP3218

that I do have working with a dtoverlay, creating /dev/fb1 upon which I can render images (via fbi) or play movies (via mplayer).

Pulling the latest WeatherPi_TFT, however, I cannot get it to display on /dev/fb1. Instead, it always ends up rendering on the HDMI display (/dev/fb0). The same is true for other Python programs that make use of pygame and rely, as WeatherPi_TFT appears to, upon the environment variables $SDL_FBDEV and $SDL_VIDEODRIVER to "direct" libSDL to make use of a framebuffer directly.

Googling around about the issue, I came across this posting from early 2019 on the Raspberry Pi forums:

Issue using Python3/pygame to output to /dev/fb1 targeting a 2.8" TFT screen https://www.raspberrypi.org/forums/viewtopic.php?t=234087

In a follow-up post, that author states the following:

Why not using pygame/SDL1.2.x as instructed in many forums and the adafruit TFT manual?

First, it doesn't work, at all. I have tried a gazillion versions of libsdl and its dependencies and they all failed consistently. I've tried forcing some libsdl versions downgrades, same with pygame version, just to try to get back to what the software was when my TFT screen was released (~2014). Then I aslo tried switching to C and handle SDL2 primitives directly.

Furthermore, SDL1.2 is getting old and I believe it is bad practice to build new code on top of old one. That said, I am still using pygame-1.9.4...

So why not SDL2? Well, they have stopped (or are about to stop) supporting framebuffers. I have not tried their alternative to framebuffers, EGL, as it got more complex the further I digged and it did not look too engaging (so old it felt like necro-browsing). Any fresh help or advice on that would be greatly appreciated BTW.

I was wondering if you had any insights into this matter? Have you tried WeatherPi_TFT under the latest Raspberry Pi OS? Do you know if libSDL is indeed deprecating / dropping support for framebuffers?

I ask since I would like to get WeatherPi_TFT working on my RPi3, as well as figure out what changes are necessary for my small project (kodi_panel) to make use of /dev/fb1.

Thanks!

mattblovell commented 3 years ago

I've had some luck following the advice from the 2018 answer provided in this stackoverflow thread (started in 2015).

https://stackoverflow.com/questions/27735961/no-video-mode-large-enough-error-in-pygame-when-using-1-8-tft-via-a-rpi

In particular, I was getting a "No video mode large enough" error from pygame. The advice to take the initial output from

fbset -i -fb /dev/fb1

and add it to the contents in /etc/fb.modes appears to have worked. I now have WeatherPiTFT displaying there with the "standard" values for the two `SDL*` environment variables. (Although starting WeatherPi_TFT also seems to cause X, on the HDMI display, to go completely blank.)

Prior to the above, I also tried recompiling libSDL to enable kmsdrm per the directions for Kivy:

https://kivy.org/doc/master/installation/installation-rpi.html#raspberry-pi-1-4-installation-on-raspbian-jessie-stretch-buster

but I don't think that change was significant (given that I'm still setting SDL_VIDEODRIVER to fbcon).

LoveBootCaptain commented 3 years ago

RaspianOS is currently not supported for WasperPi_TFT. I will update the readme concerning that issue.