Waveshare GamePi20

[willyside]

Hello,

I've been enjoying Moode on a number of devices since about 2018. Thank you for all of your hard work! 

I recently tried to setup a Waveshare GamePi20 as a portable media player using Moode 8.2.4, running on a Pi Zero W. I have been been able to get most things to work (8 of the buttons, connections to various BT speakers and headphones, HDMI output if I desire), but the built-in SPI screen has been a bit of a bear. I have followed the instructions on Waveshare's wiki and gotten fbcp-ili9341 compiled, running, and showing the console for a few seconds after boot (if the fbcp-ili9341 executable is setup to run from rc.local). But then the SPI screen freezes (doesn't go blank, but the input cursor stops blinking). Connecting an HDMI display, I can see that the SPI screen freeze corresponds to the same time as the HDMI's console going blank a few seconds after boot. This is the case whether local UI is enabled or not, though if local UI is enabled, the SPI screen remains frozen after the GUI has come up on the HDMI display. 

If instead of launching the fbcp-ili9341 executable from rc.local, I ssh into the player and run said executable from the command line after the HDMI display's GUI has come up, the GUI then does show up on the SPI display, as well. 

Further, even when I don't run the fbcp-ili9341 executable, if local UI is not enabled in Moode, the HDMI console goes blank a few seconds after boot. 

If instead of running Moode, I install the latest version of Raspberry Pi OS via NOOB, and then compile and install fbcp-ili9341, the SPI screen does not freeze (with fbcp-ili9341 running from rc.local); rather, it continues to show an active console or the XWindows GUI, as would be shown on an HDMI display if it was connected. 

Given all this, it seems that Moode is doing something to perhaps reset the framebuffer (device?) a few seconds after bootup, and fbcp-ili9341 is losing its connection to the framebuffer. I have contemplated putting in a sleep statement (maybe 10 seconds) before launching fbcp-ili9341 near the end of rc.local. It's not clear to me if whatever happens to the framebuffer device will just wait until rc.local has exited to happen, though, and I'm not home to test it right now. 

Questions:
1) What code could I change to keep the HDMI display's console from going blank after boot if local UI is not enabled? (I'm hoping this will keep it from freezing on the SPI display, with the HDMI display connected; once I've achieved this, I'll start working on getting first the command line and later the GUI to show up on the SPI screen without the HDMI display connected.) 
2) If getting the HDMI console to remain doesn't keep the SPI screen from freezing a few seconds after boot, and my idea of adding the sleep statement to rc.local doesn't help, is it possible to launch the fbcp-ili9341 executable during X-Windows startup instead of from rc.local? If so, would .xinitrc be the place to try it? 
3) Which source files/database entries might I add/modify to give support for 12 buttons via GPIO, instead of 8? I'd prefer to able to setup the additional GPIO lines via the same gui as the first 8, but if this is too much work, I'm willing to do it via script/cli. 

I know this was a long message; thank you for your patience! 

Regards,
William

[Tim Curtis]

"3) Which source files/database entries might I add/modify to give support for 12 buttons via GPIO, instead of 8? I'd prefer to able to setup the additional GPIO lines via the same gui as the first 8, but if this is too much work, I'm willing to do it via script/cli."

Code:

/var/www/daemon/gpio_buttons.py
/var/www/templates/gpio-config.html
/var/www/gpio-config.php
cfg_gpio SQL table (moodeutl -q "select * from cfg_gpio")

Regarding the screen going blank after login prompt briefly appears, IIRC this has to do with a config on the Lite version of RaspiOS that changes the getty target -- because it's meant to be headless and accessed only via SSH -- Something like that.

As far as getting your screen configured with its driver etc before moOde worker.php starts LocalUI (xinitrc) I would think that loading the driver from rc.local before the line that starts worker.php should work but I don't know what that driver does or wants so YMMV.

moOde startup sequence is as follows:

Code:

Linux boot -> rc.local -> /var/www/daemon/worker.php -> systemctl start local -> /usr/bin/xinit