Adding Touch Support

[VidFerris]

Hi Juj;

Firstly I'd like to thank you for making this driver; I can confirm that the driver works with the Elecrow 3.5" display by using the Waveshare settings (the board seems to be just a Waveshare clone). I was wondering if you were intending to add touchscreen support in the near future, or if that is something which is on the backburner. (The Elecrow utilises the XPT2046 driver.) Thanks!

[juj]

Thanks for the report, good to hear that Elecrow works as well. Presumably it is a ILI9486 and not a ILI9486L?

Unfortunately I do not have current plans to add touch support. If someone is able to contribute, that would be greatly appreciated.

(If it is possible to wire and configure the touch controller+its existing driver to operate against Pi's SPI1 or SPI2, that may be an alternative to get both to operate independently)

[aenertia]

Hrm - I've had a look I have a number of waveshare clone 3.5 screens which all use the xpt2046 and ads7846 overlay as the driver for the touch panel. It is unfortunately shared using mosi for the lcd on spi0.1 and looking at the board schematic it is near impossible to cut traces and reroute to spi1 pins on the pi. i.e
https://raspberrypi.stackexchange.com/questions/56500/how-to-enable-spi1-pi-3-and-two-rc522-rfid-readers

What might be possible is you were to to allow for the spi0 and ads7846 overlay to be loaded whilst fbcp-ili is running - why can't you use the spi0.0 hook rather than not allowing it to be bound?

I wonder if I can hack at the dts for spidev and remove the 0x0 register stanza and just leave the 0x1 there that the touch needs...

[juj]

Good research there, thanks for posting your findings.

What might be possible is you were to to allow for the spi0 and ads7846 overlay to be loaded whilst fbcp-ili is running - why can't you use the spi0.0 hook rather than not allowing it to be bound?

Unfortunately the source of fbcp-ili9341s speed comes exactly from the exclusive unshared, unmediated access to the raw SPI0 peripheral registers that can be controlled at instruction level clock cycle precision. That is what enables fbcp-ili9341 to saturate 100% of the SPI hardware bus at all times (on multicore-Pis) without any wasted idle time on the line. At that level, it is not possible to share access to the peripheral with other drivers, as a single kernel-user context switch could mean thousands to tens of thousands lost bits of transfer time. The original fbcp driver with fbtft implements an approach that is compatible with spi0.0, not sure if that architecture could be squeezed further.

Implementing touch support to fbcp-ili9341 will need fine grained interleaving of display and touch controller communication in the hot loop of the SPI thread, one that is able to seamlessly juggle between the two devices at idle times when there are no bytes to send to the other device. It is doable, but achieving it without wasting bandwidth on the display it something to look at carefully, otherwise context switching could result in a surprisingly large % loss of transfer bandwidth.

[aenertia]

Any way you could map spi0.1 to spi1.0 within fbcp-ili9341 or through up a fake spi as a bitbanged implementation. The touch need not be fast; am just trying to avoid needing to port in a bunch of touch panel stuff into fbcp itself.

[juj]

There are unfortunately no tricks or shortcuts that I know of. The issue cannot be avoided by remapping device files, but the challenge resides in physical communication out from the hardware.

Possible ways to get touch (or any other SPI device, such as an SPI-based SD card reader) working at the same time as fbcp-ili9341 are to implement coordinated touch support to fbcp-ili9341 directly so that the communication interleaves, like mentioned above; or to rewire the device to operate against SPI1 or SPI2 (fbcp-ili9341 only accesses SPI0 peripheral, and does not touch SPI1 and SPI2, unless by accidental bug), so that another driver program can independently drive the communication over SPI1 or SPI2 (but that program should make sure it stays free from touching SPI0, or it would conflict on fbcp-ili9341). To my understanding spi-bcm2708 and spi-bcm2835 drivers have been written from the perspective that they exclusively control SPI0, SPI1 and SPI2 each, so in this mode, one would probably have to modify the kernel driver modules to disable SPI0 access, and only run against SPI1 or SPI2.

[aenertia]

The current rpi 4.14 kernel overlays have an sp1-cs3 overlay that loads the spi1 bus; and I can confirm with this loaded and fbcp-ili9431 running I don't hit any conflicts.

[aenertia]

Currently looking to add the ili9486 to this project which is kinda a mashup of your approach + fbcp but has touch support https://github.com/bitbank2/BB-CP

So far your driver gives the best results tho; just my use case is for fixed smart switch installs for IOT.

Having said that the current fbturbo implementation works much better than fbcp does with the waveshares. fbcp is laggy as hell.

The other thing as I posted is ideally I want to get these running on the sunxi-h3 boards which are MUCH nicer to work with than the original rpi's (full mainline support, proper blobless early boot seperate serial/uart header, 5v barrel jack, emmc 8gb)

[MichPonv]

Hello Author
What a great library and detailed description you have!
Your library is the only one that allows fast and efficient OpenGL rendering on an LCD, LCD-show creates a /dev/fb1 device, But OpenGL draws to a fixed buffer using dispmanx driver, and its not possible to change it to /dev/fb1 with my level of experience.

I am in the process of adding support for the touchscreen to your driver
I am only working with one touchscreen for a waveshare35b clone (XPT2046 controller)

I can read touchscreen values, but not concurrently with the display at the moment.
I should have some crude touchscreen support in a few days where it would take turns reading when the display is not being updated.

If interested in adding this to your source code I can contribute to the project,
I don't have any other displays at the moment, so I can only make the contribution for the current one.
I am not familiar with github contributions, but I'll try using what I know about git.
Feel free to contact me by email, dmitryengr@gmail.com

Thanks,

[juj]

This is cool to hear. If you have the stamina and will to try to get the feature filled in, it would be of great use for many others who have been asking for touch support.

It is ok to add support for only one touch device, as long as the support docs identify which touch controller it is, and it is not hardcoded to a specific display, since I think many displays reuse the same touch controller. So people who have a different display with the same XPT2046 controller would be able to try it out if it would work for their display as well.

Contribution is welcome, probably the only requirement is that the feature is compartmentalized/categorized in such a way that it is easy to enable/disable conditionally from command line when not used.

[kpishere]

Guys, there is now touch support in the driver. I only hooked it into the mpi3501 driver (Kedei 6.3) now as that is all i have. Give it a look and try with others. No re-wiring, ouch!

[DaleMitchell]

Guys, there is now touch support in the driver. I only hooked it into the mpi3501 driver (Kedei 6.3) now as that is all i have. Give it a look and try with others. No re-wiring, ouch!

Maybe in your fork, but not the master repo.

https://github.com/kpishere/fbcp-ili9341

[kpishere]

Dale M.: yes, juj isnt in position to test and merge back etc. Y wanna give it a go? my branch is in need of a tester.

[DaleMitchell]

I really appreciate your hard work, @kpishere! 😄

Although I'd really enjoy testing your fork, right now I don't have the MPI3501 or XPT2046, I have the ILI9341 and STMPE811 instead. But if you got the XPT2046 to work, then that must mean it's possible to get the ILI9341 and STMPE811 working as well!

I found the drivers for the STMPE in the Linux kernel:
https://github.com/torvalds/linux/blob/master/drivers/mfd/stmpe.c
https://github.com/torvalds/linux/blob/master/drivers/mfd/stmpe.h
https://github.com/torvalds/linux/blob/master/drivers/mfd/stmpe-spi.c

[kpishere]

From what i see for this device, the touch controller has its own SPI interface so you should be able to use a separate driver for it.