3.5 320x480 touchscreen does not work

[mukral]

It's a problem caused by change to wayland as standard. To make it work again you have to switch back to X11:

• connect to a monitor (little bit tricky for me because I have a SPI-version that does not allow parallel use of HDMI-monitor, so I've put the sd-card out backupped the config.txt and copied a "fresh" config.txt to /boot. Alternatively access via ssh.
• After booting raspi you can proceed this:
• sudo raspi-config
• 6 Advanced Options
• A6 Wayland
• W1 X11

exchange config.txt on sdcard with backupped config.txt

Hopefully someone writes a driver for wayland because X11-driver is so slooooooowww

[lurch]

Could you provide more details about exactly which screen you're using please? There are several different 3rd-party small screens. And if you could explain what config.txt changes you have to make to get your screen working, that'd be useful too.

[mukral]

Touchscreen same like this one: http://www.lcdwiki.com/3.5inch_RPi_Display#Step_1.EF.BC.9ADownload_the_Raspbian_IMG and installed like described on page. To make it work again with bookworm there is no need to change anything in config.txt, only set back to X11 and use same config.txt that worked before.

[lurch]

You might want to create an issue at https://github.com/goodtft/LCD-show and ask them to add support to their drivers / installation-instructions for Wayland?

[6by9]

All these SPI displays need to have a DRM driver, and for the driver to be known by Mesa, for them to work under Wayfire.

Many displays are already supported via the TinyDRM drivers in the Linux kernel, but there are so many variants that the overlays aren't necessarily there. Most of those are registered with Mesa, but some are missing.

Your one happens to have already has a driver dtoverlay=piscreen,drm in /boot/firmware/config.txt, reboot. The ili9486 is one of those missing from Mesa - I'll create a patch to add that display. I did it locally and had that display running as part of investigating https://forums.raspberrypi.com/viewtopic.php?p=2144343#p2144343. It just shows up as another display in the Screen Configuration app.

[mukral]

Thank you, but doesn't work, startscreen is shown, but after that nothing happens anymore. And I don't know which of these parameter else to change. I'll stay with X11.

[6by9]

You ignored the bit where I said

The ili9486 is one of those missing from Mesa - I'll create a patch to add that display.

? That patch is created and should get merged soon.

[sdbbs]

Thanks so much for the info here - just writing my data point; I have a 3.5" screen as well, on a new Raspberry Pi 3B+:

pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 12 (bookworm)
Release:    12
Codename:   bookworm

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.1.0-rpi7-rpi-v7 #1 SMP Raspbian 1:6.1.63-1+rpt1 (2023-11-24) armv7l GNU/Linux

pi@raspberrypi:~ $ cat /etc/issue
Raspbian GNU/Linux 12 \n \l

Instructions from the seller were unclear on precisely which driver to use, so I used ./LCD35-show as per https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A) - after it installed and rebooted, for a while I could see boot text on it, but nothing was shown once the desktop booted (as confirmed via VNC); then I saw:

Your one happens to have already has a driver dtoverlay=piscreen,drm in /boot/firmware/config.txt, reboot.

... and commented the #dtoverlay=waveshare35a which the ./LCD35-show driver installation added, then I wrote in the dtoverlay=piscreen,drm in /boot/firmware/config.txt, saved /boot/firmware/config.txt, rebooted - and finally can see the desktop on the 3.5" screen! Great ...

Touchscreen was off for me; the ./LCD35-show driver installation installed xinput-calibrator, which I called from the GUI over VNC (only x11vnc server could get me the actual tiny desktop), the procedure seemingly passed, I saved sudo nano /etc/X11/xorg.conf.d/99-calibration.conf as requested and rebooted, but touch axes were still off ... but it should be doable to put it under control.

[lurch]

@sdbbs You might want to ask Waveshare to update their instructions?

[alfrix]

I can confirm that using dtoverlay=piscreen,drm works on my 3.5"A clone screen

i had to set a lower speed to have correct colors dtoverlay=piscreen,speed=16000000,drm

but rotation doesn't work in the drm driver:

none of the rotations seem to work [90 180 270] > dtoverlay=piscreen,speed=16000000,rotate=90,drm

In the non drm driver rotation works, but X doesn't launch dtoverlay=piscreen,speed=16000000,rotate=90

...
   803.430] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   803.430] (II) FBDEV: driver for framebuffer: fbdev
[   803.432] (WW) Falling back to old probe method for modesetting
[   803.432] (EE) open /dev/dri/card0: No such file or directory
[   803.432] (WW) Falling back to old probe method for fbdev
[   803.432] (II) Loading sub module "fbdevhw"
[   803.433] (II) LoadModule: "fbdevhw"
[   803.433] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[   803.433] (II) Module fbdevhw: vendor="X.Org Foundation"
[   803.433]    compiled for 1.21.1.7, module version = 0.0.2
[   803.433]    ABI class: X.Org Video Driver, version 25.2
[   803.434] (II) FBDEV(0): using /dev/fb1
[   803.434] (EE) Screen 0 deleted because of no matching config section.
[   803.434] (II) UnloadModule: "fbdev"
[   803.434] (II) UnloadSubModule: "fbdevhw"
[   803.434] (EE) Device(s) detected, but none match those in the config file.
[   803.434] (EE) 
Fatal server error:
[   803.434] (EE) no screens found(EE) 

reading the log, if i completely empty /usr/share/X11/xorg.conf.d/20-glamour.conf and mark it as read only chmod 444 (if i delete the file it gets regenerated) then the non drm driver starts and works

the performance of the drm driver seems better, both drivers have their issues

[6by9]

You're right that the overlay rotate override isn't updating the right DT property for rotate in DRM mode - it needs to be rotation instead of rotate. The change is easy, however my one of these panels is out on loan at present, so I can't test it. I'll create the PR if you're prepared to test.

Invoking rotation from the display can cause issues with the touch overlay then not matching. Generally it's a better option to use xrandr or wlr-randr to perform the rotation, as there are then standard mechanisms to transform the touch input to match (xinput --map-to-output, and an input-device entry in ~/.config/wayfire.ini)

[alfrix]

You're right that the overlay rotate override isn't updating the right DT property for rotate in DRM mode - it needs to be rotation instead of rotate. The change is easy, however my one of these panels is out on loan at present, so I can't test it. I'll create the PR if you're prepared to test.

idk how to compile your dts since it gives me an error

Error: piscreen-overlay.dts:9.1-9 syntax error
FATAL ERROR: Unable to parse input tree

it's an include, i have to build the kernel to compile this binary?

i've decompiled the binary changed rotate to rotation and the value to rotation = <0xB4>, recompiled, rebooted and it works, thank you

Invoking rotation from the display can cause issues with the touch overlay then not matching. Generally it's a better option to use xrandr or wlr-randr to perform the rotation, as there are then standard mechanisms to transform the touch input to match (xinput --map-to-output, and an input-device entry in ~/.config/wayfire.ini)

using xrandr will not rotate the console, and it's the first thing i've tried: DISPLAY=:0 xrandr --output Unknown19-1 --rotate inverted it will rotate the current image, but will cause the screen to stop responding

[popcornmix]

sudo rpi-update pulls/5994

will install the beta kernel that includes the rotate/ratation fix.

[alfrix]

sudo rpi-update pulls/5994

will install the beta kernel that includes the rotate/ratation fix.

doing that rotation is working i did: dtoverlay=piscreen,speed=16000000,rotate=180,drm

and the desktop works, but the console is completely broken (unrelated to the rotation value)

Edit: the touchscreen is not working on the new kernel

[alfrix]

i copied the new piscreen.dtbo to the home folder sudo rpi-update rpi-6.1.y and copied the dtbo into the overlays folder again everything is working correctly in the 6.1 kernel with the new dtbo, please consider doing a backport

[6by9]

There won't be any further official 6.1 kernel releases, so there's little point in doing a backport.

I'll reclaim my panel and see why we have the regression.

[6by9]

New Elegoo screen. 6.6.18 64bit kernel. I also saw minor corruption with the default SPI clock frequency. Dropped to 18MHz and all is good. Adding rotate=180 also does the expected thing.

I tend to use kmstest to test DRM devices, though you may need to use kmstest --device=/dev/dri/card2 if vc4 has display connected or is registered before the SPI display.

[alfrix]

adding fbcon=map:11 to the cmdline makes the console work

but the touchscreen is not responding in the new kernel ???

i did use rpi-update rpi-6.6.y kernel reports uname: 6.6.18-v8+ (aarch64)

reverting to 6.1.y i have to copy the newer dtbo to make rotation work, but touch works

i'm going to try the lite image to see how it behaves

lite behaves largely the same> kernel 6.6.16-v8+

in recent testing i found that the touchscreen is kinda working, i mean it responds sometimes every once in a while, like every 5 or 6 touches doing one per second, in kernel 6.1.y its very responsive

it's showing libinput list-devices 6.6.18-v8+

Device:           ADS7846 Touchscreen
Kernel:           /dev/input/event0
Group:            1
Seat:             seat0, default
Capabilities:     touch 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      -1.09 0.02 1.02 0.00 1.04 -0.01
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         n/a

6.1.73-v8+

Device:           ADS7846 Touchscreen
Kernel:           /dev/input/event1
Group:            1
Seat:             seat0, default
Capabilities:     touch 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      -1.09 0.02 1.02 0.00 1.04 -0.01
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         n/a

dmesg 6.6.18-v8+

[   11.886528] ads7846 spi0.1: supply vcc not found, using dummy regulator
[   11.887695] ads7846 spi0.1: touchscreen, irq 184
[   11.892020] input: ADS7846 Touchscreen as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/input/input0
[   11.943162] [drm] Initialized ili9486 1.0.0 20200118 for spi0.0 on minor 0
[   12.721028] Console: switching to colour frame buffer device 60x40
[   12.851366] ili9486 spi0.0: [drm] fb1: ili9486drmfb frame buffer device

dmesg 6.1.73-v8+

[   12.591743] [drm] Initialized ili9486 1.0.0 20200118 for spi0.0 on minor 1
[   12.594872] ili9486 spi0.0: [drm] fb0: ili9486drmfb frame buffer device
[   12.617401] ads7846 spi0.1: supply vcc not found, using dummy regulator
[   12.619718] ads7846 spi0.1: touchscreen, irq 184
[   12.620483] input: ADS7846 Touchscreen as /devices/platform/soc/3f204000.spi/spi_master/spi0/spi0.1/input/input1

[alfrix]

kernel 6.6-20 is now on the stable update channel, touchscreen is extremely unresponsive and sometimes stops responding, it's unusable.

https://github.com/raspberrypi/bookworm-feedback/assets/1247237/2bc9afad-e04e-4029-9852-ab7ab1b6fc7d

i have downgraded to 6.1 and copied the dtbo with working rotation (rpi-update 6c2b033bf556c2a2ae109ec85d86485fa4c16050) and now it works correctly

https://github.com/raspberrypi/bookworm-feedback/assets/1247237/6930e60f-8c22-4763-9241-2ad17ec819ff

ideas?

[6by9]

Upstream have updated the ADS7846 touch driver to use gpiod (see https://github.com/torvalds/linux/commit/767d83361aaa6a1ecb4d5b89eeb38a267239917a), and that applies polarity inversion based on device tree.

The piscreen dtoverlay has the polarity incorrectly defined for the pendown GPIO, so it is polling when not touched, and stopping when it is. I'll sort a PR to invert it, including speculatively fixing up all users of ADS7846.

[alfrix]

Upstream have updated the ADS7846 touch driver to use gpiod (see torvalds/linux@767d833), and that applies polarity inversion based on device tree.

The piscreen dtoverlay has the polarity incorrectly defined for the pendown GPIO, so it is polling when not touched, and stopping when it is. I'll sort a PR to invert it, including speculatively fixing up all users of ADS7846.

I can confirm it's working :+1:

you are the reason why a Raspberry Pi is worth it, Thank you

[noobmaster777]

At 6.6.63-v8-16k+ bookworm os lite, screen works perfectly with my Raspberry pi 5 through dtoverlay=piscreen,speed=18000000,rotate=180,drm However, touchscreen is not working at all. There is a cursor on the center and its stuck there. I can see the touchscreen on /dev/input/ too. (If I use dtoverlay=ads7846, the /dev/input/touchscreen disappears) Am i missing something here? Perhaps a wrong config for my /etc/X11/xorg.conf.d/99-calibration.conf? May I have a working sample? Or the /usr/share/X11/xorg.conf.d/45-evdev.conf? Help pls. My tft is a waveshare35A any help would be greatly appreciated!

[6by9]

What gets reported via evtest?

[noobmaster777]

What gets reported via evtest?

It is an available device: /dev/input/event1 ADS7846 touchscreen then when chosen is stuck at 0 and testing even when I press on the touchscreen

[robertojguerra]

At 6.6.63-v8-16k+ bookworm os lite, screen works perfectly with my Raspberry pi 5 through dtoverlay=piscreen,speed=18000000,rotate=180,drm However, touchscreen is not working at all. There is a cursor on the center and its stuck there. I can see the touchscreen on /dev/input/ too. (If I use dtoverlay=ads7846, the /dev/input/touchscreen disappears) Am i missing something here? Perhaps a wrong config for my /etc/X11/xorg.conf.d/99-calibration.conf? May I have a working sample? Or the /usr/share/X11/xorg.conf.d/45-evdev.conf? Help pls. My tft is a waveshare35A any help would be greatly appreciated!

noobmaster... can you share your dtbo or decompiled dts? I would like to make the ili9486 work in my orange pi zero 3, and I can only use DTS... I am specially interested in the reset-gpios and dc-gpios line.

I know I am very close since the ili9341 driver actually draws SOMETHING, but all my tries with ili9486 drivers dont work. Thank you!

I have the ads7846 functionality working 100%... see my DTS in https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#findComment-204672

[6by9]

At 6.6.63-v8-16k+ bookworm os lite, screen works perfectly with my Raspberry pi 5 through dtoverlay=piscreen,speed=18000000,rotate=180,drm However, touchscreen is not working at all. There is a cursor on the center and its stuck there. I can see the touchscreen on /dev/input/ too. (If I use dtoverlay=ads7846, the /dev/input/touchscreen disappears) Am i missing something here? Perhaps a wrong config for my /etc/X11/xorg.conf.d/99-calibration.conf? May I have a working sample? Or the /usr/share/X11/xorg.conf.d/45-evdev.conf? Help pls. My tft is a waveshare35A any help would be greatly appreciated!

noobmaster... can you share your dtbo or decompiled dts? I would like to make the ili9486 work in my orange pi zero 3, and I can only use DTS... I am specially interested in the reset-gpios and dc-gpios line.

I know I am very close since the ili9341 driver actually draws SOMETHING, but all my tries with ili9486 drivers dont work. Thank you!

All the official overlay source files are in the Pi kernel tree - https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts Please note that there is the drm override which switches from the old fbtft fb_ili9486 module to the tinydrm ili9486 module. The latter is the recommended one.

[6by9]

What gets reported via evtest?

It is an available device: /dev/input/event1 ADS7846 touchscreen then when chosen is stuck at 0 and testing even when I press on the touchscreen

Check for interrupts being triggered (or not) by looking at /proc/interrupts, and for the state of the interrupt line using pinctrl get 17 (interrupts are triggered on the high to low edge).

[robertojguerra]

At 6.6.63-v8-16k+ bookworm os lite, screen works perfectly with my Raspberry pi 5 through dtoverlay=piscreen,speed=18000000,rotate=180,drm However, touchscreen is not working at all. There is a cursor on the center and its stuck there. I can see the touchscreen on /dev/input/ too. (If I use dtoverlay=ads7846, the /dev/input/touchscreen disappears) Am i missing something here? Perhaps a wrong config for my /etc/X11/xorg.conf.d/99-calibration.conf? May I have a working sample? Or the /usr/share/X11/xorg.conf.d/45-evdev.conf? Help pls. My tft is a waveshare35A any help would be greatly appreciated!

noobmaster... can you share your dtbo or decompiled dts? I would like to make the ili9486 work in my orange pi zero 3, and I can only use DTS... I am specially interested in the reset-gpios and dc-gpios line. I know I am very close since the ili9341 driver actually draws SOMETHING, but all my tries with ili9486 drivers dont work. Thank you!

All the official overlay source files are in the Pi kernel tree - https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts Please note that there is the drm override which switches from the old fbtft fb_ili9486 module to the tinydrm ili9486 module. The latter is the recommended one.

Thank you... and where can I find the DRM-enabing ili9486 DTS (it should have "rotation" instead of "rotate")

[6by9]

Thank you... and where can I find the DRM-enabing ili9486 DTS (it should have "rotation" instead of "rotate")

It's an override in that overlay - https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts#L104-L105

And it does get rotation if you use the rotate override - https://github.com/raspberrypi/linux/blob/rpi-6.6.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts#L99-L100

[robertojguerra]

Thank you... until now, I didnt know about the overrides section of a DTS Thank you... still haven't made it work.. but I will add those overrides tomorrow.

I just made my ili9486 show garbled pixels all over the screen... that is progress :)

[6by9]

Try slowing the SPI rate down. As commented above, the default 20MHz of that overlay seems too high for some displays. Reducing it to 18MHz has worked on all mine, but no harm in dropping significantly lower when trying to initially get it working.

[noobmaster777]

What gets reported via evtest?

It is an available device: /dev/input/event1 ADS7846 touchscreen then when chosen is stuck at 0 and testing even when I press on the touchscreen

Check for interrupts being triggered (or not) by looking at /proc/interrupts, and for the state of the interrupt line using pinctrl get 17 (interrupts are triggered on the high to low edge).

Using 'cat /proc/interrupts' I can see the line- 171: 0 0 0 0 pinctrl-rp1 17 Edge ads7846 But it always stays on 0 0 0 0 even though i press the screen.

and with 'pinctrl get 17'- 17: ip pd | hi // GPIO17 = input

Perhaps a reinstallation would work?

[robertojguerra]

What gets reported via evtest?

It is an available device: /dev/input/event1 ADS7846 touchscreen then when chosen is stuck at 0 and testing even when I press on the touchscreen

Check for interrupts being triggered (or not) by looking at /proc/interrupts, and for the state of the interrupt line using pinctrl get 17 (interrupts are triggered on the high to low edge).

Using 'cat /proc/interrupts' I can see the line- 171: 0 0 0 0 pinctrl-rp1 17 Edge ads7846 But it always stays on 0 0 0 0 even though i press the screen.

and with 'pinctrl get 17'- 17: ip pd | hi // GPIO17 = input

Perhaps a reinstallation would work?

Try changing the pendown-gpio in the DTS, as I suggest here: https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/#findComment-204641

My previous issues with touch were because LCD and touch are sharing an SPI bus... is it the same with RPI and this model of LCD? (I work with orange pi zero 3)

[6by9]

If GPIO 17 isn't toggling with pen down, then your display is likely broken. https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A) lists GPIO 17 as the correct GPIO for pen-down. pinctrl has told you that a pull-down is active on the Pi, so the display is actively pulling it up.

LCD and touch happily share an SPI bus on this panel, although obviously with different chip selects.

[noobmaster777]

If GPIO 17 isn't toggling with pen down, then your display is likely broken. https://www.waveshare.com/wiki/3.5inch_RPi_LCD_(A) lists GPIO 17 as the correct GPIO for pen-down. pinctrl has told you that a pull-down is active on the Pi, so the display is actively pulling it up.

LCD and touch happily share an SPI bus on this panel, although obviously with different chip selects.

Thanks so much for helping typing 'pinctrl 17 op' then 'pinctrl 17 dl' made it work!!!

[robertojguerra]

Someone commented in the Aliexpress product page... and my LCD may actually be ili9488... I need to rebuild my OS again XD

[6by9]

Thanks so much for helping typing 'pinctrl 17 op' then 'pinctrl 17 dl' made it work!!!

You've just switched it to being an output driven low, not a signal from the screen. It's by chance that the driver will look at that state and continuously poll the position the whole time whenever the pen is down.

Original issue resolved, so I'm closing this.

[noobmaster777]

Thanks so much for helping typing 'pinctrl 17 op' then 'pinctrl 17 dl' made it work!!!

You've just switched it to being an output driven low, not a signal from the screen. It's by chance that the driver will look at that state and continuously poll the position the whole time whenever the pen is down.

Original issue resolved, so I'm closing this.

Hold on, last question, it seems i cant click. Would you know how i can resolve this? When i do xinput calibrator, the mouse pointer is accurate but the red crosshair wont click.

[6by9]

Hold on, last question, it seems i cant click. Would you know how i can resolve this? When i do xinput calibrator, the mouse pointer is accurate but the red crosshair wont click.

As I'd said, you've effectively told the driver that the pen is always down and just updating the position. You'll never get a "touch up" event, so are effectively always dragging.

You really need to work out why the touch controller isn't giving the "pen-down" signal - either the GPIO on the Pi is damaged (test by adding an external wire to 3V3 and 0V in turn, and ensure pinctrl reports the correct state), or the display is faulty.