Firmware 4.1.0 Coordinate Test Program

[Coder_TimT]

I've attached a link to a small coordinate test program with my "fixes" for Firmware 4.0.2+. It seems to work somewhat acceptably on my F200 which originally had 4.0.0, upgraded with the latest firmware release. So I was really needing someone with the newer F200 revision to test it out and see if it behaves the same way. Also included is a version for firmware 4.0.0 that does not include the "fix", if someone wants to flash to 4.1.0 and back to 4.0.0 and compare the two...

Test program.

 

[Manjuu]

There is an error in the link address.

Unfortunately, I'm not brave enough to touch the firmware in my F-200. Sorry, I can't be of any help.

EDIT: I tried it out just to see how it works. The one for FW 4.0.0 work fine here.

 

[EvilDragon]

Gonna try them tonight

 

[Squidge]

Fixed link

 

[Coder_TimT]

There is an error in the link address.

Unfortunately, I'm not brave enough to touch the firmware in my F-200. Sorry, I can't be of any help.

EDIT: I tried it out just to see how it works. The one for FW 4.0.0 work fine here.

Aww, come on Manjuu. I've gone from 4.0.0->4.0.2->4.1.0->4.0.0->4.1.0->4.0.0->4.1.0->new 4.1.0->new 4.0.2->new 4.1.0. It's all good.... Seriously though, I can pretty much test the "old" f200, I just provided that in case someone other than me wanted to compare the accuracy of the "workaround". It would be for some unnecessary firmware flash like this that something would happen to cause a brick...

Fixed link

Thanks Squidge...

 

[sbock]

Hi Coder_TimT!

Nice work. The fix works nice on my F-200. Unfourtunally it's the same model as yours, with 4.0.0 at delivery. Now I'm on 4.1.0 new version and your program works like a charm.

And you're right: I changed my firmware a dozen times on F-100 and F-200 without problems.
But that is a thing everybody has to decide for his own...

Regards,
Stephan

 

[EvilDragon]

Okay, tried on a new F200. As expected, the FW4.0.0-Version messes up.

The test version for higher FWs works fine though, even on the new LCD gp2x

Tried it both with FW 4.0.2 and FW 4.1.0.

Is it possible to include this as a firmware fix somehow or do all touchscreen apps have to be recompiled?

 

[ledow]

Okay, tried on a new F200. As expected, the FW4.0.0-Version messes up.

The test version for higher FWs works fine though, even on the new LCD gp2x

Tried it both with FW 4.0.2 and FW 4.1.0.

Is it possible to include this as a firmware fix somehow or do all touchscreen apps have to be recompiled?

On a similar note, as a developer, is it easy to hardcode these tests (i.e. if FW > 4.0 then do this, else do this) and compensate accordingly? Is it possible to detect the particular hardware that causes this? Is it just an axis change? Would we be able to just load a new kernel module (in the style of the "new" g_ether.o for 2.6 compatibility) which could fix this on affected machines, so that apps don't have to be recompiled at all?

I really hope we're not going to get into waiting weeks for a new SDL/Allegro/tslib and then having to recompile absolutely everything.

 

[Coder_TimT]

I guess, I'll go ahead and post this here also. My workaround looks like this...

CODE
curX = 320 * (240-samp.y) / 240;
curY = 240 * (320-samp.x) / 320;


The coordinates are swapped, but there is more than that going on...

1. You notice I'm putting samp.y into curX and samp.x into curY. That is obviously our coordinate swap.
2. The coordinates for both axises are reversed. The bottom right corner reads as 0,0. Thus the reason for the (240-samp.y) and (320-samp.x).
3. Even though the coordinates are swapped, I don't think they are intended to be. Because once we do the swap the x-axis only has a resolution of 240 and the y-axis has 320. Obviously not actual resolution, but those are the bounds imposed. Thus multiplication of 320 and division by 240 for curX and the opposite for curY...to bring the Y axis within bounds of 240 and to extend the X axis up to 320.

For the version decision logic, I'm using a file in /usr/gp2x called version. It's apparently the file that is read to display the version in the system info screen. Because it reads 4.0.1 for firmware 4.0.2...which is something 4.0.2 users have mentioned seeing. Anyway, I'm just reading it in, stripping off the periods and converting to an int.

I'm away from my development environment for a couple of days, but when I get back, I can start looking into things such as if the touchscreen driver is loaded as a module and if the 4.0.0 driver could be used to replace it... Of course, even if that works, that won't solve the problem for those f200 owners with the new lcd. We'll have to wait for GPH to release their 4.1.0 source so we can "fix" the new driver... Depending on what they've done though, "fixing" the driver might break all internal apps... I guess all we can do it try though...

 

[Orkie]

The touchscreen stuff is compiled into the AC97 driver which is in turn compiled into the kernel (so basically, you can't replace it). The hack would be simple if the 4.1 source code had been released since drivers/sound/mp2520f-ac97.c has a wm97xx_proc_read_reg function and you could simply apply your formula to to data stored in outputbuf[15] before the call to copy_to_user.

 

[Coder_TimT]

The touchscreen stuff is compiled into the AC97 driver which is in turn compiled into the kernel (so basically, you can't replace it). The hack would be simple if the 4.1 source code had been released since drivers/sound/mp2520f-ac97.c has a wm97xx_proc_read_reg function and you could simply apply your formula to to data stored in outputbuf[15] before the call to copy_to_user.

Thanks for that information, Orkie. So it would require the distribution and flashing of a custom kernel...right? Hmm, I wonder what is the lesser of two evils, every developer having to modify their software or having to maintain a custom kernel for each subsequent GPH firmware release(assuming they don't "fix" the problem in a future firmware). Then there is still the issue that if they modified the driver so that it behaves in the current fashion, it seems they would have had to modify the built-in applications to deal with the current behavior....and thus if we "fix" the driver to work with current software, it will break those apps... Lots of unknowns and conjecture there. I guess we have to wait until they release the 4.1 source to answer some of those questions...

 

[Orkie]

Ideally, they'd just fix it, and release the source (if you fix it, I can guarantee GPH will steal the code). But I'm not convinced they'll do either without a lot of bullying. If you make a custom kernel, the easiest solution will be to just revert the menu to a 4.0.0 one.

You can however detect the firmware version by reading /usr/gp2x/version (or /etc/open2x on Open2x), though firmware-specific code is a nasty solution (a particular pain for me).