Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes


I have a 4DCAPE-43T LCD and tested it with Beaglebone Black and the latest Angstrom image (2013.08.21). Unfortunately, I am experiencing input jitter / jumping. I use TSlib’s ts_calibrate for calibration and ts_test for testing. In Gnome’s calibration tools the same problem appeared: Instead of clicking, I often have some dragging or even random jumping of the pointer. The problem appears especially if the pressure applied to the touchscreen is lower.

I wrote 4D SYSTEMS support regarding the touchscreen jitter and got the following reply:
“The 4D Cape 43T LCD has been based on the LCD4 from Circuitco and uses the same drivers written for the LCD4 on the Angstrom. Upon testing and verification, the problem of jitter is evident as well on the LCD4 display of Circuitco using the Angstrom 2013.06.20 and 2013.08.21 images so in effect this has nothing to do with the hardware but it’s a software problem.”

Actually, I found a video on Youtube with LCD7 where a similar jump / jitter problem can be seen: @ min 2:00

Any idea how the problem can be solved?

Thanks in advance,

Update: I bought a LCD4 from Circuitco to compare.
Unfortunately, the same jitter problem on the touchscreen can be observed.

Anyone else observing this problem?


… to continue my monologue:

I observed that the jumps appear when the pressure applied to the touchscreen is lower. So I tried to filter the lower pressure inputs in TSLIB’s ts.conf. I entered

input module pthres pmin=200

instead of the default input module pthres pmin=1

This seems to remove the jumps but it turns out that the pressure values differ in the different parts of the touchscreen. I tested it with evtest.

So in the lower part of the screen I get only values < 200 and therefore no matter how hard I press on the TS the input is ignored due to my filter and this part is not usable anymore.

I have no idea why the pressure values read in the upper left TS part in comparison to the lower right part are so diffentent…

UPDATE: Just tested with the old 2013.06.20 Angstrom image (3.8.13 kernel) and there the touchscreen functions perfectly. So it looks like that in the later ADC / TSC updates some bug must have been introduced :frowning:

Hi Anguel

I too have the same problem. I have a LCD4 and a LCD7 and both do the same thing.
I suspect since the 4D Systems displays use the same drivers the 4DCAPE-43T does the same thing, so it doesn’t seem to be hardware related at all since they use different brand touch screens.

Have you had any reply out of CircuitCo?
Does CircuitCo actually write the drivers or is it someone else?
Can anyone help and point us to someone who wrote the drivers that we can discuss this with?

I know a number of other people who have these displays and experience the exact same thing, so it is not just isolated to us 2 people.

Please can someone point us in the right direction?


Hi Terry,

Nice to know that I am not the only one who cares about the touchscreen. Neither CircuitCo nor 4D Systems seem to really care about the problem. They sell the displays but don’t reply to my e-mails anymore. I also reported the problem on Beaglebone IRC but did not receive any help there. I even tried tweaking a bit in the kernel but without success. I just don’t have the experience to dig deeper in the ADC drivers and chase for the bug.

The latest patches were actually submitted by Zubair Lutfullah, he seems to adapt them (from the TI driver developers who write them for the older kernel afaik). Zubair told me that he already knew about the jitter problem and gave me the following reply: “The touchscreen driver that was patched in the linux kernel was different compared to the old patches in the beaglebone tree. And we try to keep the beaglebone tree close to the mainline. The old 3.8 patches were ok. The mainlined ones introduced this problem… A fix would require a comparison of the two drivers to figure out what went wrong and upload a patch to the mainline… It would require time…”

Unfortunately, Zubair is very busy right now. He also mailed his reply to Koen Kooi, one of the main Angstrom developers (also works at CircuitCo according to his Google+ profile). I am afraid that Koen is also very busy and won’t have the time to look into the issue. So we can just hope that someone with more experience can fix the issue in the near future.


As was previously indicated to you, this is an issue with X11, a bug. If you will fix the X11 it should work fine. Or just use the latest Angstrom build.

This is you decision as to how you handle it.


Hi Anguel

Probably a little harsh to say CircuitCo and 4D Systems don’t care about the problem. If you look at what 4D Systems claims, they state the software is not written or supported by them and they are essentially supplying hardware only, so they are actually unable to do anything about it even if they wanted to. I am still confused about what role CircuitCo plays, if they are just a hardware supplier or do software too. and along with TI and all the other players, I really have no idea who does what.

I do hope however we can get to the bottom of it.

Hi Gerald

Being a beginner with Linux, I don’t even know what the X11 is. I have tried the latest Angstrom release for the BBB and the touch issue is still present, or are you meaning something else?
It does seem a little disappointing how the software does not work correctly for the hardware. I have a friend who was building an industrial product with the LCD4 and BBB, yet due to the touch issues the product was useless, so he ended up using a different solution entirely. I am sure there are many others who fall into this camp too.

I do hope we can find a solution


When things change upstream and break, it can take time to get fixes created, tested, verified, and back upstream so it works out of the box. A lot of things changed in the 3.8 Kernel. But, only the owners can fix it, unless someone wants to create a patch to make it work. Then again, by the time one would create that, the owner would have fixed it.

Linux changes all the time. If you want full SW support for these displays then you would need to add $500 to the cost of each of them. The concept here is the people that buy them, know how Linux works and can get things going themselves and make what ever tweaks are required. Supporting all the different kernel versions and distributions, that is no feasible.


Just downloaded the TI Android 4.2.2 release, which works for the LCD4 so should work for the 4DCAPE-43T also.
No touch issues. Installed a few drawing apps and it performs nicely.
Installed a screen rotation utility and that enables portrait or landscape mode so that works nicely too.
Played some videos and that works nicely.
Overall rather happy. Proves its not the hardware.


How do you know this is a X11 bug? I see the same bug with TS_LIB. It is somewhere deep in the driver.


Linux changes all the time. If you want full SW support for these displays then you would need to add $500 to the cost of each of them.

That’s an interesting calculation, I wonder how you have calculated that price. The CircuitCo LCD prices are actually very high for what they offer. So please don’t tell me that they do not make any profit and do it only because they like the Linux community.

The concept here is the people that buy them, know how Linux works and can get things going themselves and make what ever tweaks are required. Supporting all the different kernel versions and distributions, that is no feasible.

Probably this is the nice business concept used by TI, CircuitCo, etc. Sell chips and boards, make money, but let the open source community write the software and support everything for free. Just make a product, label it to be “for developers” and sell it without any support. This seems to be a very nice buisiness model. Those boards and capes are not made by students in a garage and sold in low quantities, they are professionally distributed through Digikey, Mouser, etc. and TI and CircuitCo do profit from the sales. You say that every developer who uses the boards is supposed to be able to rewrite and patch low level Linux kernel drivers? He is supposed to have the time, knowledge and ressources to fix bugs that would cost the manufacturers hundreds of thousands of dollars? Here I am just referring to your $500 price tag! And if someone fixes the bugs for free this just means that CircuitCo, TI, etc. can sell even more “development boards” and chips. Nice concept…

Who is actually behind It is TI and CircuitCo as far as I see. Refering to your other post, pointing me to “just use the latest Angstrom” I wonder if you have not read my previous posts. Nobody has ever pointed me to any X11 bug (which IMHO is not the problem at all). Zubair, one of the driver developers, has clearly stated that the bug is known and is caused by the drivers which are in the kernel. If I am not mistaken, you are responsible for, you are a TI employee and you are responsible for quality assurance. I still wonder why it is still not written in big red letters on the LCD pages of CircuitCo (and 4D Systems should then copy and paste that) that NONE of their displays work with the latest Angstrom images. Please update that information so people can think again if they should buy those boards and capes for their projects.



That is what I was told by Circuitco.



CircuitCo support did not even answer my e-mail regarding the non-functional touchscreen. 4D Systems at least admitted that this is a well known problem. Once again: Why don’t they clearly state on their LCD product pages that the touchscreen does not work in latest Angstrom? I really hope that customers see my thread before buying a LCD with touchscreen.


I would not buy it either. Contact the president at:


There is a difference between “any support” and “not supported”.

“Not supported” means that it has been tested under a very specific software configuration and works for that configuration. If you check the Linux Source code, you will find a LOT of code written by Texas Instruments - so they are certainly providing SOME support.

Interestingly, if you check the LCD drivers you will find that for small LCD screens, most of those drivers come from Nokia[or at the very least are based off Nokia drivers].

So no, it is not “the community” that is expected to support things “for free”. How it works is that Nokia, a cell phone manufacturer, decides to use a Texas Instruments processor in a cell phone. They decide to use a specific model of LCD screen. They pay developers to create an LCD driver for a Texas Instruments supported linux kernel. If they find a bug in the TI LCD interface, they contact TI and TI works with them to fix it. Once they have the TI supported kernel working, they then try to use the same driver in the latest version of Android. If it doesn’t work, their developers have to figure out what changes were made that broke something, and then they fix it. Considering that their going to order 100,000+ TI processors, they probably pay TI for support so their developers and TI’s developers work on the driver.

When that is all done, this driver which was written by Nokia with Texas Instruments help is then given to “the community” for free - under the terms of the standard GPL license, including:

Please note that last line as it is the one you seem to object to, and yet it is the very reason companies are willing to give away applications they paid developers to write to the community - as they are not required to support them and you agreed to assume the cost.

Android does NOT use the X11 window system, so the driver written by Nokia for their phone may not work properly for a Ubuntu desktop. As the reason Nokia paid developers to write it was for an android phone, I can’t see any reason to expect them to make sure it works for Ubuntu “for free”.

Your receiving a huge amount of support from TI and CitcuitCo - however your “tone of voice” is demanding that they FIX the problem. They are not required to fix the problem, and you agreed to assume the cost of all correction. In all fairness, they should be billing you for the time spent responding to you as you agreed to “assume the cost”.

You have identified a problem. Programmers from “the community”, “Texas Instruments”, and “CircuitCo” have acknowledged the problem, done a good bit of deductive reasoning to determine where the problem lies and the general idea of how to fix it and given this information to you for free.

There are four solutions specifically for you:

A) Use the linux versions that are known to work for the device, move on with your life.

B) Wait for someone to be willing to fix it “for free”

C) Fix it “yourself” - note this does not mean you personally, this means either you fix it or hire someone to fix it.

D) Give up in frustration and use a different product. If you wish, loudly proclaim that “everything just works out of the box”. A few weeks down the road you will discover a different problem with the interaction of a completely different set of drivers that the vendor of that product doesn’t use and does not support. When you do, if you choose to loudly proclaim your “solution” you can choose to acknowledge that your solution that “just worked” actually does not work so others who may be misled by your comments to also switch don’t suffer the same issue. Or you can keep quiet about it to avoid looking foolish and thus cause economic harm to others.

As a summary “not supported” means that the company is not required to pay engineers to fix problems you discover.

As for making money, my understanding is that the Beagle Board line of products makes enough money to just about break even. Ie the little money made per board is used to pay for TI engineers time in answering questions and designing the next board. From a corporate standpoint, the point is not to “make money” selling BeagleBoards - but rather to provide thousands of smart people with a system that they can use create nifty tools. Out of the hundreds of nifty tools created, a few of them will have broad commercial potential. Some of those will get enough financial backing to have thousands of them made by a company and offered for sale. Maybe half of those commercial products will use the same processor as used on the BeagleBoard since all the code was written for it. The other half may well use a completely different chip from a different manufacturer which has a high enough price difference to justify rewriting programs. The processor won’t be as powerful, but it will do the job.

So TI’s money comes from those few products that make it to being sold commercially and still use the same processor. This is certainly a successful business - there is a symbiotic relationship between “the community” getting free software from TI and TI getting improvements from “the community” for specific use cases.


circuitco responds to ALL emails sent to and for products produced by circuitco. we have responded to a number of emails with questions about the jitter issue. we provide recommended configurations and setup for all of the products, however we sell the hardware independently for developers to do as they choose with it. i highlight that fact… developers. we can not test every single software load out there for every single product. as such a developer is responsible for configuring their own software functionality. we provide a warranty and guarantee on the hardware along with full documentation. one of the ways we keep costs low is for these products to be community supported. if you are unhappy with the lcd cape, we will be happy to refund your money for both the cape and beaglebone black so that you may select something more to your liking. may i suggest the TI AM33x EVM platform? ( it retails for $995USD…

Dave Anders


Thank you for your extensive and philosophic point of view. I just don’t understand how Nokia is related to the problem… It is clear that at some point in time some bug has slipped into the TI SoC ADC kernel drivers or the touchscreen drivers that use these ADC drivers. What I am angry about is that CircuitCo (and 4D Systems) know about the problem. Besides the fact that they don’t do anything to fix it (although afaik they have good people working on Angstrom), they could at least post a notice on their product’s webpages so customers don’t have to chase where the bugs come from for weeks. The fact that they have still not done it makes me think that they want to keep their sales high. Again, the prices for the LCD boards are not low and we cannot talk about break even here. I am sure that actually many units are being sold together with the high sales volumes of the Beaglebone + Beaglebone Black.



The only thing that I can say is that CircuitCo never answered my e-mail. If you have responded to so many e-mails regarding the jitter issue and after the long discussions here I really wonder why you have STILL not put a note that there are well known touchscreen issues with the latest official Angstrom images. This would prevent many developers like me from spending many weeks searching for the source of the problem and wasting their time. Or are you afraid that your sales may drop if people know that the touchscreens of your displays don’t work with the latest kernel?

Regarding your suggestion for the $995 TI EVM board I may suggest the AM335x Starter Kit for $199 only.



Thank you for your extensive and philosophic point of view. I just don’t understand how Nokia is related to the problem…
It is clear that at some point in time some bug has slipped into the TI SoC ADC kernel drivers or the touchscreen drivers that use these ADC drivers

If your talking about touchscreens interfaces and LCD screens, your very likely using code written by Nokia or one of the other major cell phone manufacturers. If there is a “bug” in the code it is likely that they wrote it. Because the code DOES work under a different version of Linux and works under versions of Android - it is not even fair to say the the driver has a bug in it. The driver works for the system it was written in. Why it doesn’t work in later versions of Linux may be because there was a true bug which only showed up when something else in the kernel changed. It may also be that there were changes to the api functions being used by those drivers which changed the way they work. The word bug tends to be taken negatively, as in the programmer of the code containing the bug made a mistake. In the case of changing API’s there was no “mistake”.

To understand why you have to understand how Linux itself is developed. There are thousands of drivers in the codebase for different items. For those drivers to get into the source tree they must compile AT THE TIME THEY ARE ADDED, they must follow Linux Coding Standards, they must work AT THE TIME THEY ARE ADDED, and they must be licensed under the GPL.

Once they are IN the codebase then when changes are made to any of the functions they use, the programmer making those changes MUST run an automatic program to find every single call to that function and fix them - hopefully the process will be automatic. Those changes have to follow the same rules as above PLUS every bit of code that they modified[all the drivers] must still compile successfully. Note: it doesn’t have to WORK, it just hast to compile. That is because it would cost millions of dollars to test every single bit of hardware[since you have to have access to every single bit] to ensure that the drivers still function. The best that can be reasonably expected is that they compile.

A better word to use is incompatibility - as you simply have no idea where the “bug” is so unless you specify each and every component that is being integrated then saying there is a bug in X companies code comes across as blaming the companies listed.

As for why I went into the long explanation, you were making comments about how TI expects “the community” to support their product for free - so I was giving you the true picture - how is a symbiotic relationship and how in this case your benefiting from work done by TI and Nokia - and that “the community” is expected to modify that work for their own usage if needed.

. What I am angry about is that CircuitCo (and 4D Systems) know about the problem. Besides the fact that they don’t do anything to fix it (although afaik they have good people working on Angstrom), they could at least post a notice on their product’s webpages so customers don’t have to chase where the bugs come from for weeks.

The comments in this thread indicated to me that they contributed to fixing the problem - in this case identifying where they think the problem lies and therefore cutting down on the time needed to debug code.

I will agree 100% that CircuitCo should update their product pages to include notices of compatibility issues as well as listing a known good software version compatibility matrix. I only agree about 60% that 4D Systems should be doing this as well.

The fact that they have still not done it makes me think that they want to keep their sales high. Again, the prices for the LCD boards are not low and we cannot talk about break even here.

We can’t? Consider the following:
SainSmart makes a similiar LCD module for Ardunio:
It costs 16$. If you go to ebay you can find similiar products for 12$.

Compare this to CircuitCo’s 3" board:
Which is 70$.

So what are the differences? Well, first of all, the pin layouts for the boards are completely different. BeagleBone capes have 2 rows of pins, while the Ardunio board has 1 row of pins. I know that pins seem like a nothing cost, but the truth is that every time you add big bulky items to a board - you increase production costs. So taking a stab in the dark, I’m going to guess that we added 4$ to the cost of the card(20$). In addition to this, a beaglebone cape needs an EEPROM on it which is programmed with the device tree configuration of the card[to allow the bone to automatically detect the card and configure itself]… So let’s call that another 5$ since while the chip may not cost much, we added another step to produce the board where the chip needs to be programmed and tested(25$). Lastly, the Ardunio is an extremely popular product - so for every 1 BeagleBone cape sold, let’s say 100 Ardunio capes could be sold. Production cost is directly related to how many you build, so I’ll guess that the cost is halved for making 100 of a product vs 1[or 100,000 vs 1000]. So that brings the comparable cost up to 50$.

50$ vs 70$… Yes the price seems high, but it is not twice my rough estimates, so I’m gonna give them the benefit of the doubt.

Keep in mind, due to this price difference I myself am planning on getting the Sainsmart module and seeing if I can get it to work…but then I also consider hacking away at it entertaining. So I am not the type of person to feel that the price difference is trivial. I just would not go around assuming that the pricing is inflated because I lack sufficient experience in pricing board production to make any sort of fair estimate. I know enough to know that there are lots of variables that affect cost - and I know enough to understand that all the numbers I come up with I am pulling out of my but.

You have one valid, in my opinion, complaint: CircuitCo and 4D should post more information regarding compatibility on their product pages. The problem is it is buried in so many other comments that I don’t consider reasonable that it is hard to differentiate.

Based on observation of your comments here, I can only assume your comments were written in the same manner when communicating with CircuitCo and others privately. This puts into question your interpretation of their response as a “lack of response”. I expect that they responded to the more serious seeming comments about “lack of support” and completely overlooked the “provide notice for future customers” part. Or that they stopped responding when you appeared to not accept their response and became repetitive.

I’m not trying to insult you and I apologize if it comes across that way. I’m trying to explain why some of your assumptions are incorrect - why many of your comments appear inflammatory - and how to go about things in a more productive manner.

The following phrases:
“We are not responsible for…”
“That is not our product…”
“Developers are expected to fix incompatible code…”
“We do not produce software…”

These are all, in my opinion, infuriating statements frequently made when discussing bugs. They appear to be shifting responsibility. In truth though they are stock phrases with a dual purpose:

  1. When an employee of a company is trying to help you and going into detail about potential fixes. This opens them up to liability because “he said it would work if I did…”. So they often pepper their comments with these disclaimers to remind you that what they are doing is a FAVOR to you, not something they or their company is required to do.

  2. When the comments they are responding to come across as extremely inflammatory - these stock phrases are a more professional way of saying “your acting like a complete jerk and upsetting my mental well-being”.

So you have to learn to not take those comments personally and note that they have been made and try to modify your phrasing to appear less confrontational.