-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
too low touch event polling rate with official Raspberry Pi 7inch screen #3227
Comments
Taken a quick look at the firmware side drivers, and that polls at 60Hz. So the delay is probably elsewhere. edit: Linux side driver is the same - 60Hz polling. |
The monitor mode comment above may well be correct. The driver itself does nothing to switch in and out of any modes - just polls the chip at 60Hz. |
Yep, but that change from Monitor to Active should be automatically. I think it's unlikely the mode switch doesn't happen, the driver shouldn't need to interfere with that at all. It's possible that somehow some settings of the FT5426 are changed by the firmware driver that are badly chosen. But even then, it really bugs me that the interval is exactly 40ms. If the FT5426 and firmware/linux were running at different polling rates, you'd expect anything but an exact 40ms interval in userspace, wouldn't you? EDIT: Just looked at the linux driver again, it doesn't check if the touch buffer contents changed at all. |
Looking at the firmware side, and the datasheet, I suspect it is going in to active mode, but then dropping straight back to monitor mode. I'll do some tests to see if setting the timeout a little larger makes a difference. |
Quick question - running your test above, I get no events from the touchscreen at all. Moving the mouse gives me 62Hz update, but not events from the TS at all. Anything specific I need to set up? |
Ah, using /dev/input/mouse1 is what I need. Showing 25Hz using the default settings. |
I just built a python GPIO I2C sniffer and looked at the traffic on i2c-0. The VideoCore polls the FT5426 at 60Hz, but also, the FT5426 correctly replies with up-to-date touch data (nearly) every time. I measured across 10 seconds, and the average time between polls with up-to-date touch data was about 19ms. Not 17ms, but also far away from 40ms. If you want to test it yourself, the repo is located here. It seems like you need to physically connect the touchscreen's i2c pins to the Pi for it to work. Sniffing pins 0&1 (where i2c-0 should be located) doesn't work for me, somehow. What do you think? I personally am more and more convinced it's actually a linux driver bug. The VC <-> FT5426 comm. is working as it should (if my i2c sniffer is to be trusted), and that exact 40ms interval in userspace really shouldn't be there. |
BSC0 (the I2C controller behind /dev/i2c-0) can be pinmuxed to GPIOs 0&1, 28&29, or 44&45, but only one set at a time. The firmware has a thread for polling the touchscreen. It sleeps 17ms, and then reads the data into a buffer shared with the Linux kernel. |
Useful information, I was unsure how to check if the controller was actually returning data at 60Hz. In your sniffing, did the data change at 60Hz, or 25Hz? I have tried setting the appropriate registers in the controller to set/change the monitor/active timings and see no difference in the overall poll rate in userspace, which make me wonder if the linux multitouch/input system has some setting I need to change to set the correct report rate. |
That's what I meant, the data changed at 60Hz. There were some few occasions where the data didn't change between polls, but they are well within the margin of error. EDIT: I'm currently looking at other multitouch drivers trying to find a difference, but so far I've found nothing.
Ah okay; the pinmux explains it all. Should've sniffed on 44&45 then. |
OK, so it appears the hardware is doing the right thing, firmware is doing the right thing, and the linux side of the driver is doing the right thing, but for the life of me I cannot find out if/where there are any rate control mechanisms in the linux input subsystem - there must be something dropping it back to 25Hz (and occasionally for one sample 12.5Hz). Will keep looking. |
Ah ha! Turns out the linux driver is NOT actually doing the right thing. The use of msleep_interruptible to do the millisecond timing is incorrect in this situation, where the delay is <20ms (see https://github.com/torvalds/linux/blob/a351e9b9fc24e982ec2f0e76379a49826036da12/Documentation/timers/timers-howto.txt). Replacing it with usleep_range and I get 60Hz refresh, which looks a LOT better. I'll do a PR. |
PR is here #3238 |
Nice! |
kernel: Fix poll rate on touchscreen See: raspberrypi/linux#3227 firmware: Round up HDMI0 minimum core clock firmware: board_info: Support bcm2710- and bcm2837- Pi 2 DTBs See: raspberrypi/linux#3234 firmware: power: bcm2711: Rescale the GPIO pad power firmware: brfs: Add GENET driver for 2711 firmware: bootloader_state: Add network state and bootmode configuration firmware: bootloader_state: Fix mask for EEPROM header magic
kernel: Fix poll rate on touchscreen See: raspberrypi/linux#3227 firmware: Round up HDMI0 minimum core clock firmware: board_info: Support bcm2710- and bcm2837- Pi 2 DTBs See: raspberrypi/linux#3234 firmware: power: bcm2711: Rescale the GPIO pad power firmware: brfs: Add GENET driver for 2711 firmware: bootloader_state: Add network state and bootmode configuration firmware: bootloader_state: Fix mask for EEPROM header magic
A useful tool for testing events was found here https://github.com/ian-kelling/evhz |
Was running at 25Hz, rather than he expected 60. Only been doing it for the last 5 years.... Replace msleep_interruptible with usleep_range as the msleep call is not accurate for times < 20ms. Fixes: #3227 Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
If you open
/dev/input/event0
directly, repeatedly read from it, and measure the interval between individual reads, you'll find that this interval is around 40ms, so 25 touch events per second / 25Hz.However, the specs of the FT5406 say it can do up to 100Hz (in practice probably around 60Hz), and the source code of the official raspberry pi touchscreen driver says it polls the touchscreen with an interval of about 17ms, or 60Hz.
This doesn't seem to be the case. 60Hz and 25Hz touchscreen report rate is a huge difference for responsive touch applications. If you drag some object in a touch application, but your finger position only updates 25 times per second, then that object only redraws at 25fps too. The whole application will feel laggy.
To reproduce
Run this:
Expected behaviour
Expected is a 60Hz polling rate, as specified in the driver and in the FT5406 specs.
Actual behaviour
In reality the polling rate is 25Hz.
System
When the FT5406 is in Monitor mode, it polls at 25Hz. However, if it then detects an input, it immediately switches to Active mode for a configurable time and polls at 60Hz. Maybe the time in active mode is somehow set too low, so that it in practice never really gets out of Monitor mode?
The text was updated successfully, but these errors were encountered: