official 7-inch touchscreen polling rate too low #3777
Comments
|
Any news on this? Basically every other generic touchscreen is working better right now (both in terms of polling rate and latency) than this officially supported one. |
|
5.4 has adopted the mainline driver from drivers/input/touchscreen/raspberrypi-ts.c rather than the downstream drivers/input/touchscreen/rpi-ft5406.c It appears to have defined 60fps polling, but it offloads the poll process to the framework by the looks of it. There is one commit in later kernels (>=5.5) that changes this driver, but I haven't looked to see if the required framework change are in 5.4 or not. |
|
I can confirm it seems like its the linux-side again, the firmware-side is polling the TS at approx 57Hz according to my i2c sniffer. The intervals between events are most commonly 30ms, sometimes 60ms and very rarely 40ms. It's kinda strange. The
I did a little bit of research and it seems the actual implementation didn't change much. |
|
While the driver is different, the cause of the slow polling may be the same as #3227 (comment) |
|
I've had a very brief look at the framework for input_poller and it looks plausible. It's using |
Do you want to do that? I can do it, if you want me to. I kinda have the feeling though they'll say we should just increase the |
|
@pelwell Do you have a feel for the delay accuracy on
There is some work in mainline to write drivers for the Toshiba TC358752 DSI to DPI bridge and the touchscreen controller. One issue is that they share an I2C controller with the camera module, so if you shift the touchscreen to the kernel then you can not use the firmware camera stack (you can use libcamera which is all ARM side). |
|
I'd be tempted to create a delayed_work item that just requeues itself 1 jiffy later for 100 iterations, and log the times. |
|
So, according to this doc on linux work queues,
Either way, I'm amazed by how inaccurate EDIT: I somehow though |
|
The kernel devs have been introducing sleep ranges and other "inaccuracies", allowing power savings by batching up activity to increase the length of the low power states. This could be a consequence of those changes. |
Could be. Though I just looked it up and |
|
just for completeness: with the new |
|
Any updates on this issue? This issue is making it hard to use the pi display for our product. Even button click events cause a lag that is hard to not notice |
|
based on @ardera's comment about rounding up the jiffies I changed raspberrypi-ts: Latest 50Hz, Average 47Hz Then setting HZ to 250 in the config: raspberrypi-ts: Latest 50Hz, Average 56Hz This led to VASTLY improved gesture support on the screen with Qt/QML code Of course the correct solution is to have the input-poller code get the timing correct but this solution may help others |
Describe the bug
The rate of input events arriving at userspace when using the Official 7inch touchscreen is too low. Input events arrive at user space at about 33Hz, resulting in perceived lagginess of touch applications, even though the application is running at 60fps.
This bug was present once before, see #3227, so this is kinda a regression. I'm not sure exactly what commit/update caused it to go back down to 33Hz though.
To reproduce
See #3227
Expected behaviour
Expected is at least 60Hz, possibly even higher (since touchscreen controller seems to support 100Hz, and higher polling rates result in less input lag. All iPhones past iPhone X for example poll at 120Hz, some android gaming phones at 240Hz)
Actual behaviour
The frequency of input events arriving at userspace is 33Hz.
System
Logs
evhz output:
kinda offtopic
Is there any way the (actual) touchscreen driver can be moved out of the firmware into the linux kernel, and be modified to use interrupts if the user wants so? The delay is pretty bad to be honest, less input lag would make the Raspberry Pi actually very usable for modern UI (using flutter and my flutter-pi project).
The text was updated successfully, but these errors were encountered: