Fixed 4.1.0 Firmware Available At Gamepark Site

[Flynn_fr]

I tested the 4.1.0 fw and there are some problem with touch and audio volume.
In the pocket snes and gpfce I have niticed that audio volume is too low.
I tested also the new touch calculator fcalc and don't work.

Someone can test those programs with 4.1.0 firmware? :huh:

Thank you!

There will be a release of Fcalc for firmware 4.1.0 soon.
4.1.0 really fixes correctly the touchpad, making SDL seeing it as a mouse.
It breaks old software because old software used tricks to get the touchpad information and it collides with SDL beahviour in 4.1.0.
Beside, you need an up-to-date SDL library, and the best is to link against the dynamic lib in the firmware itself, (which could be tricky)

So, IMO, the best firmware regarding the touchpad topic is 4.1.0, but most of the applications will fail and have to be patched to behave correctly, but that's the price to pay.

Flynn

 

[notaz]

It breaks old software because old software used tricks to get the touchpad information and it collides with SDL beahviour in 4.1.0.

Tricks? 4.0.0 returned data (through /dev/touchscreen/wm97xx) which made sense at least, X range was ~0-320, Y ~0-240 (after applying pointercal), and pressure was 0 when pen was up, and > 0 when down.

>= 4.0.2 returns ~240-0 for X (values decreasing left to right), ~320-0 for Y, and pressure returns some X related value, not pen status. Not to mention that kernel mode thread they have added, which is polling the touchscreen non-stop regardless of any app using it or not.
Does that look correct to you?

Yeah, they might have hacked their version of SDL to cope with this, but who should care about that, when everyone is doing static linking to avoid compatibility problems? Also, not everyone in this world is using SDL, you know.

 

[Flynn_fr]

Tricks? 4.0.0 returned data (through /dev/touchscreen/wm97xx) which made sense at least, X range was ~0-320, Y ~0-240 (after applying pointercal), and pressure was 0 when pen was up, and > 0 when down.

>= 4.0.2 returns ~240-0 for X (values decreasing left to right), ~320-0 for Y, and pressure returns some X related value, not pen status. Not to mention that kernel mode thread they have added, which is polling the touchscreen non-stop regardless of any app using it or not.
Does that look correct to you?

Yeah, they might have hacked their version of SDL to cope with this, but who should care about that, when everyone is doing static linking to avoid compatibility problems? Also, not everyone in this world is using SDL, you know.

You have a point.

I've made a small app that dumps the output of wm9xx.
The structure it's supposed to return is 16-bytes long.
Under 4.1.0, it returns randomly only the beginning of the structure, i.e. 4 or 8 or 12 bytes, and sometimes 16 bytes, which I interpreted as some other process was reading the device at the same time. As a consequence, it gets difficult to interpret the returned data, since the returned structure is not complete, (but it always starts correctly curiously), and overlaps probably the previous structure read during the previous iteration.

So wm9xx is unusable, but the mouse events I get are correct., maybe for a bad reason if you're right and if the reason is a dirty SDL hack.

So I guess one should look into the 4.1.0 sources ;-) Are they available yet ?

Flynn

 

[notaz]

Strange, I'm getting consistent results (described in my prev post), by simply reading this structure:
CODE

typedef struct
{
unsigned short pressure;
unsigned short x;
unsigned short y;
} ts_event;


There is no source code yet, they usually upload it to http://svn.gp2x.com/gp2x/tag/ .

 

[Flynn_fr]

Strange, I'm getting consistent results (described in my prev post), by simply reading this structure:
CODE

typedef struct
{
unsigned short pressure;
unsigned short x;
unsigned short y;
} ts_event;

There is no source code yet, they usually upload it to http://svn.gp2x.com/gp2x/tag/ .


Hum, maybe it does this only when SDL lib is initialized !? (i.e. the culprit steali,g bytes is the SDL lib itself ?)
BTW I was reading a ts_event slightly different, thus reading more bytes than you do.
typedef struct {
uint16_t pressure;
uint16_t x;
uint16_t y;
uint16_t pad;
struct timeval stamp;
} TS_EVENT;

Flynn