DietPi-Config | tft35a LCD display support

[SteveJohnsson]

G_DIETPI_VERSION_CORE=6 G_DIETPI_VERSION_SUB=21 G_DIETPI_VERSION_RC=1 G_GITBRANCH=master G_GITOWNER=Fourdee G_DISTRO_NAME=stretch

Kernel=Linux pi 4.14.98-v7+ #1200 SMP Feb 12 2019 armv7l Device=RPi 3 model B Power supply=USB from the router SDcard: SanDisk ultra

• Can this issue be replicated on a fresh installation of DietPi?

  Yes

Steps to reproduce

1. Download and unpack drivers: https://github.com/goodtft/LCD-show
2. Install ./LCD35-show

Expected behaviour

• The script is kinda messy, it has been discussed earlier, but the solution provided here (https://github.com/Fourdee/DietPi/issues/1598) is not working. Expected behavior is that TFT LCD screen goes from white to present the output from the console.

Actual behaviour

Installation fails (Yes, the script is messy)

Extra details

• The script works fine on latest Raspbian. After the installation LCD screen turns on and works as it should. However, this is not the case with DietPi. I'm suspecting that the script cannot complete because of this statement:

if test "$nodeplatform" = "raspberrypi";then echo "this is raspberrypi kernel" version=${version%% *} version=${version#*#} echo $version if test $version -lt 970;then echo "reboot" else echo "need to update touch configuration" sudo apt-get install xserver-xorg-input-evdev sudo cp -rf /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf echo "reboot" fi else echo "this is not raspberrypi kernel, no need to update touch configure, reboot" fi

[MichaIng]

@SteveJohnsson Thanks for your report.

Yeah indeed the script is out of style, but this is no big issue, it is small enough to easily allow an overview.

The problem is more, that it simply overrides several RPi core config files completely, thus overwriting any other required or manually made changes. This is easier from the scripts/drivers dev point of view, but breaks any custom use cases and requirements. So lets try to find the essential settings that are required to run this LCD.

First thing of course the driver itself is required:

cd /tmp
wget https://github.com/goodtft/LCD-show/archive/master.zip
unzip master.zip
rm master.zip
cd LCD-show-master
cp usr/tft35a-overlay.dtb /boot/overlays/
mv usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

Next is the X.org calibrations:

mkdir -p /etc/X11/xorg.conf.d
cp usr/99-calibration.conf-35-90  /etc/X11/xorg.conf.d/99-calibration.conf
mkdir -p  /usr/share/X11/xorg.conf.d
cp usr/99-fbturbo.conf  /usr/share/X11/xorg.conf.d/

Next is the kernel command line file cmdline.txt. Instead of overwriting the whole file, lets try to add only the required additions, although not sure if they are even required:

sed -i 's/[[:blank:]]logo.nologo//' /boot/cmdline.txt
sed -i 's/[[:blank:]]fbcon=[^[:blank:]]*//g' /boot/cmdline.txt
echo "$(sed -n 1p /boot/cmdline.txt) fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo" > /boot/cmdline_new.txt
mv /boot/cmdline_new.txt /boot/cmdline.txt

The inittab file can be skipped with systemd. There is nothing LCD specific inside, only default getty spawn and runlevel settings.

Next is the config.txt, same as above lets find and add/set the really required settings. Hmm looks like the LCD driver overlay is the only thing, the remaining looks like an old default file, so:

G_CONFIG_INJECT 'dtoverlay=tft35a' 'dtoverlay=tft35a:rotate=90' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=i2c_arm=' 'dtparam=i2c_arm=on' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=spi=' 'dtparam=spi=on' /DietPi/config.txt
G_CONFIG_INJECT 'enable_uart=' 'enable_uart=1' /DietPi/config.txt
G_CONFIG_INJECT 'hdmi_force_hotplug=' 'hdmi_force_hotplug=1' /DietPi/config.txt

The nodeplatform thing is a bid confusing and as you said most likely is the issue why enabling the LCD fails. uname -n prints the hostname, which is in very most cases not raspberrypi, actually not even by default on fresh Raspbian, I think? And of course hostname and kernel are totally independent from each other. And the current kernel version that is compared in the script is 1200 >= 970:

2019-02-25 22:15:21 root@micha:/tmp# uname -v
#1200 SMP Tue Feb 12 20:27:48 GMT 2019

So lets do the touch configuration updates:

G_AGI xserver-xorg-input-evdev

• This installs the whole xserver package tail, so can take a while, if you didn't install the xserver yet, AFAIK.

I don't get the last command. This simply doubles one config file installed by the above packages. It raises its "priority" but as long as those settings are not overridden by another one (with priority between 10 and 45), this should have no effect. And even if wanted, then the file should not be copied, but moved, to not have doubled settings 🤔. I would just skip this... ~cp /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf~

Finally:

reboot

[MichaIng]

@SteveJohnsson Ah one more thing, since this is no HDMI display? I don't know too much about this, but do you know if the display uses I2C, SPI and/or UART interface?

If it does not work or as failsafe, we better enable those overlays as well:

G_CONFIG_INJECT 'dtparam=i2c_arm=' 'dtparam=i2c_arm=on' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=spi=' 'dtparam=spi=on' /DietPi/config.txt
G_CONFIG_INJECT 'enable_uart=' 'enable_uart=1' /DietPi/config.txt

EDIT

This one: http://www.lcdwiki.com/zh/3.5inch_RPi_Display ? I see an SPI in one table, so the second command above should be sufficient.

[SteveJohnsson]

Hi @MichaIng!

I have tested your solution and it worked a charm! The only "issue" I found with this setup is that the font that is sent to the LCD is quite small. It is not a big issue however.

BIG thanks for quick response and the help you provided mate! :)

[MichaIng]

@SteveJohnsson Thanks for feedback. Did you check which interface is actually required, I²C, SPI and/or UART?

I reopen this issue as a request to add this LCD to our dietpi-config selection.

[SteveJohnsson]

Hi @MichaIng!

Sorry for the late response.

As there are no mention about I2C or UART, so I guess it is the SPI interface. Unfortunately, there is no documentation that comes with the display either.

[MichaIng]

@SteveJohnsson If you want you can test it:

sed -i '/dtparam=i2c_arm=/d' /boot/config.txt
sed -i '/enable_uart=/d' /boot/config.txt

Then reboot and see if the display still works.

[rzmichel]

Hi @MichaIng

If you want you can test it:

sed -i '/dtparam=i2c_arm=/d' /boot/config.txt
sed -i '/enable_uart=/d' /boot/config.txt

Then reboot and see if the display still works.

I did try it on fresh install image. And the unit working until displaying (ask to hit return for login) same as without that two command.

I follow every step from your guidance in this thread. With some modification because of the changed source file or uncompleted path:

cp usr/99-calibration.conf-35 /etc/X11/xorg.conf.d/99-calibration.conf I changed to cp usr/**99-calibration.conf-35-0** /etc/X11/xorg.conf.d/99-calibration.conf

mv cmdline_new.txt cmdline.txt changed to mv /boot/cmdline_new.txt /boot/cmdline.txt (this one because I did inside /tmp/LCD-show-master path)

execute dtoverlay tft35a with result DTOVERLAY[error]: Failed to open '/boot/overlays/tft35a.dtbo'

• Failed to read '/boot/overlays/tft35a.dtbo'

But yes... the console running replacing white screen

sorry for my lack knowledge, I just master on following step :-)

on device github page, I found this page showed some info for other raspberry image. http://www.lcdwiki.com/3.5inch_RPi_Display

But yes, I still prefer using DietPi Thank you for DietPi.

[MichaIng]

@rzmichel I just updated my steps above by going through the script again which contains some changes: https://github.com/goodtft/LCD-show/blob/master/LCD35-show

• Somehow it contains now enabling everything: SPI, I2C, forced HDMI, UART
• It uses the 99-calibration.conf-35-90 file and adds the dtoverlay with :rotate=90 as well. Not sure whether this is wanted or not 😉, simply landscape vs portrait format?

• mv /boot/cmdline_new.txt /boot/cmdline.txt

  • Good spot, makes sense 👍.

Checking your error and re-checking the script, this actually seems strange to me:

https://github.com/goodtft/LCD-show/blob/master/LCD35-show#L12

cp ./usr/tft35a-overlay.dtb /boot/overlays/ cp ./usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

The .dtb file is first copied over as dtb, which like this AFAIK is completely unused like this. Then is is again copied but but changed name + file type. AFAIK dtb and dtbo are quite similar, but dtbo (overlays) are meant to be leaded to runtime as well while dtb are not. This is maybe the reason why "dtoverlay tft35a" command fails. But I am not sure how to verify if the overlay has been loaded successfully on boot (via config.txt entry) since AFAIK they can fail silently, at least outside of usual boot logs.

However if it is finally working, it seems to works, then obviously it worked, hence dtoverlay tft35a should be simply skipped/its error ignored.

[rzmichel]

Hi @MichaIng Thank you for the update.

From the guidance above, TFT LCD 3.5" is working on console mode. But not on KIOSK mode or whatever Desktop application. Xorg showed me no screen found(EE)

First I want to fill information what I use on this thread.

G_DIETPI_VERSION_CORE=6 G_DIETPI_VERSION_SUB=26 G_DIETPI_VERSION_RC=3 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_DISTRO_NAME='buster' kernel=#1270 SMP Tue Sep 24 18:45:11 BST 2019 device=RPi 3 Model B (armv7l)

After fresh install, software installed is:

SSH Server=OpenSSH Desktop=Chromium TextEditor=Vim Hardware Project= Node-Red and screen

I using 3.5inch TFT LCD attached on RPi 3 Model B During installation, TFT showing white screen. To make it work, is about to copy driver on the correct place and tweak configuration file.

Follow the guidance after reboot, TFT screen showing the console process. after login, execute dietpi-autostart and choose option 11, running Chromium without Desktop.

edit resolution screen for chromium option on /Dietpi/dietpi.txt SOFTWARE_CHROMIUM_RES_X=480 SOFTWARE_CHROMIUM_RES_Y=320 otherwise the display will showing default on 1280x720 resolution.

If we reboot now, the display will showing console process and failed to start Desktop. Xorg will showing no screen found(EE) as I mentioned previously.

I found the solution on this post. Add the solution to /etc/X11/xorg.conf.d/99-calibration.conf and reboot

Display and touch WORKING! finally. but.. need calibration for placing the touch... I'm not found yet the way to calibrate.. at least I know the display working properly. Thank you

[MichaIng]

@rzmichel If I get it right, 99-calibration.conf is for the touchscreen: https://github.com/goodtft/LCD-show/blob/master/usr/99-calibration.conf-32-90 Option "Calibration" "3700 115 155 3865"+ "SwapAxes" is what you need to play around to have the touch input and screen output match. There also seems to be a tool, that is hosted on "goodtft" but not part of the script:

apt install xinput-calibrator
xinput_calibrator

The solution you found makes sense. The script installs the fbturbo driver with Allwinner identifier: https://github.com/goodtft/LCD-show/blob/master/usr/99-fbturbo.conf I was already thinking that this most likely does not work on RPi. But then again Option "fbdev" 🤔. The xorg.conf you linked uses fbdev driver with fbdev options, which looks correct to me, especially for RPi. Just to reference here:

Section "Device"
# WaveShare SpotPear 3.5", framebuffer 1
Identifier "uga"
driver "fbdev"
Option "fbdev" "/dev/fb1"
Option "ShadowFB" "off"
EndSection

Section "Monitor"
# Primary monitor. WaveShare SpotPear 480x320
Identifier "WSSP"
EndSection

Section "Screen"
Identifier "primary"
Device "uga"
Monitor "WSSP"
EndSection

Section "ServerLayout"
Identifier "default"
Screen 0 "primary" 0 0
EndSection

Also to link the actual source which contains some other differences: https://www.raspberrypi.org/forums/viewtopic.php?p=712958#p712958

Btw the thread again verifies that it is an SPI display, hence the three /DietPi/config.txt entries:

dtparam=i2c_arm=on
enable_uart=1
hdmi_force_hotplug=1

are not required.

Btw, what I was not understanding from the beginning... Are these drivers for a specific display or generic for many similar SPI display, as the thread above obviously was about WaveShare SpotPear. There is a build-in overlay on RPi:

Name:   pitft35-resistive

Info:   Adafruit PiTFT 3.5" resistive touch screen

Usage:  dtoverlay=pitft35-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}

• Same resolution, SPI, could be tested at least instead of dtoverlay=tft35a.

[rzmichel]

Hello,

I did comparing fresh install latest image between dietpi and raspbian lite with desktop. On raspbian lite with desktop, after running script for the driver from https://github.com/goodtft/LCD-show/ device running well with no issue. No calibration needed.

I continue checking on installed file. Below files is identical

/usr/share/X11/xorg.conf.d/99-fbturbo.conf
/boot/overlays/tft35a.dtbo
/boot/overlays/tft35a-overlay.dtb

The rest files have some difference. Inside file config.txt (on DietPi, file on /boot and /Dietpi is identical):

# DietPi having additional 14 configuration:
hdmi_force_hotplug=1
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
disable_camera_led=0
gpu_mem_256=128
gpu_mem_512=128
gpu_mem_1024=128
max_usb_current=1
disable_splash=1
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=i2c1=off
dtparam=spi=on
enable_uart=1
temp_limit=75
initial_turbo=20
force_turbo=0
dtoverlay=disable-bt
dtoverlay=tft35a:rotate=270

# Raspbian only 6 configuration:
dtparam=audio=on
hdmi_force_hotplug=1
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
dtoverlay=tft35a:rotate=270

At file cmdline.txt:

# DietPi `dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=cb7b86f7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait fbcon=map:10 fbcon=font:ProFont6x11`
# Raspbian `dwc_otg.lpm_enable=0 console=tty1 console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo`

At file /etc/X11/xorg.conf.d/99-calibration.conf The different only on Option Calibration value.

# DietPi is "3936 227 268 3880" 
# Raspbian Lite is "227 3936 3880 268"

Tried to put same value configuration, DietPi still stop starting Desktop. After add configuration fbdev driver above, it's start desktop but with wrong match of touch and screen input still.

Are these drivers for a specific display or generic for many similar SPI display, as the thread above obviously was about WaveShare SpotPear.

The display coming with no manual paper, inside box with bubble warp and the plastic stylus. I got the info for installing driver on description product. From the market place, they had SPI and HDMI choice of display with various size. The display with me is SPI 3.5" coming without any brand. Just chipset code (maybe), XPT2046

I just curious, how come DietPi need option fbdev when on Raspbian don't.

[MichaIng]

@rzmichel Thanks for your comparison details.

From cmdline.txt and 99-calibration.conf content it looks like you used a slightly different script than I used as basis. Which script did you run?

• cmdline.txt contains logo.nologo, this only hides the raspberries at the top of boot screen.
• DietPi config.txt contains some rotation related entries, which you could try to comment. Rotation "0" should be default, however probably this conflicts with the overlay and/or xorg.conf settings.
• 99-calibration.conf simply is 90° rotated between DietPi and Raspbian. If on Raspbian this is the correct rotation to have screen output and touch input align correctly, then this is obviously the output rotation you use: https://github.com/goodtft/LCD-show/blob/master/usr/99-calibration.conf-35-270

[rzmichel]

Hi @MichaIng

First sorry not responded in time. Always glad reading your reply. You put some explanation for the "what's going on" 😍

Actually I follow step on this thread, combine with what I found and what I need for the device. Final result is device is running as I expected. THANK YOU!

I did rotate the device since the power port is on the bottom of display when following default configuration walk through.

Below is my final configuration on the device (DietPi on RPi3 with 3.5" TFT LCD) : /usr/share/X11/xorg.conf.d/99-fbturbo.conf

Section "Device"
        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

        Option          "SwapbuffersWait" "true"

/boot/config.txt = /DietPi/config.txt

hdmi_force_hotplug=1
disable_overscan=1
display_hdmi_rotate=0
lcd_rotate=0
disable_camera_led=0
gpu_mem_256=128
gpu_mem_512=128
gpu_mem_1024=128
max_usb_current=1
disable_splash=1
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=i2c1=off
dtparam=spi=on
enable_uart=1
temp_limit=75
force_turbo=0
dtoverlay=disable-bt
dtoverlay=tft35a:rotate=270

/boot/cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=cb7b86f7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait console=ttyAMA0,115200 fbcon=map:10 fbcon=font:ProFont6x11

/etc/X11/xorg.conf.d/99-calibration.conf Touchscreen is correct now. I copied the Calibration option same as Raspbian after rotating.

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "ADS7846 Touchscreen"  
    Option  "Calibration"   "227 3936 3880 268"
    Option  "SwapAxes"      "1"
EndSection

Section "Device"
    # WaveShare SpotPear 3.5", framebuffer 1
    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"
    Option "ShadowFB" "off"
    EndSection
    #
Section "Monitor"
    # # Primary monitor. WaveShare SpotPear 480x320
    Identifier "WSSP"
    EndSection
    #
Section "Screen"
    Identifier "primary"
    Device "uga"
    Monitor "WSSP"
    EndSection
    #
Section "ServerLayout"
    Identifier "default"
    Screen 0 "primary" 0 0
    EndSection

That's all. It's running well. But start up takes some time than Raspbian Lite with Desktop image. But I'll live with it since love too much to DietPi 😂

[MichaIng]

@rzmichel Glad it finally worked. Note that you currently have two conflicting xorg sections in theory:

        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

and

    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"

Two configs attached to the same framebuffer device fb1. Not sure how this is solved, I guess due to alphabetical order one overwrites the other, hence one should be without effect. Or: Device "uga" in the screen section leads to the "uga" device taking priority. Not sure about details there 😉. My guess is that 99-fbturbo.conf is useless here, also since it looks wired with fbturbo driver but fbdev option, this does not fit together... But I am no expert.

[rzmichel]

I did try comment in one by one:

        Identifier      "Allwinner A10/A13/A20 FBDEV"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"

and

    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"

and comment in both. All gave result Error, giving up. So stick with this step, second thread comment. Plus add below configuration on /etc/X11/xorg.conf.d/99-calibration.conf

Section "Device"
# WaveShare SpotPear 3.5", framebuffer 1
Identifier "uga"
driver "fbdev"
Option "fbdev" "/dev/fb1"
Option "ShadowFB" "off"
EndSection

Section "Monitor"
# Primary monitor. WaveShare SpotPear 480x320
Identifier "WSSP"
EndSection

Section "Screen"
Identifier "primary"
Device "uga"
Monitor "WSSP"
EndSection

Section "ServerLayout"
Identifier "default"
Screen 0 "primary" 0 0
EndSection

Screen and touch input will running. Just do calibration if you rotating the screen.

[MichaIng]

@rzmichel Okay thanks for testing. Commenting the "uga" device of course causes an error since this is used by the "Screen" section 😉. However good to know that the fbturbo device is required as well, for some reason.

[ilyasst]

Hello hello :)

I got a "MHS35" LCD screen from the https://github.com/goodtft/LCD-show repository, this one here http://www.lcdwiki.com/MHS-3.5inch_RPi_Display. I was wondering if the LCD35 was eventually added to dietpi-config ? Might be able to rely on that to make the MHS35 work too.

Scripts for Ubuntu, Raspbian and Kali Linux are available, but for a Raspberry Pi, I also still prefer using DietPi Thank you for DietPi.

[ilyasst]

I was able to get it to work for the "MHS35" LCD screen. Please let me know how I can help to maybe include a script for these screens on Dietpi-config. Cheers

[MichaIng]

Thanks for the offer. Yes generally those install scripts work on DietPi as well, but they are extremely intrusive, override large parts of boot configuration which is not required and break customisations and lots of them are not required or even very outdated (not effective on modern RPi firmware), so I'd recommend to extract the essential steps from those scripts, which is then true for our implementation as well.

Would be great if you could share the steps you did.

[ilyasst]

Hello @MichaIng , Sorry about the delay, but here it is. I was able to get the "MHS35" LCD screen to work with the Raspberry Pi 3B+ and the Raspberry Pi 4. Although the LCD screen for the Raspberry Pi 3B+ and the one for the Raspberry Pi 4 are different, they both use the "MHS35" driver from the https://github.com/goodtft/LCD-show repository. I have followed the same steps to get them to work on their respective Raspberry Pi model using the latest Dietpi version. I have mainly followed the steps provided in your first comment here and have applied them to the "MHS35". There are the steps I followed:

Download the repository that contains the drivers and the installation script for a bunch of these cheap LCD screens:

dietpi@DietPi:~$ git clone https://github.com/goodtft/LCD-show.git

Change permissions of the folder so that your user can read and write, then enter the downloaded folder:

dietpi@DietPi:~$ chmod -R 755 LCD-show/
dietpi@DietPi:~$ cd ./LCD-show/

Copy the driver for the LCD screen purchased:

sudo cp ./usr/mhs35-overlay.dtb /boot/overlays/
sudo cp ./usr/mhs35-overlay.dtb /boot/overlays/mhs35.dtbo

Modify the X.org calibrations:

mkdir -p /etc/X11/xorg.conf.d
cp usr/99-calibration.conf-35-90  /etc/X11/xorg.conf.d/99-calibration.conf
mkdir -p  /usr/share/X11/xorg.conf.d
cp usr/99-fbturbo.conf  /usr/share/X11/xorg.conf.d/

Modifications necessary for the kernel command line file cmdline.txt:

sed -i 's/[[:blank:]]logo.nologo//' /boot/cmdline.txt
sed -i 's/[[:blank:]]fbcon=[^[:blank:]]*//g' /boot/cmdline.txt
echo "$(sed -n 1p /boot/cmdline.txt) fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo" > /boot/cmdline_new.txt
mv /boot/cmdline_new.txt /boot/cmdline.txt

@MichaIng I was not able to use the G_CONFIG_INJECT command, even when using G_SUDO, I kept getting a message saying that the /Dietpi/dietpi.txt file was not there... I eventually used the following method:

Remove the micro SD card from your Raspberry Pi, insert it in a laptop or other computer. Open the boot partition of the SD card that should have automatically been detected. Open the /boot/config.txt. Ensure that each following line is uncommented or exists in the config.txt file. Modify the value of a line if necessary so that it matches the value below, add it if it does not exist:

hdmi_force_hotplug=1
dtparam=i2c_arm=on
dtparam=spi=on
enable_uart=1
dtoverlay=mhs35:rotate=90
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 480 320 60 6 0 0 0
hdmi_drive=2

Remove the SD-card, put it in your Raspberry Pi 4 and reboot, Voilà !

Please note that I do not know if the touchscreen actually works, I do not know (yet) if there is some kind of benchmark app I can use to test the touchscreen. Can you perhaps help me with this ?

I hope these instructions can help implement these LCD screens within Dietpi.

[Joulinar]

Just a side note. /Dietpi/dietpi.txt did not exist anymore. It has been moved to /boot/dietpi.txt

[ilyasst]

Just a side note. /Dietpi/dietpi.txt did not exist anymore. It has been moved to /boot/dietpi.txt

Thank you for this quick answer, it explains a lot 😅 Well, I won't need to remove the SD card from the RPi next time.

[MichaIng]

Awesome, many thanks for sharing the steps.

sudo cp ./usr/mhs35-overlay.dtb /boot/overlays/ sudo cp ./usr/mhs35-overlay.dtb /boot/overlays/mhs35.dtbo

Only the second is necessary, as you use dtoverlay=mhs35:rotate=90.

cp usr/99-fbturbo.conf /usr/share/X11/xorg.conf.d/

Do you have any xf86-video-fbturbo or xserver-xorg-video-fbturbo package or similar installed already? It should not work OOTB with this when starting an X server and I think a specific DDX driver is not required, if I'm not mistaken regular fbdev is used on RPi by default.

I just see that fbturbo is available on the RPi repo, aside of fbdev: http://archive.raspberrypi.org/debian/pool/main/x/

If one finds time, we could to some 2D acceleration benchmarks on different RPi models to check whether fbturbo is a better default, when X server is installed on RPi, but I'm going off-topic 🙂.

[ilyasst]

The Raspberry Pi 4 and 3B+ were freshly installed, the only thing I did is build opencv and installed a few python related packages (venv) I believe. I did not need to use this command, since the LCD screen changed from white to the console when I rebooted:

G_AGI xserver-xorg-input-evdev

Here is the list of packages that start with x that are installed on the RPi:

x11-common/stable,stable,now 1:7.7+19 all [installed,automatic]
x11proto-composite-dev/stable,stable,now 1:2018.4-4 all [installed,automatic]
x11proto-core-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-damage-dev/stable,stable,now 1:2018.4-4 all [installed,automatic]
x11proto-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-fixes-dev/stable,stable,now 1:2018.4-4 all [installed,automatic]
x11proto-input-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-randr-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-record-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-xext-dev/stable,stable,now 2018.4-4 all [installed,automatic]
x11proto-xinerama-dev/stable,stable,now 2018.4-4 all [installed,automatic]
xkb-data/stable,stable,now 2.26-2 all [installed,automatic]
xorg-sgml-doctools/stable,stable,now 1:1.11-1 all [installed,automatic]
xtrans-dev/stable,stable,now 1.3.5-1 all [installed,automatic]
xz-utils/stable,now 5.2.4-1 arm64 [installed,automatic]

Please le me know if I did not understand or answer something.

I have the LCD running on the 3B+ and 4, so we could test these two if you have a benchmark script :)

[MichaIng]

The config is not loaded unless you actually start an X server, like a desktop or GUI program, which doesn't seem to be installed in your case. For console usage, fbturbo or any other DDX have no effect anyway 😉.

[vargn]

@SteveJohnsson Thanks for your report.

Yeah indeed the script is out of style, but this is no big issue, it is small enough to easily allow an overview.

The problem is more, that it simply overrides several RPi core config files completely, thus overwriting any other required or manually made changes. This is easier from the scripts/drivers dev point of view, but breaks any custom use cases and requirements. So lets try to find the essential settings that are required to run this LCD.

First thing of course the driver itself is required:

cd /tmp
wget https://github.com/goodtft/LCD-show/archive/master.zip
unzip master.zip
rm master.zip
cd LCD-show-master
cp usr/tft35a-overlay.dtb /boot/overlays/
mv usr/tft35a-overlay.dtb /boot/overlays/tft35a.dtbo

Next is the X.org calibrations:

mkdir -p /etc/X11/xorg.conf.d
cp usr/99-calibration.conf-35-90  /etc/X11/xorg.conf.d/99-calibration.conf
mkdir -p  /usr/share/X11/xorg.conf.d
cp usr/99-fbturbo.conf  /usr/share/X11/xorg.conf.d/

Next is the kernel command line file cmdline.txt. Instead of overwriting the whole file, lets try to add only the required additions, although not sure if they are even required:

sed -i 's/[[:blank:]]logo.nologo//' /boot/cmdline.txt
sed -i 's/[[:blank:]]fbcon=[^[:blank:]]*//g' /boot/cmdline.txt
echo "$(sed -n 1p /boot/cmdline.txt) fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo" > /boot/cmdline_new.txt
mv /boot/cmdline_new.txt /boot/cmdline.txt

The inittab file can be skipped with systemd. There is nothing LCD specific inside, only default getty spawn and runlevel settings.

Next is the config.txt, same as above lets find and add/set the really required settings. Hmm looks like the LCD driver overlay is the only thing, the remaining looks like an old default file, so:

G_CONFIG_INJECT 'dtoverlay=tft35a' 'dtoverlay=tft35a:rotate=90' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=i2c_arm=' 'dtparam=i2c_arm=on' /DietPi/config.txt
G_CONFIG_INJECT 'dtparam=spi=' 'dtparam=spi=on' /DietPi/config.txt
G_CONFIG_INJECT 'enable_uart=' 'enable_uart=1' /DietPi/config.txt
G_CONFIG_INJECT 'hdmi_force_hotplug=' 'hdmi_force_hotplug=1' /DietPi/config.txt

The nodeplatform thing is a bid confusing and as you said most likely is the issue why enabling the LCD fails. uname -n prints the hostname, which is in very most cases not raspberrypi, actually not even by default on fresh Raspbian, I think? And of course hostname and kernel are totally independent from each other. And the current kernel version that is compared in the script is 1200 >= 970:

2019-02-25 22:15:21 root@micha:/tmp# uname -v
#1200 SMP Tue Feb 12 20:27:48 GMT 2019

So lets do the touch configuration updates:

G_AGI xserver-xorg-input-evdev

* This installs the whole xserver package tail, so can take a while, if you didn't install the xserver yet, AFAIK.

I don't get the last command. This simply doubles one config file installed by the above packages. It raises its "priority" but as long as those settings are not overridden by another one (with priority between 10 and 45), this should have no effect. And even if wanted, then the file should not be copied, but moved, to not have doubled settings thinking. I would just skip this... ~cp /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf~

Finally:

reboot

I followed this guide, just changed tft35a to mhs35 since that's the LCD I got. The LCD works just fine, but I lost my network connection and can't figure out why? I think maybe the edit of cmdline.txt might be the issue. But exactly what I don't know.

pls help :)

[MichaIng]

I think maybe the edit of cmdline.txt might be the issue.

The cmdline is not related to network at all. I guess it became apparent as part of package upgrades or the reboot. If you still have network issues, please open a new issue about that.

[hailogugo]

I add the datas not in the dietpi config file I add it in the /boot/config.txt. The Display shows the things. Touch I cannot test now.

Thx for the guide.

[MichaIng]

Great. Yes, all those settings need to be applied to config.txt, not dietpi.txt, having a look through it I think the instructions above are correct on this, when considering that previous /DietPi is now /boot.

[hailogugo]

We are workin on this project. https://github.com/splitti/MuPiBox If I use a normal Monitor or my secound Touchscree on HDMI the Mupibox will start. If I use the Rpi 3,5" screen with connection from GPIO it showed me only some start up thinks but never the Chromonium page on the Raspberry. Do you have an idea what can be the problem?

My steps:

1. installing dietpi on SD, with dietpi.txt from Mupibox but without the autosetup skipt
2. starting dietpi and installing the screen like the steps above.
3. Installing Mupibox as root cd; rm buster-install-*; wget https://raw.githubusercontent.com/splitti/MuPiBox/main/autosetup/autosetup.sh; chmod +x autosetup.sh; ./autosetup.sh
4. Change GPIO from OnOffShim /etc/mupibox/xxxxx.json because On Off Shim use same GPIO like the 3,5" Touchscreen. (OnOff Shim is not connected with the Pi up to now.
5. Now I tested different things but it do not start up to the small screen.

I hope you can help.

[MichaIng]

Can you try con2fbmap 1 2 to map the console /dev/tty1 to the second framebuffer device /dev/fb1. I guess /dev/fb0 is the HDMI screen being used by default as output device for the default console.

But while the above changes the output screen for the console, I'm not sure whether this is passed automatically to the X server. Especially when KMS is used, it definitely won't. For this you could try:

startx /usr/bin/chromium-browser -- :1

to force it starting at screen 1 instead of screen 0. This can be made permanently for all X sessions as well, or for Chromium via our autostart script. We might even make this a dietpi.txt setting so that the screen can be selected if multiple ones are attached.

[hailogugo]

So I do a lot and stat up with a new system. Now the screen will Display the browser afer I do this in the console startx /usr/bin/chromium-browser -- :1

Now my problem is that I click right the mouse goes on top, if click left mouse goes down, if I click down it mouse goes right, if i click up mouse goes left. I can turn display in config.txt this works. I think my problem is the calibration but I enter different parameter but it do not change. (here change /etc/X11/xorg.conf.d/99-calibration.conf)

Can you support me again?

[MichaIng]

I'm also no expert in this. Check out the calibration configs from here, which should give you an idea how it works:

• Option "Calibration MinX MaxX MinY MaxY" for the dimension, which can include swapping X and Y (180°) axis by swapping min and max values.
• Option "SwapAxes" "1" for swapping X and Y axis (90°).

You can also try xinput_calibrator:

apt install xinput-calibrator
xinput_calibrator

[hailogugo]

Display is working now. I do the steps from here https://github.com/goodtft/LCD-show How to rotate the display direction

Enter these from above into /etc/X11/xorg.conf.d/99-calibration.conf

Section "Device"
    # WaveShare SpotPear 3.5", framebuffer 1
    Identifier "uga"
    driver "fbdev"
    Option "fbdev" "/dev/fb1"
    Option "ShadowFB" "off"
    EndSection
    #
Section "Monitor"
    # # Primary monitor. WaveShare SpotPear 480x320
    Identifier "WSSP"
    EndSection
    #
Section "Screen"
    Identifier "primary"
    Device "uga"
    Monitor "WSSP"
    EndSection
    #
Section "ServerLayout"
    Identifier "default"
    Screen 0 "primary" 0 0
    EndSection

In /boot/config.txt I have to change because everything will be delete by the script from the Display.

After I test it with this code startx /usr/bin/chromium-browser -- :1

Now I have to find the problem why chromium cannot open any webpage also 127.0.0.1

root@MuPiBox:~# startx /usr/bin/chromium-browser -- :1

X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
Build Operating System: linux Raspbian
Current Operating System: Linux MuPiBox 5.10.103-v7+ #1530 SMP Tue Mar 8 13:02:44 GMT 2022 armv7l
Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=480 bcm2708_fb.fbheight=320 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  root=PARTUUID=b458407c-02 rootfstype=ext4 rootwait fsck.repair=yes net.ifnames=0 console=tty3 vt.global_cursor_default=0 fastboot noatime nodiratime noram splash silent loglevel=0 vt.default_red=68,68,68,68,68,68,68,68 vt.default_grn=175,175,175,175,175,175,175,175 vt.default_blu=226,226,226,226,226,226,226,226 fbcon=map:10 fbcon=font:ProFont6x11 logo.nologo
Build Date: 04 January 2022  10:24:42AM
xorg-server 2:1.20.11-1+rpt1+deb11u1 (https://www.debian.org/support)
Current version of pixman: 0.40.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.1.log", Time: Wed Mar 16 15:07:18 2022
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
/usr/bin/chromium-browser: Zeile 140: lsb_release: Kommando nicht gefunden.
/usr/bin/chromium-browser: Zeile 141: lsb_release: Kommando nicht gefunden.
[7367:7420:0316/150720.304722:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[7367:7420:0316/150720.305224:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
libEGL warning: DRI2: failed to authenticate
[7367:7420:0316/150720.371339:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[7367:7420:0316/150720.371529:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[7367:7420:0316/150720.566160:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[7367:7420:0316/150720.566307:ERROR:bus.cc(397)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[7427:7427:0316/150720.847343:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is
[7367:7482:0316/150720.921912:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[7367:7482:0316/150720.924952:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.GetDisplayDevice: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[7367:7482:0316/150720.928651:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.UPower.EnumerateDevices: object_path= /org/freedesktop/UPower: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.UPower was not provided by any .service files
[7427:7427:0316/150720.929334:ERROR:viz_main_impl.cc(188)] Exiting GPU process due to errors during initialization
libEGL warning: DRI2: failed to authenticate
[7485:7485:0316/150721.416223:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is egl, ANGLE is
[7485:7485:0316/150721.522680:ERROR:viz_main_impl.cc(188)] Exiting GPU process due to errors during initialization
[7508:7508:0316/150721.575649:ERROR:egl_util.cc(74)] Failed to load GLES library: /usr/lib/chromium-browser/libGLESv2.so: /usr/lib/chromium-browser/libGLESv2.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden
[7508:7508:0316/150721.657156:ERROR:viz_main_impl.cc(188)] Exiting GPU process due to errors during initialization
[7518:7518:0316/150721.702314:ERROR:gpu_init.cc(454)] Passthrough is not supported, GL is disabled, ANGLE is
[7367:7397:0316/150725.838339:ERROR:chrome_browser_main_extra_parts_metrics.cc(227)] START: ReportBluetoothAvailability(). If you don't see the END: message, this is crbug.com/1216328.
[7367:7397:0316/150725.838514:ERROR:chrome_browser_main_extra_parts_metrics.cc(230)] END: ReportBluetoothAvailability()
^Cxinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

[MichaIng]

In /boot/config.txt I have to change because everything will be delete by the script from the Display.

Not a good idea to run those scripts IMHO, as long as it is not a fresh official Raspberry Pi OS. They are doing way too much and assuming way too much, breaking a lot of custom configurations etc.

The /etc/X11/xorg.conf.d/99-calibration.conf is not really a touch input calibration but basically redundant, hardcoding legacy framebuffer driver. But since it contains Option "fbdev" "/dev/fb1", -- :1 can be skipped for the startx command. However, if you want to use KMS, then the LCD screen needs to be set like so:

Section "Device"
    Identifier "uga"
    Driver "modesetting"
    Option "kmsdev" "/dev/dri/card1"
    EndSection

Preserving syntax and identifier you used above.

Please keep discussion about the Chromium issue here (which seems to match your issue): #5342

[ZenoBell]

i had as well problem with the calibration even if i rotated the sceen as the guy from some posts above, it didnt work for me. I followed the example of MichaIng and installed xinput calibrator but I couldnt launch it cause i didnt have intall LXDE or any other graphic interface as i was runnign chromium without. It may see obvious for others but not for me so i'm putting here all the steps just in case someone also needs it. So sudo pkill x to kill my current chromium session that was autolaunching. Then sudo startx /usr/bin/xinput_calibrator and you calibrate the monitor. Copy the results on 99-calibration.conf and you shoud be good to go. My setting calibration data were:

Section "InputClass"
        Identifier      "calibration"
        MatchProduct    "ADS7846 Touchscreen"
        Option  "Calibration"   "194 3965 3849 189"
        Option  "SwapAxes"      "0"
EndSection

(same monitor 3.5inch RPi Display and rotation 270). Cheers !

p.s. big thanx once more to MichaIng to help in the first place making the script work!