Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes

[Anguel]

Hi!

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:
http://www.youtube.com/watch?v=vEfnwL-Jxgw   @ min 2:00

Any idea how the problem can be solved?

Thanks in advance,
Anguel

[Anguel]

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?

Anguel

[Anguel]

... 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...

[Anguel]

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 :(

[terrys...@gmail.com]

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?

Thanks

Terry

[Anguel]

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.

Regards,
Anguel

[Gerald Coley]

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.

Gerald

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[terrys...@gmail.com]

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. Beaglebone.org and beagleboardtoys.org 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

Regards

Terry

[Gerald Coley]

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.

Gerald

--

[terrys...@gmail.com]

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.

Terry

[Anguel]

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

[Anguel]

Gerald,

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 Beagleboard.org? 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 beagleboard.org, 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.

Regards,

Anguel

[Gerald Coley]

That is what I was told by Circuitco. 

Gerald

[Anguel]

Gerald,

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.

Anguel

[Gerald Coley]

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

cl...@circuitco.com

Gerald

[garyamort]

On Tuesday, September 24, 2013 5:33:36 AM UTC-4, Anguel wrote:

 

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.

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:

"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION."

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.

[David Anders]

Anguel,

circuitco responds to ALL emails sent to sup...@beagleboardtoys.com and sup...@boardzoo.com 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? (https://estore.ti.com/TMDXEVM3358-AM335x-Evaluation-Module-P2714.aspx). it retails for $995USD.....

thanks
Dave Anders
Circuitco

[Anguel]

Gary,

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.

Regards,
Anguel

[Anguel]

David,

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 http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit for $199 only.

Regards,
Anguel

[garyamort]

On Friday, September 27, 2013 4:47:44 AM UTC-4, Anguel wrote:

Gary,

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:

http://www.sainsmart.com/arduino-compatibles-1/lcd-module/sainsmart-3-2-tft-lcd-display-touch-panel-pcb-adapter-sd-slot-for-arduino-2560.html  

It costs 16$.  If you go to ebay you can find similiar products for 12$.

Compare this to CircuitCo's 3" board:

http://www.mouser.com/ProductDetail/CircuitCo/BB-BONE-LCD3-01/?qs=2TuNuDMZFZ5UQcnBUi0fGw%3D%3D&gclid=CIy6vY7n67kCFUWd4AodLxkAqg

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.

[omarbea...@gmail.com]

I am using the android 4.2.2 with the 3.2 kernel, downloaded from the TI website. I can't get anything on my 4DCAPE-43T. It won't even power up. I already booted into Angstrom and the screen does boot up and work so it can't be the screen. Anyway you can provide me with the link for your download? Maybe yours had teh 3.8 kernel?

[Terry Storm]

Have you checked out the Datasheet from 4D?

It states in there that both of the EEPROM ID Jumpers have to be connected for Android for it to work.

Give that a try.

[Terry Storm]

Has there been any progress made by anyone about this touch screen jitter/jumping issue with the LCD Capes?

I now have a 4DCAPE-43T, 4DCAPE-70T, LCD4 and LCD7 and they all exhibit the exact same behaviour, even using the latest version of Angstrom listed on this site.

When loaded with the TI Android 4.2.2 Image, touch works perfectly. Can launch draw programs and there are no issues at all, everything runs smoothly. All the menus can be accessed without issue, so there really is an issue with the released versions of Angstrom and the drivers they use.

Are there any capable people out there working on this?

Thanks

[Anguel]

I have given up with all LCD capes, there are driver bugs in the 3.8 kernel as stated before (see my previous postings). Afaik Android uses the old 3.2 kernel an therefore works ok.
Also, I have the impression that Angstrom development for the BBB is completely abandoned now.
Just hope that the Buildroot people will soon have full support for the BBB...

[Terry Storm]

Hmm,

There are 2 Android builds that I know of, one from TI which is the 3.2 Kernel which does work fine http://downloads.ti.com/sitara_android/esd/TI_Android_DevKit/TI_Android_JB_4_2_2_DevKit_4_1_1/index_FDS.html, and then this one which uses 3.8 which also works fine http://icculus.org/~hendersa/android/

Both work correctly for touch...

I didn't realise Angstrom was abandoned, that is not good.

So what is the new most supported distribution for the BBB and LCD capes?

The touch problem is incredibly frustrating.

Thanks for the info

[Ian Kidd]

Hi, Terry.  I see you got the touchscreen working in Android.  I'm using the Anderson image, and while I can get swipe scrolling to work, it doesn't seem to be calibrated for the point of touch.  Any particular utility that you use to calibrate the touch on Android.

Also, what was the screen rotation utility you mentioned?

[Terry Storm]

Hi Ian

Did you try the TI image instead of the Anderson image?

The TI one seems to be more stable and the buttons are actually mapped to suit Android, which isn't the case on the Anderson image. Anderson Image is Kernel 3.8 however, but also does support the Hardware Graphics like the TI one, so the TI one is quite a bit faster too.

I haven't had to calibrate, both just worked for me.

Screen rotation utility was just from the App Store, just some free rotation app. Cant remember what it was called off the top of my head.

Try and TI image and report back.

Terry

[Terry Storm]

Should read

"but does not support the Hardware Graphics like the TI one"

above.

[Ian Kidd]

I figured.  I'll give that a shot.  Be nice to have an App Store on that TI image.

[Terry Storm]

Lots of alternatives you can download

Aptoide is one for example

Only have to get the apk for that and then download using aptoide like any other App Store.

--

For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/SXTaSUf4aSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Micka]

OK,

Maybe it's time we work together and try to fix this bug. A beaglebone black that doesn't support correctly the touchscreen, it's a SHAME !

So I'm going to try to fix it by myself =>

I prefer to put my conclusion here, because I don't hink everyone has the time to read my research :

1) Presentation of the BUG

• When you touch the screen repeatedly ( up and down up and down ) the bug seems to happen ! ( rarely, but it does )
  
• When you touch the screen continuously, you can see that sometime the mouse go far away from your finger .

2) The driver

The name of the driver is TI - TSC ADC (Touschscreen and analog digital converter)

It's easy to find the source of this driver => drivers/input/touchscreen/ti_am335x_tsc.c

3) The  Interesting part

The interesting part of this driver, is this function :

static void titsc_read_coordinates(struct titsc *ts_dev,

                u32 *x, u32 *y, u32 *z1, u32 *z2)

{

        unsigned int fifocount = titsc_readl(ts_dev, REG_FIFO0CNT);

        unsigned int prev_val_x = ~0, prev_val_y = ~0;

        unsigned int prev_diff_x = ~0, prev_diff_y = ~0;

        unsigned int read, diff;

        unsigned int i, channel;

        unsigned int creads = ts_dev->coordinate_readouts;

        *z1 = *z2 = 0;

        if (fifocount % (creads * 2 + 2))

                fifocount -= fifocount % (creads * 2 + 2);

        /*

         * 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.

         */

        for (i = 0; i < fifocount; i++) {

                read = titsc_readl(ts_dev, REG_FIFO0);

                channel = (read & 0xf0000) >> 16;

                read &= 0xfff;

                if (channel < creads) {

                        diff = abs(read - prev_val_x);

                        if (diff < prev_diff_x) {

                                prev_diff_x = diff;

                                *x = read;

                        }

                        prev_val_x = read;

                } else if (channel < creads * 2) {

                        diff = abs(read - prev_val_y);

                        if (diff < prev_diff_y) {

                                prev_diff_y = diff;

                                *y = read;

                        }

                        prev_val_y = read;

                } else if (channel < creads * 2 + 1) {

                        *z1 = read;

                } else if (channel < creads * 2 + 2) {

                        *z2 = read;

                }

        }

}

So did you watch this code ? Well, In my case, I understand why there is this huge bug !

We have to admit, that sometime there is noise during the transfer of the coordinate between the LCD and the driver.

So, this code is supposed to filter any of noise with this :

                       

                        diff = abs(read - prev_val_x);

                        if (diff < prev_diff_x) {

                                prev_diff_x = diff;

                                *x = read;

                        }

                        prev_val_x = read;

Well, I'm sorry, but if the noise happen, you should not save the noise value has the last position (correct me if I'm wrong ?) .....

So, I changed the code with something like that :

             if (channel < creads) {

                        printk("raw x=%d\n", read);

                        diff = abs(read - prev_val_x);

                        if (diff < prev_diff_x) {

                                printk("x=%d & diff=%d\n", read, diff);

                                prev_diff_x = diff;

                                *x = read;

                                prev_val_x = read;

                        }

                } else if (channel < creads * 2) {

                        printk("raw y=%d\n", read);

                        diff = abs(read - prev_val_y);

                        if (diff < prev_diff_y) {

                                printk("y=%d & diff=%d\n", read, diff);

                                prev_diff_y = diff;

                                *y = read;

                                prev_val_y = read;

                        }

                } else if (channel < creads * 2 + 1) {

                        *z1 = read;

                } else if (channel < creads * 2 + 2) {

                        *z2 = read;

                }

Also, it's important to note that this function is called by the function irqreturn_t titsc_irq:

I put a printk to be noticed when the function is called :

static irqreturn_t titsc_irq(int irq, void *dev)

{

        struct titsc *ts_dev = dev;

        struct input_dev *input_dev = ts_dev->input;

        unsigned int status, irqclr = 0;

        unsigned int x = 0, y = 0;

        unsigned int z1, z2, z;

        unsigned int fsm;

        status = titsc_readl(ts_dev, REG_IRQSTATUS);

        /*

         * ADC and touchscreen share the IRQ line.

         * FIFO1 threshold, FIFO1 Overrun and FIFO1 underflow

         * interrupts are used by ADC,

         * hence return from touchscreen IRQ handler if FIFO1

         * related interrupts occurred.

         */

        if ((status & IRQENB_FIFO1THRES) ||

                        (status & IRQENB_FIFO1OVRRUN) ||

                        (status & IRQENB_FIFO1UNDRFLW))

                return IRQ_NONE;

        else if (status & IRQENB_FIFO0THRES) {

                printk("start\n");

                titsc_read_coordinates(ts_dev, &x, &y, &z1, &z2);

Now, it' time to test it ! I've a LCD7, and max x =  800, max y=480:

[  198.656774] start

[  198.656831] raw x=646

[  198.656854] diff 647

[  198.656876] x=646

[  198.656897] raw x=686

[  198.656918] diff 40

[  198.656937] x=686

[  198.656958] raw x=686

[  198.656979] diff 0

[  198.656998] x=686

[  198.657018] raw x=686

[  198.657038] diff 0

[  198.657058] raw x=686

[  198.657078] diff 0

[  198.657099] raw y=2891

[  198.657119] diff 2892

[  198.657139] y=2891

[  198.657160] raw y=2890

[  198.657180] diff 1

[  198.657200] y=2890

[  198.657221] raw y=2889

[  198.657241] diff 1

[  198.657262] raw y=2888

[  198.657281] diff 2

[  198.657302] raw y=2885

[  198.657322] diff 5

[  198.659221] start

[  198.659250] raw x=685

[  198.659270] diff 686

[  198.659290] x=685

[  198.659310] raw x=686

[  198.659330] diff 1

[  198.659350] x=686

[  198.659370] raw x=685

[  198.659390] diff 1

[  198.659410] raw x=683

[  198.659430] diff 3

[  198.659450] raw x=680

[  198.659470] diff 6

[  198.659490] raw y=2879

[  198.659510] diff 2880

[  198.659530] y=2879

[  198.659550] raw y=2878

[  198.659570] diff 1

[  198.659590] y=2878

[  198.659611] raw y=2879

[  198.659630] diff 1

[  198.659651] raw y=2879

[  198.659670] diff 1

[  198.659691] raw y=2873

[  198.659711] diff 5

+ other data

My first question, is WHY the Y VALUE is that high ?  maybe because y is not in pixel ?

Also we can see that the function  titsc_read_coordinates is called multiple times.........

And just now, I discover something ! There is a mistake between the role of the  two function :

The function  irqreturn_t titsc_irq call the function titsc_read_coordinates. to calculate the position of x, y, and z . After that the function  irqreturn_t titsc_irq report to the upper level the position and the pressure level with this:

 titsc_read_coordinates(ts_dev, &x, &y, &z1, &z2);

              if (ts_dev->pen_down && z1 != 0 && z2 != 0) {

                        /*

                         * Calculate pressure using formula

                         * Resistance(touch) = x plate resistance *

                         * x postion/4096 * ((z2 / z1) - 1)

                         */

                        z = z1 - z2;

                        z *= x;

                        z *= ts_dev->x_plate_resistance;

                        z /= z2;

                        z = (z + 2047) >> 12;

                        if (z <= MAX_12BIT) {

                                input_report_abs(input_dev, ABS_X, x);

                                input_report_abs(input_dev, ABS_Y, y);

                                input_report_abs(input_dev, ABS_PRESSURE, z);

                                input_report_key(input_dev, BTN_TOUCH, 1);

                                input_sync(input_dev);

                        }

                }

So, If I'm not wrong ( correct me if it is ), The function titsc_read_coordinates should calculate just one x value and one y value. Most of the times, the function works because it give the last position (depending of some condition ...) of the FIFO ....

So why not calculate the average value of x and y ? If I do that, I will be able to eliminate better, the noise .... but in counter part I will increase the time of response .....

I tried that, but I don't see any difference, but for me, it's better like that, I feel that it's the correct thing to do !

So, I have still this horrible bug ! And I don't know why !!!! So I started again some test, but this time, I want to see the value of the pressure !  =>

.....

[   69.777100] start

[   69.777140] x=2982

[   69.777161] y=1223

[   69.777185] Z1 1612 Z2 3472 z=224 

[   69.779156] start

[   69.779201] x=2983

[   69.779222] y=1222

[   69.779245] Z1 1600 Z2 3474 z=223

[   69.781230] start

[   69.781271] x=2983

[   69.781292] y=1225

[   69.781316] Z1 1581 Z2 3486 z=221

[   69.783301] start

[   69.783344] x=2984

[   69.783365] y=1226

[   69.783389] Z1 1565 Z2 3488 z=220

[   69.785372] start

[   69.785413] x=2983

[   69.785433] y=1226

[   69.785458] Z1 1555 Z2 3493 z=219

[   69.787437] start

[   69.787479] x=2984

[   69.787499] y=1226

[   69.787522] Z1 1540 Z2 3500 z=218

[   69.789502] start

[   69.789543] x=2983

[   69.789564] y=1229

[   69.789587] Z1 1467 Z2 3532 z=212

[   69.791562] start

[   69.791602] x=2986

[   69.791623] y=1231

[   69.791646] Z1 1172 Z2 3678 z=186

[   69.793621] start

[  69.793663]x=1807

[   69.793683] y=2596

[   69.793707] Z1 1 Z2 4091 z=168

AND NOW, it's starting to be VERY VERY interesting ! It looks like that when you remove your finger, some times ( electrical problems ? ) we got noise ! And THAT make the BIG bug !

I love linux and printk ^^

So, it's time to fix it, how ? by detecting the drop of z !!!! We just need to ignore the x and y calculated if Z drop too much ! =>

It work sometime .. but not all of the time ==>

[  184.476665] start

[  184.476705] x=2889

[  184.476726] y=1300

[  184.476748] deltaZ=-7 z=207

[  184.478722] start

[  184.478764] x=2889

[  184.478784] y=1293

[  184.478806] deltaZ=-22 z=185

[  184.478827] z ignored, deltaZ=-22

[  184.480720] start

[  184.480760] x=2890

[  184.480781] y=1289

[  184.480803] deltaZ=-20 z=165

[  184.480824] z ignored, deltaZ=-20

[  184.482714] start

[  184.482753] x=719

[  184.482774] y=3591

[  184.482796] deltaZ=56 z=221

So, it looks like that it's not that perfect, not yet !

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Mike Bremford]

I don't have one of these, but I'll weigh in anyway :-) I looks like your loop (i=0..fifocount) is going through at least 10 times and giving you 5 x and Y values, but then just storing the last one, right? So that's where you're averaging instead, correct?

In that case just a thought, but if you're getting "spikes" of bad values, then perhaps discard the lowest and highest of the 5 samples before averaging? eg. store in an array (say xval[0..4] and yval[0..4]) then something like:

uint8_t numcoords = 5; // or however many you got.

uint8_t minxindex = 0, minyindex = 0, maxxindex = 0, maxyindex = 0;

for (i=1;i<numcoords;i++) {

    if (xval[i] < xval[minxindex]) {

        minxindex = i;

    }

    // same for miny/maxx/maxy

}

uint32_t avgx = 0, avgy = 0;

for (int i=0;i<numcoords;i++) {

    if (i != minxindex && i != maxxindex) {

        avgx += xval[i];

    }

    if (i != minyindex && i != maxyindex) {

        avgy += yval[i];

    }

}

*x = avgx / (numcoords-2);

*y = avgy / (numcoords-2);

This will remove the spikes, rather than just reducing their impact....

As for the Z pressure stuff, makes sense as well - the first bad Y value you listed has Z1=1 Z2=4096, while all the others are in the range Z1=~1500, Z2=~3500. Maybe it's not deltaZ you should be checking but that Z1 and Z2 are within an acceptable range? Just an idea, but if checking delta-Z isn't working...

[Micka]

thx for the answer, but actually i sent the mail by error :p .

I agree with you, that the loop give 5 times x and y ( or less ), but it's always around the same average ..... (_( So when the spikes happen, it's for every value of x and y in the fifo ...... .

[Mike Bremford]

Oh well, worth a shot!

[Micka]

OK,

Maybe it's time we work together and try to fix this bug. A beaglebone black that doesn't support correctly the touchscreen, it's a SHAME !

So I'm going to try to fix it by myself =>

I prefer to put my conclusion here, because I don't think everyone has the time to read my research :

4) CONCLUSION:

I fixed the bug, but the original source of this bug is hardware for me . 

The solution to fix this problem is to put a better filter ! Enjoy ;)

My research =>

So, If I'm not wrong ( correct me if it is ), The function titsc_read_coordinates should calculate just one x value and one y value and the z value. Most of the times, the function works because it give the last position (depending of some condition ...) of the FIFO ....

It work sometime :

[   71.146681] deltaZ=0 z=249

[   71.148661] start

[   71.148705] x=856

[   71.148726] y=3114

[   71.148749] deltaZ=-1 z=248

[   71.150734] start

[   71.150775] x=852

[   71.150796] y=3109

[   71.150818] deltaZ=-3 z=245

[   71.152802] start

[   71.152844] x=851

[   71.152865] y=3113

[   71.152888] deltaZ=-3 z=242

[   71.154876] start

[   71.154916] x=851

[   71.154937] y=3114

[   71.154960] deltaZ=-7 z=235

[   71.156976] start

[   71.157017] x=851

[   71.157038] y=3116

[   71.157060] deltaZ=-7 z=228

[   71.159024] start

[   71.159059] x=855

[   71.159080] y=3558

[   71.159102] deltaZ=-14 z=214

[   71.159123] z ignored, deltaZ=-14

but not all of the time ==>

[  184.476665] start

[  184.476705] x=2889

[  184.476726] y=1300

[  184.476748] deltaZ=-7 z=207

[  184.478722] start

[  184.478764] x=2889

[  184.478784] y=1293

[  184.478806] deltaZ=-22 z=185

[  184.478827] z ignored, deltaZ=-22

[  184.480720] start

[  184.480760] x=2890

[  184.480781] y=1289

[  184.480803] deltaZ=-20 z=165

[  184.480824] z ignored, deltaZ=-20

[  184.482714] start

[  184.482753] x=719

[  184.482774] y=3591

[  184.482796] deltaZ=56 z=221

So, it looks like that it's not that perfect, not yet !

So let's ignore z when it's increasing too much !

It works, but again ! not all the time :

[  141.325412] start

[  141.325453] x=2896

[  141.325473] y=1955

[  141.325496] deltaZ=-51 z=132

[  141.325517] z ignored, deltaZ=-51

[  141.327402] start

[  141.327438] x=2583

[  141.327458] y=1799

[  141.327480] deltaZ=-2 z=130

Well, this time, let's try to ignore when z is <0 ........ =>

yes, but I have sometime that : 

[  107.594674] x 2820 y 2125 deltaZ -4

[  107.596580] x 2820 y 2126 deltaZ -16

[  107.598481] x 2809 y 2128 deltaZ -34

[  107.600381] x 562 y 3806 deltaZ 67

Okay .... let's filter with deltaZ>=0 & deltaZ<= 10 !!!!!!!! ==>

YES ! YES ^^ It works ALL the time for me ! At least 99% :)

You will find the patch attached :p Enjoy the BBB, enjoy the lcd ^^

[Ian Kidd]

I'm going to be the helpless little girl here and ask for a quick synopsis of how to apply the patch?  I'm not sure where the file is that gets this Diff, because I can't locate it in /lib/modules.

[Terry Storm]

Ditto.

Regarding the fix which makes this work 99% of the time...

Have you considered the noise could be on the power lines which power the touch screen?

One could assume the power rails are meant to be between GND and VCC, however this may not be the case. It then assumes GND is 0 and VCC is Max. Since there are 4 AIN's used, it should be possible to read the voltages... Maybe do some sort of ratio calculation or something.

Just a thought.

Terry

[Micka]

Lan Kidd, For the patch, I'm sure that Robert Nelson will include it on the next release of the kernel, same for Koen !

Terry Storm, well not really :) , the noise come when you remove your finger, always at this time .... when the pressure is not enough we got some crazy x and y value ..........

--

[Will Kostelecky]

I have the same problem with the LCD7 on Archlinux and would really like to get it fixed.   I can't find the above file on my installation and am not sure where to look.   Or for that matter what to do with the patched file if I were able to find it.   Can someone help with a) telling me where to look for the right file to patch, and b) tell me how to build a patched driver?   I am not a complete neophyte with Linux (I frequently build apps from source and can debug build problems)  but I dont know where to start with drivers!

Thanks,
Will

[Micka]

I would love to create a patch for you, but i don't know how .... I tried to commit the result, but I got :

beaglekernel@beaglekernel-VirtualBox:~/linux-dev/KERNEL$ git commit

# On branch v3.8.13-bone35

# Changes not staged for commit:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified:   drivers/input/touchscreen/ti_am335x_tsc.c

#

no changes added to commit (use "git add" and/or "git commit -a")

beaglekernel@beaglekernel-VirtualBox:~/linux-dev/KERNEL$ git commit drivers/input/touchscreen/ti_am335x_tsc.c

error: insufficient permission for adding an object to repository database .git/objects

error: drivers/input/touchscreen/ti_am335x_tsc.c: failed to insert into database

error: unable to index file drivers/input/touchscreen/ti_am335x_tsc.c

fatal: updating files failed

[André Prado]

Micka thank you so much for your work!

We can compile this driver with Linaro and load it dynamically right? Using mobprobe

Or am i mistaken?

Cheers

Att
André

[Micka]

I don't think so ( I'm not an expert on that ) But It's "easy" with the Kernel from Robert Nelson to build, modify the kernel, rebuild the kernel, install the kernel in your sdcard .... It's what i've done ... .

I hope that Robert Nelson will include this modification for the next release of the Kernel .....

[André Prado]

Micka could you please give me the way? I need to get https://github.com/beagleboard linux repo and compile with Linaro? Is that all?

[Will Kostelecky]

Micka:

I second the huge thanks from Andre for the work you have done on this to date...would also support Andre's question about the way!   If you could give us some pointers on what we need to do, or point us to a reference on the web, it would be greatly appreciated (even more greatly than hugely)!

Cheers,
Will

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/SXTaSUf4aSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Micka]

http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel

git clone git://github.com/RobertCNelson/linux-dev.git

cd linux-dev/

git checkout origin/am33x-v3.8 -b tmp


./build_kernel.sh





go to the file KERNEL/drivers/input/touchscreen/ti_am335x_tsc.c

edit the file by following the file that I previously sent . 

save the file, go to the folder linux-dev, and rebuild the kernel :

./tools/rebuild something .sh

micka,

[André Prado]

Thank you so much, i will do it when i get home :)

[Will Kostelecky]

Micka:

I have gotten to the point of rebuilding the kernel and have what may be a dumb question before I press enter...

In tools I have a rebuild.sh and a rebuild_deb.sh.   Form your message I am guessing that I run the latter?

Thanks,

Will

[Micka]

I never used rebuild_deb.sh ..... I don't know what it is for .....

[longdirt...@gmail.com]

Hello Will,

I am experiencing the same problems !!

I am compiling a new kernel for ArchLinux with the proposed jitter-patch ... the lecacy-one (3.8.13) ... I will let you know if I am successfull !!

Greetings, Alfred.

Op zondag 12 januari 2014 13:35:38 UTC+1 schreef Will Kostelecky:

[Will Kostelecky]

Everything went well up to the point of actually installing the patched and rebuilt kernel!   I run from an SD card so had to point the install script to it.   It installed ok on the first partition but blew up on the second.   I have not had a chance to dig into why yet.   I am thinking of trying the upgrade on the internal drive and see if that, being what is expected by default, works better?

[Micka]

Well,

First, thx to Robert Nelson, the patch for the touchscreen fix has been implemented  :

https://github.com/RobertCNelson/linux-dev/commit/20c9c32e3443826d79ea01e17cbd2d6fa2c616ae

Which means, that now, you don't need to implement it yourself :p , you just need to build the kernel and install it in your sdcard.

Which means that soon, the fix will be implemented to each release of ubuntu/debian from Robert Nelson !

Also Will Kostelecky, the script to install the kernel, only work for a Robert Nelson image ( ubuntu/debian ) .

Micka,

[Will Kostelecky]

:-(

[Micka]

What ? You have an angstrom image ? You should change .... Angstrom it's over .... go to the Ubuntu/Debian image !

[Will Kostelecky]

Arch.   Much faster than Debian for my application.   I must admit messing with the kernel might be above my level of competency.  I am but an app developer!

[longdirt...@gmail.com]

Hello Will,

The proposed patch did not work on Arch  Linux !

However, I made a new (working) one.

Could you please test it for me.

Becaue this is a build-in module, I have compiled a new (legacy) kernel.

https://drive.google.com/file/d/0B0llA47E0GJwZjRhRGk1N2JvUDg/edit?usp=sharing

Install it with pacman -U filename.

I hope to hear from you soon.

Greetings, Alfred.

[Will Kostelecky]

Alfred:

I will try this ASAP but first need to ask a dumb question.   What should the filename be!   I have unpacked the compressed file and now have the directories usr/lib/modules/extramodules-3.8--am33x-legacy and usr/lib/modules/3.8.13-16-ARCH...

Thanks, Will

[longdirt...@gmail.com]

Do not unpack !!!

It is an install-file.

Everything will be done for you, if you use it together with pacman

So:

pacman -U ./filenameofthefileyoudownload

Off you go !!!

Op vrijdag 24 januari 2014 16:45:10 UTC+1 schreef Will Kostelecky:

[Will Kostelecky]

longdirtyanimalf:

WORKS ABSOLUTELY G_R_E_A_T!   and easy to apply.   I was in the middle of trying to learn how to build a new kernel and do not need to invest that time so am tickled pink!

Will

[Terry Storm]

Great news

Can someone please link me to the latest Debian/Ubuntu image which features this fix? Is there is pre-made image available, or do I need to build it?

Ditto for Arch Linux, would love to try that one out too with the fix for that.

Regards

Terry

[Will Kostelecky]

Can't speak to the Debian question but the patch for Arch needs to be applied against a normally built image.

Will

[Micka]

You should ask Robert Nelson about that.

Micka,

[Robert Nelson]

On Mon, Jan 27, 2014 at 4:36 AM, Terry Storm <terrys...@gmail.com> wrote:
> Great news
>
> Can someone please link me to the latest Debian/Ubuntu image which features
> this fix? Is there is pre-made image available, or do I need to build it?
> Ditto for Arch Linux, would love to try that one out too with the fix for
> that.

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

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Terry Storm]

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

[Micka]

Well, It's good that it works in other device :)

Micka,

--

[Will Kostelecky]

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

[mich...@o2.pl]

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

[Bas Laarhoven]

Hi Piotr,

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

-- Bas

[Piotr Murawski]

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 Piotr,

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

-- Bas


On 24-2-2014 12:51, mich...@o2.pl wrote:
> 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...

[ro...@krda.ca]

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.

[ro...@krda.ca]

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).

On Tuesday, 28 January 2014 01:05:15 UTC-8, Mickae1 wrote:

Well, It's good that it works in other device :)

Micka,

On Mon, Jan 27, 2014 at 9:32 PM, Terry Storm <terrys...@gmail.com> wrote:

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

On Tuesday, 28 January 2014 02:45:40 UTC+13, RobertCNelson wrote:

On Mon, Jan 27, 2014 at 4:36 AM, Terry Storm <terrys...@gmail.com> wrote:
> Great news
>
> Can someone please link me to the l

...

[Micka]

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

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Roop Singh]

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?

---

From: Micka [mailto:micka...@gmail.com]
To: beagl...@googlegroups.com
Sent: Thu, 13 Mar 2014 00:59:42 -0800
Subject: Re: [beagleboard] Re: Touchscreen Jitter / Jumping on Beaglebone Black LCD Capes

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/SXTaSUf4aSk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Micka]

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,

[Roop Singh]

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 :(

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?

---

From: Micka [mailto:micka...@gmail.com]
To: beagl...@googlegroups.com

Cc: Robert Nelson [mailto:robert...@gmail.com]
Sent: Thu, 13 Mar 2014 11:08:23 -0800

[Piotr Murawski]

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.



 

[ro...@krda.ca]

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.

On Friday, 14 March 2014 15:19:28 UTC-7, Piotr Murawski wrote:

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++;

&

...

[ro...@krda.ca]

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 :)

--
For more options, visit <a href="http://beagleboard.org/discuss

...

[Roop Singh]

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.

From: Micka [mailto:micka...@gmail.com]
To: beagl...@googlegroups.com

Cc: Robert Nelson [mailto:robert...@gmail.com]

Sent: Thu, 13 Mar 2014 11:08:23 -0800

[fredd...@gmail.com]

El martes, 3 de septiembre de 2013 06:47:44 UTC-5, Anguel escribió:

Hi!

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:
http://www.youtube.com/watch?v=vEfnwL-Jxgw   @ min 2:00

Any idea how the problem can be solved?

Thanks in advance,
Anguel

El martes, 3 de septiembre de 2013 06:47:44 UTC-5, Anguel escribió:

Hi!

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:
http://www.youtube.com/watch?v=vEfnwL-Jxgw   @ min 2:00

Any idea how the problem can be solved?

Thanks in advance,
Anguel

[Olivier B.]

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

[Micka]

Hi Robert,

What do you think about that ? ( bellow )

Could you change the kernel 3.8 to include this touchscreen driver update ?

Thx,

Micka.

[p3f...@gmail.com]

Hello Terry,
                 I am working on Beaglebone Black interfaced with a custom made LCD.The driver of the touchscreen is XWC959.I am not able to find the drivers for it.Can u help me here...I know the post is a little old but urgent help required.


Regards
Polash

On Monday, December 16, 2013 2:03:25 PM UTC+5:30, Terry Storm wrote:

Hmm,

There are 2 Android builds that I know of, one from TI which is the 3.2 Kernel which does work fine http://downloads.ti.com/sitara_android/esd/TI_Android_DevKit/TI_Android_JB_4_2_2_DevKit_4_1_1/index_FDS.html, and then this one which uses 3.8 which also works fine http://icculus.org/~hendersa/android/

Both work correctly for touch...

I didn't realise Angstrom was abandoned, that is not good.

So what is the new most supported distribution for the BBB and LCD capes?

The touch problem is incredibly frustrating.

Thanks for the info

On Monday, 16 December 2013 19:56:40 UTC+13, Anguel wrote:

I have given up with all LCD capes, there are driver bugs in the 3.8 kernel as stated before (see my previous postings). Afaik Android uses the old 3.2 kernel an therefore works ok.
Also, I have the impression that Angstrom development for the BBB is completely abandoned now.
Just hope that the Buildroot people will soon have full support for the BBB...

[eric.z...@gmail.com]

This forum thread saved my ti touch screen device. Thanks all! My touchscreen was having the exact symptoms mentioned in the first few posts. A drop in 'touch' pressure would cause the x-coordinates to drastically deviate from where I was touching. This made functionality of something, like a UI scroll-bar, useless.

I was using a v3.12 linux kernel, but was still able to modify the ti_am335x_tsc.c from the v3.8 patch that was listed here.

For future users, if you need a patch for the 3.12 kernel, you can find it here.
https://github.com/EricZaluzec/ti_am335x_tsc/blob/master/remove-pressure-jitter.patch

Cheers.
-Ez