Raspberry Pi 5 Bookworm ADS7846 can not rotate touch

[DRAgon734465502]

Describe the bug

I use a Raspberry Pi 5 or 4B with the lastest Bookworm OS
and with a Resistance touch using XPT2046
I add touch calibration at 99-calibration.conf
I add dtoverlay=ads7846 at config.txt

Then touch work but “99-calibration.conf” not work ， it not keep Touch Reverse
I can not rotate Touch direction by 99-calibration.conf
this same configuration work at 3B （same SD card with same LCD and same SD card OS）But not work at 4B and 5

please tell me how can I solve this problem？

Thanks !!!

Steps to reproduce the behaviour

At config.txt
dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900

sudo apt-get install xserver-xorg-input-evdev xinput-calibrator
sudo cp -rf /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf
sudo nano /usr/share/X11/xorg.conf.d/99-calibration.conf
Section "InputClass"
Identifier "calibration"
MatchProduct "ADS7846 Touchscreen"
Option "Calibration" "117 3992 3743 156"
Option "SwapAxes" "1"
Option "EmulateThirdButton" "1"
Option "EmulateThirdButtonTimeout" "1000"
Option "EmulateThirdButtonMoveThreshold" "300"
EndSection

Device (s)

Raspberry Pi 4 Mod. B

System

At config.txt
dtoverlay=ads7846,cs=1,penirq=25,penirq_pull=2,speed=50000,keep_vref_on=0,swapxy=0,pmax=255,xohms=150,xmin=200,xmax=3900,ymin=200,ymax=3900

sudo apt-get install xserver-xorg-input-evdev xinput-calibrator
sudo cp -rf /usr/share/X11/xorg.conf.d/10-evdev.conf /usr/share/X11/xorg.conf.d/45-evdev.conf
sudo nano /usr/share/X11/xorg.conf.d/99-calibration.conf
Section "InputClass"
Identifier "calibration"
MatchProduct "ADS7846 Touchscreen"
Option "Calibration" "117 3992 3743 156"
Option "SwapAxes" "1"
Option "EmulateThirdButton" "1"
Option "EmulateThirdButtonTimeout" "1000"
Option "EmulateThirdButtonMoveThreshold" "300"
EndSection

Logs

No response

Additional context

No response

[6by9]

Bookworm is using Wayfire on Pi4&5, so X configuration files will do very little.

The ads7486 overlay has a swapxy override, so have you tried using it? Correcting the touch interface to natively produce data in the same orientation as the display generally makes life far easier.

[DRAgon734465502]

】I have tried swapxy ， it work ， But when I just want to swapX or swapY， I can not find any way， this is a big problem
】other problem， I can not calibrate touch use 99-calibration.conf ， So I have any other way to calibrate ？

[thefoster]

】I have tried swapxy ， it work

With "it work" you mean that you managed to get the touchscreen aligned to the display (in landscape view)?
On my RPi4B/Bookworm with the same touchscreen (kedei) model i can not manage to get the touchscreen rotated by 90° to match the display.
All formerly used methods in other documentation that referenced on x11 config files via evdev don't seem to work anymore and there's no option beside swapxy to do the rotate in the overlay (ads7846) config in /boot/firmware/config.txt

EDIT: just updated to 6.12.20+rpt-rpi-v8, no change in that touchscreen issue.
As i couldn't find anything in the sourcecode of ads7846 regarding rotation/orientation, i don't know to fix that if X11 configs are useless.

[6by9]

#6760 adds in the invx and invy overrides to the ads7846 overlay.

Source for the ads7846 driver is at https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/input/touchscreen/ads7846.c
Source for the generic handling of inversion/swapping DT properties on touchscreens is at https://github.com/raspberrypi/linux/blob/rpi-6.12.y/drivers/input/touchscreen.c#L125-L144
Source for the overlay is at https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/ads7846-overlay.dts

[thefoster]

Wow, that was fast; i didn't really expect to even get an answer at all on this as the thread is rather old and my mind almost accepted having to run an older Raspian to make use of the Kedei display.
I'm gonna try to compile the module myself this weekend; is that enough or do i have to do that with other parts (input/touchscreen) of the 6.12 kernel?
I used to build my custom (optimized) kernels for several years, but dropped that in 2005 because of the efforts and since then just use plain/standard kernels

[6by9]

I'd noted the DT oddities for ads7846 and piscreen before, but not made the PR. Your post nudged me to do it.

If using a current Raspberry Pi OS, then sudo rpi-update pulls/6760 will download and install the CI built kernel for the pull request.

[thefoster]

So once (not really) understood the logic within the combination of swapxy/invx/invy i can finally confirm this works with a Kedei/ads7846 (cheapo in the bay) on bookworm (current 64bit desktop image) on a Pi4B.
Since hardware-compatibility between 4B and 5 should be given, it should also solve the issue of the OP on a Pi5.

"sudo vclog -m" with dtdebug=1 set:

[...]
008708.360: dtparam: swapxy=0
008708.700: dtdebug: found override swapxy
008708.758: dtdebug:   override swapxy: boolean target touchscreen-swapped-x-y
008709.655: dtparam: invx=0
008710.046: dtdebug: found override invx
008710.105: dtdebug:   override invx: boolean target touchscreen-inverted-x
008711.004: dtparam: invy=0
008711.422: dtdebug: found override invy
008711.482: dtdebug:   override invy: boolean target touchscreen-inverted-y
[...]

The line:

dtoverlay=ads7846,cs=0,penirq=25,penirq_pull=2,speed=10000,swapxy=1,invx=1,invy=0

leads to the result one would assume to be default for that display in landscpe mode, the cursor on the display moves as expected (in terms of orientation).

But we're not done yet as the default leaves an approximately 10% unusable margin on the touch surface's borders so you can not use that to interact with the menu on the desktop.
I was close to stop here because for the intended use as a touch panel in a media player i wouldn't really need that area.

OK, so we may have to adjust/calibrate it, presumably due to fluctuations in production quality. Granted.

Calibrating things is much easier with a graphical response, so i wouldn't call it "calibration" in config.txt, rather a combination of guessing/trial&error/reboot iterative approximation.

What drove me mad is that with this line:

dtoverlay=ads7846,cs=0,penirq=25,penirq_pull=2,speed=10000,swapxy=1,invx=1,invy=0,xmin=50,ymin=350,xmax=4400,ymax=4400

xmax and ymax are being ignored (according to vclog) and aagainst my first guess not because it is above the default of 4095 (in fact all xmax/ymx values are ignored that way), but because there seems to be a limitation of parameters for the dtoverlay at 10 (including module ads7846)
(EDIT: in another thread i saw the limit is actually 100 charcters)

So another dozen reboots later i put those in a separate line:

dtoverlay=ads7846,cs=0,penirq=25,penirq_pull=2,speed=10000,swapxy=1,invx=1,invy=0
dtparam=xmin=50,ymin=350,xmax=4400,ymax=4400

Now they are recognized:
[19:35][pi@rrx:~ ]$ sudo vclog -m|grep 4400

008718.985: dtparam: xmax=4400
008720.332: dtparam: ymax=4400

Although this is tedious, i now "just" have to fiddle around the best values, 3800 for max seems almost ok for now.
At least this is deterministic now ;-)

EDIT: btw. i disabled all changes in confix.txt from former approaches, they seem pretty useless on bookwork:

#framebuffer_width=480
#framebuffer_height=320
#touch_rotate=1
#dtoverlay=kedei
#max_usb_current=1
#config_hdmi_boost=7
#hdmi_drive=2
#hdmi_group=2
##hdmi_mode=87
#hdmi_mode=35
#hdmi_cvt 480 320 60 6 0 0 0
#hdmi_force_hotplug=1
#start_x=0
#enable_uart=1
#dtoverlay=w1-gpio
#touch_rotate=1
#display_rotate=1
#hdmi_timings=600 0 20 28 48 400 0 13 3 32 0 0 0 30 0 25000000 5

Bonus question: is it possible to suppress the display's boot logo (Kadei is really ugly) or even suppress all until the desktop (or whatever "real" content) is ready?

[pelwell]

Since hardware-compatibility between 4B and 5 should be given

I wouldn't say it so definitely - almost all the external peripheral interfaces are different, even though we've tried to support the same kinds of functions on the same pins - but in this case you're probably okay.