tty2rpi Add-On (shows core based pictures and videos on a HDMI or DSI display)

[MiSTer Consoles]

Hi all. I've finally gone down the rabbit hole of setting up a Raspberry Pi Zero 2 W so that I can use tty2rpi on a 3.5" 480x320 display. It has definitely been a bumpy road so far. I have Unifi network equipment and the WiFi chip on the Pi Zero seems to be a little picky about my setup. It is 2.4GHz only, so I had to place it on a VLAN I have that utilizes this band only and not 5GHz. I also had to disable a setting called PMF as well as BSS Transition which the Pi didn't seem to be compatible with. Once I was finally able to connect to my network I could not get SFTP or SSH to work. I ended up having to add the line IPQoS 0x00 to /etc/ssh/sshd_config. The funny thing is that this step wasn't required on a Pi 3B+ which I ultimately had to use to get to the "sshd_config" file in order to modify it. LOL!

I finally got to the point where I could start downloading the necessary files for the Pi and tty2rpi. Initially I tried to give mine a name/PW other than "tty2rpi ". Then I realized that this was preventing the program from auto-logging in at startup. It might be good to update the documentation to be more explicit about that. Once I got to the point where all the necessary files were installed I attempted to make the required changes to /boot/config.txt outlined below. When I commented out dtoverlay=vc4-kms-v3d the auto-login process failed for some reason. I had to uncomment it again for that process to work. Has anyone else experienced this problem?

...
#dtoverlay=vc4-kms-v3d
...
[all]
disable_splash=1
boot_delay=0
gpu_mem=128

There's a blurb in the setup regarding /etc/X11/xorg.conf.d/10-monitor.conf -- Monitor config to disable DPMS. I saw online that the text below might need to be added to disable DPMS. Is this required?

Section "Monitor"
Option "DPMS" "false"
EndSection

I've got WiFi working just fine on my device. Is it required to create the wlan.nmconnection file and add that to the /etc/NetworkManager/system-connections/ folder?

I've still got the MiSTer setup to work on as well as the settings for the smaller display I'm using which utilizes the GPIO pins. I didn't find an exact match for this size screen in the config.txt.example file. The one listed below seems to be the closest. Should I be compiling that driver and using these settings in the config file?

NoName MHS 3.5" 480x240 (SKU: MHS3528) (waveshare dto)

• Using https://github.com/juj/fbcp-ili9341
  Compile fbcp-ili9341 with 'cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_ROTATE_180_DEGREES=ON -DSTATISTICS=0 ..'
  • Set FBUFDEV="yes" and FBDEVICE="/dev/fb0" in tty2rpi-user.ini
• Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile
  dtoverlay=waveshare35a,rotate=270
  hdmi_group=2
  hdmi_mode=87
  hdmi_cvt=480 320 60 1 0 0 0
  hdmi_force_hotplug=1

[RealLarry]

Hi all. I've finally gone down the rabbit hole of setting up a Raspberry Pi Zero 2 W so that I can use tty2rpi on a 3.5" 480x320 display. It has definitely been a bumpy road so far. I have Unifi network equipment and the WiFi chip on the Pi Zero seems to be a little picky about my setup. It is 2.4GHz only, so I had to place it on a VLAN I have that utilizes this band only and not 5GHz. I also had to disable a setting called PMF as well as BSS Transition which the Pi didn't seem to be compatible with. Once I was finally able to connect to my network I could not get SFTP or SSH to work. I ended up having to add the line IPQoS 0x00 to /etc/ssh/sshd_config. The funny thing is that this step wasn't required on a Pi 3B+ which I ultimately had to use to get to the "sshd_config" file in order to modify it. LOL!

Lucky to hear that you got WiFi problem solved, but sad to hear that there is such "unusual" equipment out there which is giving headache.

I finally got to the point where I could start downloading the necessary files for the Pi and tty2rpi. Initially I tried to give mine a name/PW other than "tty2rpi ". Then I realized that this was preventing the program from auto-logging in at startup. It might be good to update the documentation to be more explicit about that.

Yeah, I'll better point this out not to change the username. This doesn't make sense to change it for a non productive device.

Once I got to the point where all the necessary files were installed I attempted to make the required changes to /boot/config.txt outlined below. When I commented out dtoverlay=vc4-kms-v3d the auto-login process failed for some reason. I had to uncomment it again for that process to work. Has anyone else experienced this problem?

...
#dtoverlay=vc4-kms-v3d
...
[all]
disable_splash=1
boot_delay=0
gpu_mem=128

The vc4-kms-v3d is for Raspberry's own GPU when using HDMI or a DPI/DSI device. Don't turn this on when using a simple framebuffer device like yours linked below.

There's a blurb in the setup regarding /etc/X11/xorg.conf.d/10-monitor.conf -- Monitor config to disable DPMS. I saw online that the text below might need to be added to disable DPMS. Is this required?

Section "Monitor"
Option "DPMS" "false"
EndSection

What blurp? The file /etc/X11/xorg.conf.d/10-monitor.conf is created when installing tty2rpi by update_tty2rpi.sh and this is documented in the manual - or is it mentioned misleading there?

I've got WiFi working just fine on my device. Is it required to create the wlan.nmconnection file and add that to the /etc/NetworkManager/system-connections/ folder?

Creating the file wlan.nmconnection is only needed when upgrading from Debian Bullseye to Bookworm. If you have used the Raspberry Imager to setup and write the Debian Bookworm image to the SD, wlan.nmconnection is automagically created with your given credentials.

I've still got the MiSTer setup to work on as well as the settings for the smaller display I'm using which utilizes the GPIO pins. I didn't find an exact match for this size screen in the config.txt.example file. The one listed below seems to be the closest. Should I be compiling that driver and using these settings in the config file?

NoName MHS 3.5" 480x240 (SKU: MHS3528) (waveshare dto)

• Using https://github.com/juj/fbcp-ili9341
  Compile fbcp-ili9341 with 'cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_ROTATE_180_DEGREES=ON -DSTATISTICS=0 ..'
  • Set FBUFDEV="yes" and FBDEVICE="/dev/fb0" in tty2rpi-user.ini
• Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile
  dtoverlay=waveshare35a,rotate=270
  hdmi_group=2
  hdmi_mode=87
  hdmi_cvt=480 320 60 1 0 0 0
  hdmi_force_hotplug=1

Ha, dam'it, that's a (now fixed) typo and should read 480x320
To use this display (of which I'm thinking that yours is the same as the mentioned MHS3528) go to your HOME directory (usually tty2rpi) on the RPi and clone the git repository to there. Compile the program and set parameters as described above, reboot and it should work (hopefully).

Yeah I know that there some hurdles to climb and a documentation is never finished or 100% acurate. That's why I'm pointing about "I assume that you are already familiar with setting up a Raspberry Pi"

[MiSTer Consoles]

Hi all. I've finally gone down the rabbit hole of setting up a Raspberry Pi Zero 2 W so that I can use tty2rpi on a 3.5" 480x320 display. It has definitely been a bumpy road so far. I have Unifi network equipment and the WiFi chip on the Pi Zero seems to be a little picky about my setup. It is 2.4GHz only, so I had to place it on a VLAN I have that utilizes this band only and not 5GHz. I also had to disable a setting called PMF as well as BSS Transition which the Pi didn't seem to be compatible with. Once I was finally able to connect to my network I could not get SFTP or SSH to work. I ended up having to add the line IPQoS 0x00 to /etc/ssh/sshd_config. The funny thing is that this step wasn't required on a Pi 3B+ which I ultimately had to use to get to the "sshd_config" file in order to modify it. LOL!

Lucky to hear that you got WiFi problem solved, but sad to hear that there is such "unusual" equipment out there which is giving headache.

Seems like this is unique to the Pi Zero devices which can't use the 5GHz band. Apparently they went cheap on the WiFi chip to reduce cost. As they say "You get what you pay for". LOL!

I finally got to the point where I could start downloading the necessary files for the Pi and tty2rpi. Initially I tried to give mine a name/PW other than "tty2rpi ". Then I realized that this was preventing the program from auto-logging in at startup. It might be good to update the documentation to be more explicit about that.

Yeah, I'll better point this out not to change the username. This doesn't make sense to change it for a non productive device.

Thanks!

Once I got to the point where all the necessary files were installed I attempted to make the required changes to /boot/config.txt outlined below. When I commented out dtoverlay=vc4-kms-v3d the auto-login process failed for some reason. I had to uncomment it again for that process to work. Has anyone else experienced this problem?

...
#dtoverlay=vc4-kms-v3d
...
[all]
disable_splash=1
boot_delay=0
gpu_mem=128

The vc4-kms-v3d is for Raspberry's own GPU when using HDMI or a DPI/DSI device. Don't turn this on when using a simple framebuffer device like yours linked below.

I see. I will make sure to disable it when I'm using the little screen.

There's a blurb in the setup regarding /etc/X11/xorg.conf.d/10-monitor.conf -- Monitor config to disable DPMS. I saw online that the text below might need to be added to disable DPMS. Is this required?

Section "Monitor"
Option "DPMS" "false"
EndSection

What blurp? The file /etc/X11/xorg.conf.d/10-monitor.conf is created when installing tty2rpi by update_tty2rpi.sh and this is documented in the manual - or is it mentioned misleading there?

I thought I needed to take some action there. Perhaps it could be stated as Monitor config file that disables DPMS or maybe not even mentioned? Would users like me ever need to do anything with that file?

I've got WiFi working just fine on my device. Is it required to create the wlan.nmconnection file and add that to the /etc/NetworkManager/system-connections/ folder?

Creating the file wlan.nmconnection is only needed when upgrading from Debian Bullseye to Bookworm. If you have used the Raspberry Imager to setup and write the Debian Bookworm image to the SD, wlan.nmconnection is automagically created with your given credentials.

Gotcha. I won't worry about that then.

I've still got the MiSTer setup to work on as well as the settings for the smaller display I'm using which utilizes the GPIO pins. I didn't find an exact match for this size screen in the config.txt.example file. The one listed below seems to be the closest. Should I be compiling that driver and using these settings in the config file?

NoName MHS 3.5" 480x240 (SKU: MHS3528) (waveshare dto)

• Using https://github.com/juj/fbcp-ili9341
  Compile fbcp-ili9341 with 'cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_ROTATE_180_DEGREES=ON -DSTATISTICS=0 ..'
  • Set FBUFDEV="yes" and FBDEVICE="/dev/fb0" in tty2rpi-user.ini
• Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile
  dtoverlay=waveshare35a,rotate=270
  hdmi_group=2
  hdmi_mode=87
  hdmi_cvt=480 320 60 1 0 0 0
  hdmi_force_hotplug=1

Ha, dam'it, that's a (now fixed) typo and should read 480x320
To use this display (of which I'm thinking that yours is the same as the mentioned MHS3528) go to your HOME directory (usually tty2rpi) on the RPi and clone the git repository to there. Compile the program and set parameters as described above, reboot and it should work (hopefully).

Yeah I know that there some hurdles to climb and a documentation is never finished or 100% acurate. That's why I'm pointing about "I assume that you are already familiar with setting up a Raspberry Pi"

Sounds good. I will give it a try this afternoon. Unfortunately I'm a complete noob when it comes to these devices. I am a very willing learner though and know that this type of knowledge will be useful for other RPi/Linux setups. I know you are very patient with my questions and I am always very appreciative of your help. Thanks again!

[MiSTer Consoles]

I've still got the MiSTer setup to work on as well as the settings for the smaller display I'm using which utilizes the GPIO pins. I didn't find an exact match for this size screen in the config.txt.example file. The one listed below seems to be the closest. Should I be compiling that driver and using these settings in the config file?

NoName MHS 3.5" 480x240 (SKU: MHS3528) (waveshare dto)

• Using https://github.com/juj/fbcp-ili9341
  Compile fbcp-ili9341 with 'cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_ROTATE_180_DEGREES=ON -DSTATISTICS=0 ..'
  • Set FBUFDEV="yes" and FBDEVICE="/dev/fb0" in tty2rpi-user.ini
• Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile
  dtoverlay=waveshare35a,rotate=270
  hdmi_group=2
  hdmi_mode=87
  hdmi_cvt=480 320 60 1 0 0 0
  hdmi_force_hotplug=1

Ha, dam'it, that's a (now fixed) typo and should read 480x320
To use this display (of which I'm thinking that yours is the same as the mentioned MHS3528) go to your HOME directory (usually tty2rpi) on the RPi and clone the git repository to there. Compile the program and set parameters as described above, reboot and it should work (hopefully).

I followed the sequence of commands below that were on the GitHub page for the fbcp-ili9341 driver. When I ran the make -j command there were a whole lot of errors that showed up. Should I be doing those last two steps or do I stop at the cmake... step in the process?

sudo apt-get install cmake
cd ~
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341
mkdir build
cd build
cmake [options] ..
make -j
sudo ./fbcp-ili9341

Also, I don't see this file anywhere in the tty2rpi directory:

Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile

[RealLarry]

Documentation updated. I'd be glad if you could take a minute to have a look at it.

I followed the sequence of commands below that were on the GitHub page for the fbcp-ili9341 driver. When I ran the make -j command there were a whole lot of errors that showed up. Should I be doing those last two steps or do I stop at the cmake... step in the process?

sudo apt-get install cmake
cd ~
git clone https://github.com/juj/fbcp-ili9341.git
cd fbcp-ili9341
mkdir build
cd build
cmake [options] ..
make -j
sudo ./fbcp-ili9341

Also, I don't see this file anywhere in the tty2rpi directory:

Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile

Yeah, that definitely goes to the "I assume that you are already familiar with setting up a Raspberry Pi". In the standard setup/installation of the OS there is missing anything to compile something. I left this out to save time and space for those who aren't using a framebuffer device and therefore haven't a need for that bunch of software packages.
I'll send you a ready-to-run binary of fbcp-ili9341 which goes into the same named directory.
The file .bash_profile is a hidden file (marked by the dot at the beginning of a file). Best practice to navigate through the directory structure and to edit (even hidden) files is the program mc (already installed ). It's a clone of the good ole Norton Commander.

[RealLarry]

Bugfix update!

Changelog:

• Instructions for simple framebuffer devices in config.txt.example how to compile fbcp-ili9341

• New INI parameter: USEFBCP (whether to use fbcp-ili9341 or not, defaults to "no")

• New INI parameter: FBPIXFMT (Configurable Pixel Format for ffmpeg in tty2rpi-user.ini. Depends on framebuffer display - see https://ffmpeg.org/ffmpeg.html#Advanced-Video-options)

[MiSTer Consoles]

Yeah, that definitely goes to the "I assume that you are already familiar with setting up a Raspberry Pi". In the standard setup/installation of the OS there is missing anything to compile something. I left this out to save time and space for those who aren't using a framebuffer device and therefore haven't a need for that bunch of software packages.
I'll send you a ready-to-run binary of fbcp-ili9341 which goes into the same named directory.
The file .bash_profile is a hidden file (marked by the dot at the beginning of a file). Best practice to navigate through the directory structure and to edit (even hidden) files is the program mc (already installed ). It's a clone of the good ole Norton Commander.

I see. Makes sense why I could not locate that file. LOL! I'm a Windows user so I definitely like my programs with a point and click GUI, but I will try to get in the habit of using MC when doing editing. It definitely seems necessary on system files like config.txt where you have to edit as the admin.

Bugfix update!

Changelog:

• Instructions for simple framebuffer devices in config.txt.example how to compile fbcp-ili9341

• New INI parameter: USEFBCP (whether to use fbcp-ili9341 or not, defaults to "no")

• New INI parameter: FBPIXFMT (Configurable Pixel Format for ffmpeg in tty2rpi-user.ini. Depends on framebuffer display - see https://ffmpeg.org/ffmpeg.html#Advanced-Video-options)

I updated tty2rpi on the RPi this morning using the update_tty2rpi.sh script. I noticed that it overwrote the custom graphics I had placed in the tty2rpi-pics folder. Is it possible to prevent that somehow or do I need to create a new folder and then change the path TTY2RPIPICS="New Folder" in the tty2rpi-user.ini file?

[RealLarry]

I updated tty2rpi on the RPi this morning using the update_tty2rpi.sh script. I noticed that it overwrote the custom graphics I had placed in the tty2rpi-pics folder. Is it possible to prevent that somehow or do I need to create a new folder and then change the path TTY2RPIPICS="New Folder" in the tty2rpi-user.ini file?

Yes, just use the variable TTY2RPIPICS in tty2rpi-user.ini
This is a new function and only mentioned here for now. It is always a good idea to have a look at tty2rpi.ini. There, after the lines

# DO NOT CHANGE ANYTHING ABOVE
#If you want to change a setting below (Userdata), enable and edit that line in tty2rpi-user.ini
#----------------------------
#Userdata

you can see all used variables and a short description about them. And respect the hint of enable and edit that line in tty2rpi-user.ini: Any changed setting tty2rpi.ini will be overwritten on next update, which happens every Friday at a random time. Means that you have to copy 'n paste the according line to tty2rpi-user.ini to set it/them permanently.

[MiSTer Consoles]

I updated tty2rpi on the RPi this morning using the update_tty2rpi.sh script. I noticed that it overwrote the custom graphics I had placed in the tty2rpi-pics folder. Is it possible to prevent that somehow or do I need to create a new folder and then change the path TTY2RPIPICS="New Folder" in the tty2rpi-user.ini file?

Yes, just use the variable TTY2RPIPICS in tty2rpi-user.ini
This is a new function and only mentioned here for now. It is always a good idea to have a look at tty2rpi.ini. There, after the lines

# DO NOT CHANGE ANYTHING ABOVE
#If you want to change a setting below (Userdata), enable and edit that line in tty2rpi-user.ini
#----------------------------
#Userdata

you can see all used variables and a short description about them. And respect the hint of enable and edit that line in tty2rpi-user.ini: Any changed setting tty2rpi.ini will be overwritten on next update, which happens every Friday at a random time. Means that you have to copy 'n paste the according line to tty2rpi-user.ini to set it/them permanently.

Got it. Thanks again!

[RealLarry]

Even if it works now/later for your satisfaction, I'd be glad to hear that too

[MiSTer Consoles]

I think I'm getting close. The last step I need to do according to config.txt.example is to "Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile". I found the file in MC and went to edit it. There is only one line that is commented out. Do I just need to remove the hashtag on that line or is there something else that needs to be done?

By the way I created a new folder called tty2rpi-mypics, placed my custom images in there, and then added the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" to the tty2rpi-user.ini file. For some reason the program still displayed the default ones. Could this be a bug or did I do something wrong here?

[RealLarry]

I think I'm getting close. The last step I need to do according to config.txt.example is to "Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile". I found the file in MC and went to edit it. There is only one line that is commented out. Do I just need to remove the hashtag on that line or is there something else that needs to be done?

By the way I created a new folder called tty2rpi-mypics, placed my custom images in there, and then added the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" to the tty2rpi-user.ini file. For some reason the program still displayed the default ones. Could this be a bug or did I do something wrong here?

Forget about "Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile", this is obsolete and replaced by todays update (just run ./update_tty2rpi.sh when logged in per ssh/putty). This enables two new variables for your tty2rpi-user.ini and your display:
USEFBCP - set to "yes" to enable the use of fbcp-ili9341 (needed for your display)
FBPIXFMT - defaults to "rgb565le", could also be "bgra". This depends on the display and its controller (also needed for your display)

[MiSTer Consoles]

I think I'm getting close. The last step I need to do according to config.txt.example is to "Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile". I found the file in MC and went to edit it. There is only one line that is commented out. Do I just need to remove the hashtag on that line or is there something else that needs to be done?

By the way I created a new folder called tty2rpi-mypics, placed my custom images in there, and then added the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" to the tty2rpi-user.ini file. For some reason the program still displayed the default ones. Could this be a bug or did I do something wrong here?

Forget about "Enable fbcp-ili9341 in /home/tty2rpi/.bash_profile", this is obsolete and replaced by todays update (just run ./update_tty2rpi.sh when logged in per ssh/putty). This enables two new variables for your tty2rpi-user.ini and your display:
USEFBCP - set to "yes" to enable the use of fbcp-ili9341 (needed for your display)
FBPIXFMT - defaults to "rgb565le", could also be "bgra". This depends on the display and its controller (also needed for your display)

Sorry. I was looking at the old copy of the example config.txt file. I did run the update script earlier this morning. Here is what I have in my tty2rpi-user.ini file:

FBUFDEV="yes"
FBDEVICE="/dev/fb0"
USEFBCP="yes"
TTY2RPIPICS="${HOME}/tty2rpi-mypics"

I commented these lines out in config.txt:

#Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d
#max_framebuffers=2

I add this section to that file as well:

#NoName MHS 3.5" 480x320 (SKU: MHS3528) (waveshare dto)
#Using https://github.com/juj/fbcp-ili9341
#Install needed packages: 'sudo apt-get install libraspberrypi-dev raspberrypi-kernel-headers cmake'
#Compile fbcp-ili9341 with 'cmake -DSPI_BUS_CLOCK_DIVISOR=6 -DWAVESHARE35B_ILI9486=ON -DDISPLAY_ROTATE_180_DEGREES=ON -DSTATISTICS=0 ..'
#- Set FBUFDEV="yes", FBDEVICE="/dev/fb0" and USEFBCP="yes" in tty2rpi-user.ini
dtoverlay=waveshare35a,rotate=270
hdmi_group=2
hdmi_mode=87
hdmi_cvt=480 320 60 1 0 0 0
hdmi_force_hotplug=1

The screen goes from bright white to dark when booting, but no image is displayed. I'm using the NOTROTATED binary you sent me which is in the build folder and has been made executable with the chmod command. I also have the waveshare35a.dtbo file in /boot/firmware/overlays (the overlays icon in the boot folder is just a shortcut to the directory in the boot/firmware folder).

Am I missing anything here?

[RealLarry]

Am I missing anything here?

Hmm...no, everything is looking correct. You could enable max_framebuffers=2 again; don't know for what case it is or not. I have it still enabled for all displays. It is also correct that the screen turns black while booting. This indicates to me that the waveshare35a driver is loaded and initialized the display.
Every fbcp-ili9341 is fine, if it's the wrong one, the display will work, at worst turned wrong.

Gimme some extra time to debug. Maybe your display is not using the waveshare driver - but I've found a never opened/used display which looks exact like yours.

In the meantime you could have a look at your OS log. Connect to your RPi and type

Code: Select all

sudo journalctl -b

You then can navigate with up/down and page up/page down through the log. What I'm looking for is

Feb 22 11:59:19 tty2rpi4 kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned.
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned.
Feb 22 11:59:19 tty2rpi4 kernel: SPI driver fb_ili9486 has no spi_device_id for ilitek,ili9486
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: regwidth = 16
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: buswidth = 8
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: debug = 0
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: rotate = 270
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: fps = 30
Feb 22 11:59:19 tty2rpi4 kernel: fb_ili9486 spi0.0: fbtft_property_value: txbuflen = 32768

This is the output of my working Waveshare 480x320 ...

[MiSTer Consoles]

Here are the details from my log:

Feb 22 08:17:04 raspberrypi kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned.
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486: module is from the staging directory, the quality is unknown, you have been warned.
Feb 22 08:17:04 raspberrypi systemd[1]: Mounted proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System.
Feb 22 08:17:04 raspberrypi kernel: SPI driver fb_ili9486 has no spi_device_id for ilitek,ili9486
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video13
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video14
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video15
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video16
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register output node 0 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
Feb 22 08:17:04 raspberrypi systemd[1]: Finished systemd-binfmt.service - Set Up Additional Binary Formats.
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: regwidth = 16
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: buswidth = 8
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: debug = 0
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: rotate = 270
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: fps = 30
Feb 22 08:17:04 raspberrypi kernel: fb_ili9486 spi0.0: fbtft_property_value: txbuflen = 32768
Feb 22 08:17:04 raspberrypi kernel: Bluetooth: HCI UART driver ver 2.3
Feb 22 08:17:04 raspberrypi kernel: Bluetooth: HCI UART protocol H4 registered
Feb 22 08:17:04 raspberrypi kernel: Bluetooth: HCI UART protocol Three-wire (H5) registered
Feb 22 08:17:04 raspberrypi kernel: Bluetooth: HCI UART protocol Broadcom registered
Feb 22 08:17:04 raspberrypi (udev-worker)[263]: event1: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.
Feb 22 08:17:04 raspberrypi kernel: hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator
Feb 22 08:17:04 raspberrypi kernel: hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator
Feb 22 08:17:04 raspberrypi kernel: ads7846 spi0.1: supply vcc not found, using dummy regulator
Feb 22 08:17:04 raspberrypi kernel: ads7846 spi0.1: touchscreen, irq 184
Feb 22 08:17:04 raspberrypi kernel: input: ADS7846 Touchscreen as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/input/input17
Feb 22 08:17:04 raspberrypi (udev-worker)[260]: event0: Process '/usr/sbin/th-cmd --socket /var/run/thd.socket --passfd --udev' failed with exit code 1.
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node output[0] registered as /dev/video20
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node capture[0] registered as /dev/video21
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node capture[1] registered as /dev/video22
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Device node stats[2] registered as /dev/video23
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register output node 0 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 1 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 2 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Register capture node 3 with media controller
Feb 22 08:17:04 raspberrypi kernel: bcm2835-isp bcm2835-isp: Loaded V4L2 bcm2835-isp

I went a little further down because I saw some mention of "touchscreen" which this display has apparently. I did enable max_framebuffers=2 again, but that didn't seem to make a difference.

[RealLarry]

I'm still investigating but had no luck 'til now.
This is what my "found" display is looking like. Not exact the same but I'm sure that is technically the same.

yours.jpg

And that seems to be the pity. Seems like these very cheap ones are using a XPT2046 and MPI3501 controller they warn against using them (have a look at the chapter below the table where they're talking about MPI3501).

[MiSTer Consoles]

I'm still investigating but had no luck 'til now.
This is what my "found" display is looking like. Not exact the same but I'm sure that is technically the same.
yours.jpg
And that seems to be the pity. Seems like these very cheap ones are using a XPT2046 and MPI3501 controller they warn against using them (have a look at the chapter below the table where they're talking about MPI3501).

Thanks for looking into this. Hopefully there is a way to get it to work. I've got plenty of time to return it to Amazon if it isn't compatible. However, I ordered a similar non-touch display off AliExpress that I'll be stuck with either way. LOL! I don't need or really want the touch function. I just want the display to show the core/game artwork.

[RealLarry]

Thanks for looking into this. Hopefully there is a way to get it to work. I've got plenty of time to return it to Amazon if it isn't compatible. However, I ordered a similar non-touch display off AliExpress that I'll be stuck with either way. LOL! I don't need or really want the touch function. I just want the display to show the core/game artwork.

We will see. This display is driven by a HX8357D which could be compatible with one of the available drivers.
One my cheap displays is the MHS which is driven by the (unofficially) waveshare driver I gave you yesterday. Not the fastest and compatibility for future OS version is unknown, but it is confirmed working.
The best option(s) are HDMI/DPI/DSI displays. Not that cheap but way faster (including GPU acceleration) and officially supported by the Raspberry/Debian OS.

[MiSTer Consoles]

Thanks for looking into this. Hopefully there is a way to get it to work. I've got plenty of time to return it to Amazon if it isn't compatible. However, I ordered a similar non-touch display off AliExpress that I'll be stuck with either way. LOL! I don't need or really want the touch function. I just want the display to show the core/game artwork.

We will see. This display is driven by a HX8357D which could be compatible with one of the available drivers.
One my cheap displays is the MHS which is driven by the (unofficially) waveshare driver I gave you yesterday. Not the fastest and compatibility for future OS version is unknown, but it is confirmed working.
The best option(s) are HDMI/DPI/DSI displays. Not that cheap but way faster (including GPU acceleration) and officially supported by the Raspberry/Debian OS.

That MHS screen might be a good alternative if these displays with the HX8357D controller don't work out. As far as performance goes I'm just looking for something faster/more reliable than the Uno boards used for tty2tft. The Unos do work surprisingly well for the price. However, with the new per-game functionality they do get bogged down when making transitions. Not to mention that SSH doesn't really work well with all the image files on the SD card. That makes it tough to add/edit files while the display is enclosed in a case.

By the way is it possible to have an image displayed as the Raspberry Pi is booting instead of viewing all the messages? That's definitely something I enjoy about tty2tft. I get a graphic right as MiSTer is powered on.

[RealLarry]

Thanks for looking into this. Hopefully there is a way to get it to work. I've got plenty of time to return it to Amazon if it isn't compatible. However, I ordered a similar non-touch display off AliExpress that I'll be stuck with either way. LOL! I don't need or really want the touch function. I just want the display to show the core/game artwork.

We will see. This display is driven by a HX8357D which could be compatible with one of the available drivers.
One my cheap displays is the MHS which is driven by the (unofficially) waveshare driver I gave you yesterday. Not the fastest and compatibility for future OS version is unknown, but it is confirmed working.
The best option(s) are HDMI/DPI/DSI displays. Not that cheap but way faster (including GPU acceleration) and officially supported by the Raspberry/Debian OS.

That MHS screen might be a good alternative if these displays with the HX8357D controller don't work out. As far as performance goes I'm just looking for something faster/more reliable than the Uno boards used for tty2tft. The Unos do work surprisingly well for the price. However, with the new per-game functionality they do get bogged down when making transitions. Not to mention that SSH doesn't really work well with all the image files on the SD card. That makes it tough to add/edit files while the display is enclosed in a case.

The displays for the tty2tft are fast enough (more or less). It's the ESP which is to slow to play videos and to react in adequate time in general. Even when I'm happy with them too, I thought it is time for the next generation

By the way is it possible to have an image displayed as the Raspberry Pi is booting instead of viewing all the messages? That's definitely something I enjoy about tty2tft. I get a graphic right as MiSTer is powered on.

Yes, this is called "plymouth" and is disabled for now. While this working great on a PC I had some hurdles to get it working fine on the RPi, but it is on the ToDo list but not available for framebuffer displays because its initialization happens at a very late stage.
If you can see tons of messages while booting up the RPi you should set the parameter "quiet" in /boot/cmdline.txt - then you'll see almost nothing 'til entering the "tty2rpi stage". As an example:

Code: Select all

console=serial0,115200 console=tty3 root=PARTUUID=94e1907d-02 rootfstype=ext4 fsck.repair=yes rootwait quiet cfg80211.ieee80211_regdom=COUNTRYCODE

Don't change PARTUUID but if not done yet, change COUNTRYCODE to yours, which is US.

[MiSTer Consoles]

By the way is it possible to have an image displayed as the Raspberry Pi is booting instead of viewing all the messages? That's definitely something I enjoy about tty2tft. I get a graphic right as MiSTer is powered on.

Yes, this is called "plymouth" and is disabled for now. While this working great on a PC I had some hurdles to get it working fine on the RPi, but it is on the ToDo list but not available for framebuffer displays because its initialization happens at a very late stage.
If you can see tons of messages while booting up the RPi you should set the parameter "quiet" in /boot/cmdline.txt - then you'll see almost nothing 'til entering the "tty2rpi stage". As an example:

Code: Select all

console=serial0,115200 console=tty3 root=PARTUUID=94e1907d-02 rootfstype=ext4 fsck.repair=yes rootwait quiet cfg80211.ieee80211_regdom=COUNTRYCODE

Don't change PARTUUID but if not done yet, change COUNTRYCODE to yours, which is US.

I did enable the quiet option in the cmdline.txt file, so the messages are greatly reduced which helps. I also have COUNTRYCODE set to "US" as well in there. Are there displays that connect via the GPIO pins that don't use the framebuffer? I have some space constraints in my cases that make it challenging to use the HDMI port on most displays.

[RealLarry]

Are there displays that connect via the GPIO pins that don't use the framebuffer? I have some space constraints in my cases that make it challenging to use the HDMI port on most displays.

Not I'm aware off. Use a DPI or DSI display if HDMI isn't an option. They are assembled in the same way (plug'n'play).

[MiSTer Consoles]

Are there displays that connect via the GPIO pins that don't use the framebuffer? I have some space constraints in my cases that make it challenging to use the HDMI port on most displays.

Not I'm aware off. Use a DPI or DSI display if HDMI isn't an option. They are assembled in the same way (plug'n'play).

It looks like the DPI displays connect to the Pi via the 40 pin GPIO connector according to this document. Is that correct? If so, are those screens capable of using this "Plymouth" function you mentioned to display an image during boot or is that only possible through screens attached via the HDMI port?

[RealLarry]

Are there displays that connect via the GPIO pins that don't use the framebuffer? I have some space constraints in my cases that make it challenging to use the HDMI port on most displays.

Not I'm aware off. Use a DPI or DSI display if HDMI isn't an option. They are assembled in the same way (plug'n'play).

It looks like the DPI displays connect to the Pi via the 40 pin GPIO connector according to this document. Is that correct? If so, are those screens capable of using this "Plymouth" function you mentioned to display an image during boot or is that only possible through screens attached via the HDMI port?

Correct, they're getting connected to RPi's GPIO connector. They are starting to show a "picture" (= Plymouth, Text, whatever) a short time after Kernels start and reading the /boot/config.txt

• HDMI is "driverless" and displaying everything after connecting the power ssource.

• DPI/DSI needs a driver and an initialization, then they (can) working together with HDMI, ie Dual Display

• Framebuffer needs a driver, an initialization and a redirection program. HDMI is still the primary display and we are working with it (set to the resolution of the framebuffer display). That is what fbcp-ili9341 is doing: It mirrors HDMI to Framebuffer.

In fact there are ways to display/redirect data to the framebuffer right after loading a driver and its initialization, but this making things more complex and complicated, and I can't (easyily) intervene into the boot process. Maybe I'll come back later to this issue.

[RealLarry]

Small update

Changelog:

• Search for filenames with at least three caracters, not two. This speeds up searching and lowers the risk of misinterpretation

• The INI variable KEEPASPECTRATIO is now undefined per default. The picture viewers feh/fim are now auto scaling a picture to screen's size. This speeds up displaying a picture a lot!
  Setting KEEPASPECTRATIO to yes/no/x/y re-enables pre-scaling.

[MiSTer Consoles]

Not I'm aware off. Use a DPI or DSI display if HDMI isn't an option. They are assembled in the same way (plug'n'play).

It looks like the DPI displays connect to the Pi via the 40 pin GPIO connector according to this document. Is that correct? If so, are those screens capable of using this "Plymouth" function you mentioned to display an image during boot or is that only possible through screens attached via the HDMI port?

Correct, they're getting connected to RPi's GPIO connector. They are starting to show a "picture" (= Plymouth, Text, whatever) a short time after Kernels start and reading the /boot/config.txt

• HDMI is "driverless" and displaying everything after connecting the power ssource.

• DPI/DSI needs a driver and an initialization, then they (can) working together with HDMI, ie Dual Display

• Framebuffer needs a driver, an initialization and a redirection program. HDMI is still the primary display and we are working with it (set to the resolution of the framebuffer display). That is what fbcp-ili9341 is doing: It mirrors HDMI to Framebuffer.

In fact there are ways to display/redirect data to the framebuffer right after loading a driver and its initialization, but this making things more complex and complicated, and I can't (easyily) intervene into the boot process. Maybe I'll come back later to this issue.

Thanks for the explanation! This stuff is all very new to me and I enjoy learning about it. Sounds like an HDMI display is the most ideal for this project. I will have to keep exploring other options that I might be able to use in my boxes. Perhaps I can increase the height of the box to accommodate for the port + adapter to connect the display to the Pi.

[RealLarry]

Sounds like an HDMI display is the most ideal for this project. I will have to keep exploring other options that I might be able to use in my boxes. Perhaps I can increase the height of the box to accommodate for the port + adapter to connect the display to the Pi.

It depends imho. HDMI has the advantage that it "just works", DPI and DSI that together with a RPi it is "one device". Pros and Cons the same time can be cabling, available screen sizes and certainly many more things. You know, however you'll do it, it will be never perfect.

[MiSTer Consoles]

Sounds like an HDMI display is the most ideal for this project. I will have to keep exploring other options that I might be able to use in my boxes. Perhaps I can increase the height of the box to accommodate for the port + adapter to connect the display to the Pi.

It depends imho. HDMI has the advantage that it "just works", DPI and DSI that together with a RPi it is "one device". Pros and Cons the same time can be cabling, available screen sizes and certainly many more things. You know, however you'll do it, it will be never perfect.

I agree. It can be difficult to find a solution that exactly meets one's needs 100%. Thankfully there are lots of different displays out there for the RPi, so at least we have quite a few options to choose from.

Hey I ran the update script this morning and as expected it overwrote the images in the tty2rpi-pics directory. I had placed some custom graphics there (000-notavail.png and tty2rpi.png) because the new directory I created for these files (tty2rpi-mypics) does not get looked at by the program even though I have the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" entered in the tty2rpi-user.ini file. Any ideas what might be going wrong there?

[RealLarry]

Hey I ran the update script this morning and as expected it overwrote the images in the tty2rpi-pics directory. I had placed some custom graphics there (000-notavail.png and tty2rpi.png) because the new directory I created for these files (tty2rpi-mypics) does not get looked at by the program even though I have the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" entered in the tty2rpi-user.ini file. Any ideas what might be going wrong there?

Just tested, but it's working here. tty2rpi.png is hardcoded for now but 000-notavail.png, 000-clock.png and all its numbers are displayed when placed and defined in TTY2RPIPICS="${HOME}/tty2rpi-mypics"

There may be be new bug I encountered with 000-notavail.png : It is getting displayed only one time, on the next "not found" the last successful picture is displayed. I'm working on it.

[MiSTer Consoles]

Hey I ran the update script this morning and as expected it overwrote the images in the tty2rpi-pics directory. I had placed some custom graphics there (000-notavail.png and tty2rpi.png) because the new directory I created for these files (tty2rpi-mypics) does not get looked at by the program even though I have the line TTY2RPIPICS="${HOME}/tty2rpi-mypics" entered in the tty2rpi-user.ini file. Any ideas what might be going wrong there?

Just tested, but it's working here. tty2rpi.png is hardcoded for now but 000-notavail.png, 000-clock.png and all its numbers are displayed when placed and defined in TTY2RPIPICS="${HOME}/tty2rpi-mypics"

There may be be new bug I encountered with 000-notavail.png : It is getting displayed only one time, on the next "not found" the last successful picture is displayed. I'm working on it.

I see. So if I want a custom image for tty2rpi.png I will have to just keep overwriting the one in the tty2rpi-pics directory after each update?