GP2X Messy F200 Touchpad X-coord, Or Just Me?

[TrevorBradley]

I've been playing around with touchpad drawing on Fenix, though I think this applies to the F200 generally.

I'm seeing some noise on the x co-ordinate. Sometimes I get spikes of plus or minus ten pixels and then a return to a normal noise of +/- 1 or 2 pixels. But the big spikes only seem to be in the left/right x-direction.

I was coding around this, building smoothing functions to watch for this and correct it, then thought I should check if this were true of all F200's or just mine. Does anyone else see their mouse.x co-ordinate jump where it shouldn't, while mouse.y behaves pretty well?

Thanks in advance!

 

[ruckage]

I've noticed it as well, mine jumps occasionally on the x axis. Quiest also mentioned it though I think his was affected on both the x and y axis.

 

[Hooka]

Is this just a fenix-related thing, or just the touchscreen driver in general?

*Note to self: really gotta get the virtual keyboard in freesci using the touchscreen... atleast I'm half way there, got touchscreen working in general

 

[paeryn]

The touchscreen reports lots of inaccuracies. One of the biggest causes of touchscreen interference is from "noise" coming from the LCD, and it wouldn't surprise me if GPH hadn't bothered to fine-tune either the hardware or software to account for it.

I don't know how Fenix accesses the touchscreen (directly / SDL / other) but in the most recent version of my HW-SDL I implemented a version of TSLIB to smooth out most of the errors but I think I'd only got it down to the region of ~10 pixel spikes every now and then.

 

[TrevorBradley]

The touchscreen reports lots of inaccuracies. One of the biggest causes of touchscreen interference is from "noise" coming from the LCD, and it wouldn't surprise me if GPH hadn't bothered to fine-tune either the hardware or software to account for it.

I don't know how Fenix accesses the touchscreen (directly / SDL / other) but in the most recent version of my HW-SDL I implemented a version of TSLIB to smooth out most of the errors but I think I'd only got it down to the region of ~10 pixel spikes every now and then.

OK, I'll try to release my program by the end of this week, and let the 'net judge if my algorithm is better or worse than anyone elses.

 

[GernotFrisch]

I have the very same problems. It's totally annoying. I'm using about 5 passes to round out the error, but still have about 5 pixels.
The main problem is when you first dip on the screen.
Maybe leaving/ignoring the first dip as a "warmup" might help?

 

[Jessicatz]

Here is some cheap interpolating for you:

CODE
// Returns 1 when pressed, 0 otherwise, fills given integers with
// the coords of the touch (fills with -1 if not touched). px and py
// should be the coords received from the last call of this function.
bool getTouch(int& px, int& py) {
if (pressed()) {
px = (px == -1 ? x : ((px * 6 + x)) / 7); // x = touched x
py = (py == -1 ? y : ((py + y)) / 2); // y = touched y
return true;
} else {
px = -1;
py = -1;
return false;
}
}

 

[GernotFrisch]

I do this 8 times now. Overclocked to 240MHz - maybe that's the problem? I get x coordinate about 4 pixels noise now.
y seems quite stable.