Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes

You should ask Robert Nelson about that.

Micka,

<cough>
https://groups.google.com/d/msg/beagleboard/w9PfhGkByQU/bE_BNG4vgHgJ

Regards,

Brilliant

Thank you Robert, and thank you Micka for the patch.

Just ran it up, booted from SD card and I cant fault the touch in the few minutes I have played with it.
Great news, thank you both.

Will continue to test.

Terry

Well, It’s good that it works in other device :slight_smile:

Micka,

Micka:

I am now adding a Debian BBB to my collection to drive a 3d printer and need to apply your patch. The new image did not work for me (hung on a black screen of death) so I followed the procedure for rebuilding the kernel per an earlier note of yours. Unfortunately during this process I trashed the am335x_tsc file and was wondering if you know how I can get a source copy from the web…or if you can send me a copy of your patched version…

Thanks for any help you can render!

Cheers,
Will

Hi,

I step in as everybody looking to find solutions for TS issues. Actually, I’m still working on solving it. However, I have some tips and “discoveries” I’d like to share, meby someone will find it useful.

  1. I have just external TS, no cape at all, the TS is 10 inch.

  2. I found “after many hours :(” that ti_am335x_tsc driver can not be build in, and must be loaded as a module after the cape for TSC is loaded. That’s because I use “overlay-ed” cape for TSC. Even though it is set to be loaded in uEnv.txt!

  3. Big touch screen has bigger capacity, it results in permanent “auto-touch” event generation, driving me nuts since LCD7 TS works nicely. I have discovered, that adjusting delays in driver is the solution!!! There are “open-delay”, “sample-delay”, “charging-delay” defined in ti_am335x_tscad.h file. They have fundamental influence on this effect. Someone has mentioned that “hardware issue” was observed as a few “auto-touch” glitches. That is exactly this, just in case of a smaller TS, it is not so evident.

So, concluding, now I’m focusing on adjusting delays. I’ll let you know my setting for this 10inch TS.

Regards,
Piotr

Hi Piotr,

Have you studied the errata for the processor? IIRC some issues and workarounds with the TSC are documented there.

-- Bas

Good point! However, the issue in the errata is about “pen-up” whereas I had “pen-down” false interrupt. Increasing charging time clearly moves the problem away.
Piotr.

W dniu poniedziałek, 24 lutego 2014 14:45:31 UTC+1 użytkownik Bas Laarhoven napisał:

Hi Micka,

Would you be able to send me the driver you compiled with these changes? RobertCNelson’s latest builds (-40) have ti_am335x_tsc.ko from last year.

I tried the steps you provided last night, I got as far as compiling the kernel but the driver I made had invalid ELF data so I did not try loading it.

Alternatively, the patch you have, which version of the ti_am335x_tsc.c driver is it meant to patch? there’s been a lot of activity on ti_am335x_tsc.c.

Hi Micka,

Any chance you can post the ti_am335x_tsc.ko that you compiled for debian? RobertCNelson’s recent releases contain an old ti_am335x_tsc.ko (from last year).

Are you sure ? => https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.8/patch.sh#L847

My apologies:

-rw-r–r-- 1 root root 11K Feb 15 01:10 ti_am335x_tsc.ko

The jitter does not seem to be much better with this. Worse than the jitter is sometimes when I press and release, there is a much larger jump, say 50 pixels away from my finger. I see this with a 4.3" newhaven display. I have some 7" screens on the way, perhaps there will be a difference there?

If you have an oscilloscope I’m sure that you can see this crazy noise … . During my test i could saw the noise in the driver.

I also discovered that the TI driver include a filter to the jitter issue =>
module dejitter delta=100

I’m sure the jitter filter from TI is much better than mine …

… maybe it will be better to use the TI driver (TSLIB) than the default driver … .

Robert Nelson ? Any idea how to do it ? I found some tutorial, but in my last tried I didn’t succeeded :

http://boundarydevices.com/debian-in-more-depth-adding-touch-support/

Micka,

I love TSLIB, their modular approach and on the fly tweaking allowed me to get the touchscreen working really well… Then I found that X11 no longer supports TSLIB :frowning:

My option was hacking this driver (which you’ve done to an extent, thanks again) or downgrading all of X11 to be compatible with TSLIB again. Maybe that’s a better option, I’m not sure.

Is calling tslib from the driver what you’re suggesting Micha?

There is a part in the driver (ti_am335x_tsc.c):

config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev->bit_yp |
ts_dev->bit_xn | STEPCONFIG_INM_ADCREFM |
STEPCONFIG_INP(ts_dev->inp_xp);
titsc_writel(ts_dev, REG_STEPCONFIG(end_step), config);
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
STEPCONFIG_OPENDLY);

end_step++;
config |= STEPCONFIG_INP(ts_dev->inp_yn);

There is possible bug, with using “OR”. It does not show up when XP → AN0 and YN → AN3 because 0 is ORed to 3 (fortunately). With other X/Y plate connections, z2 might be totally wrong.

Regards,
Piotr.

I have been playing with touchscreens for the last couple weeks. I noticed the following:

For both 4.3" and 7" resistive touchscreens I have, the jitter is significantly better in the default Angstrom versus Debian. Angstrom jitters with around 5pixels of the touched point, Debian is >20pixels

Looking at Debian, it seems to have a much newer version of the touchscreen driver than Angstrom does. I believe this is the revision angstrom uses:

Last time steps_to_configure was available:
https://github.com/torvalds/linux/commit/af9c2fe3740fe8dac05eede8805d9aaa45972cb6

Change from steps_to_configure to coordinate_readouts:
https://github.com/torvalds/linux/commit/0396310b0eba71595c1151ce7c8fde7a9f33f719

Angstrom’s DTC files for touchscreen refer to ‘steps-to-configure’ where Debian’s has the newer ‘coordinate-readouts’.

I would be happy if the quality of touch input that I get from Angstrom existed in Debian, so I’ll try to compile the old driver, then recompile my DTC files and use steps_to_configure and report back.

I have a solution!

1). grab install.me from here: https://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone21/ and run it. It’d downgrade your kernel

2). Change your .dts files from touchscreen drives from ti,coordinate-readouts to ti,steps-to-configure and compile

3). Enjoy really nice touchscreen operation!

How I found this out: 3 days of fiddling with this! I noticed that the angstrom release’s touchscreen works really well. I saw their .dts files had steps-to-configure in it instead of the newer ti,coordinate-readouts. I then read the driver changes in ti_am33x_tsc in linus’ repo and traced it back to June 2013 which was the last time that ‘step-to-configure’ source was available. I don’t know how to compile this file on it’s own so I grabbed a RobertCNelson kernel from around that date (linked above). Ran install.sh, changed and recompiled my dtbo and voila!

I’ll leave it to the dedicated people here to decide if they want to merge the two drivers together into a newer driver that’s also perfect response. Btw, the driver author wrote in the source about fixing this exact jumping problem:


	/*
	 * Delta filter is used to remove large variations in sampled
	 * values from ADC. The filter tries to predict where the next
	 * coordinate could be. This is done by taking a previous
	 * coordinate and subtracting it form current one. Further the
	 * algorithm compares the difference with that of a present value,
	 * if true the value is reported to the sub system.
	 */

I see that note missing in newer versions and that section gone, so this critical piece of code was removed for some reason.

time for the champagne :)

I seem to have some issue posting to google groups via the sites, my apologies if this gets duplicated.

I have a solution!

1). grab install.me from here: https://rcn-ee.net/deb/wheezy-armhf/v3.8.13-bone21/ and run it. It’d downgrade your kernel

2). Change your .dts files from touchscreen drives from ti,coordinate-readouts to ti,steps-to-configure and compile

3). Enjoy really nice touchscreen operation!

How I found this out: 3 days of fiddling with this! I noticed that the angstrom release’s touchscreen works really well. I saw their .dts files had steps-to-configure in it instead of the newer ti,coordinate-readouts. I then read the driver changes in ti_am33x_tsc in linus’ repo and traced it back to June 2013 which was the last time that ‘step-to-configure’ source was available. I don’t know how to compile this file on it’s own so I grabbed a RobertCNelson kernel from around that date (linked above). Ran install.sh, changed and recompiled my dtbo and voila!

I’ll leave it to the dedicated people here to decide if they want to merge the two drivers together into a newer driver that’s also perfect touschscreen response. Btw, the driver author wrote in the source about fixing this exact jumping problem:

/*

  • Delta filter is used to remove large variations in sampled
  • values from ADC. The filter tries to predict where the next
  • coordinate could be. This is done by taking a previous
  • coordinate and subtracting it form current one. Further the
  • algorithm compares the difference with that of a present value,
  • if true the value is reported to the sub system.
    */

I see that note missing in newer versions and that section gone, so this critical piece of code was removed for some reason.

Hello!

Having same kind of issues with the 7" 4D systems cape, even with Robert Nelson’s patched driver, I resolved the issue by increasing SEQ_SETTLE value to 1023 in ti_am335x_tsc.c .

Hoping it could help someone.

Olivier