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?
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.
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
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...
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
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?
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
Should read
“but does not support the Hardware Graphics like the TI one”
above.
I figured. I’ll give that a shot. Be nice to have an App Store on that TI image.
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.
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 !
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…
thx for the answer, but actually i sent the mail by error 
.
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 … .
Oh well, worth a shot!
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 =>
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 and the z 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 :
[ 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 
Enjoy the BBB, enjoy the lcd ^^
touchscreen_jitter_fix.patch (3.37 KB)
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.
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
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 …
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
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