GAPI: solution is simple!!!

[Guest The PocketTV Team]

Here is what we found in this device:

First, the way to identify the device: SPI_GETOEMINFO returns "Typhoon"

GAPI GXGetDisplayProperties: cxWidth = 176, cyHeight = 220, cbxPitch = 2, cbyPitch = 352, cBPP = 16, ffFormat = 160 (very normal)

GAPI GXIsDisplayDRAMBuffer() return 1: GAPI uses DRAM buffer!

So clearly this is the root of the problem: for some reason, GAPI tells the application that it uses a DRAM frame buffer, i.e. that the real frame buffer is updated only when GXEndDraw is called.

I'm not sure if GXIsDisplayDRAMBuffer returns the correct information, or if it does, why Orange decided to not give direct access to the raw frame buffer.

Also interesting:

GETVFRAMEPHYSICAL not supported

GETVFRAMELEN not supported

GETRAWFRAMEBUFFER not supported (if this one was supported, there would be no problem at all, naturally!)

PROCESSOR_INFO not available, error 5 (no privilege) ... this is the same on most smartphones due to the stupid security model of MSFT. so there is no way to determine programatically what processor it has (unless your app is signed with a privileged cert), and to enable code optimized specifically for that processor. You'll have to somehow hard-code that in your app (TI OMAP 730 ARM)

More to come!

[Guest The PocketTV Team]

We found the solution, it is quite simple:

If GXIsDisplayDRAMBuffer return 1 on the SPV C500:

1) Assume that GXIsDisplayDRAMBuffer() return 0 (i.e. no DRAM Buffer)

2) Call GXBeginDraw, it returns the real address of the raw frame buffer!

3) Do not call GXEndDraw. If you call it, it will trigger the update from the DRAM buffer, which is not something you want.

4) Do not call GXCloseDisplay: it also triggers an update from the DRAM buffer, which you don't want.

That's it.

The bad part is that apps must be slightly modified to detect this device and implement the workaround. But that's just a few lines of code, and we (Mobile developers) are used to working around platform-specific bugs :)

You can try PocketTV Classic 0.15.1 for Smartphone, it is implemented using the rules above. Free download from www.pockettv.com .

Credits and thanks:

Thierry Tremblay (PocketHAL)

Johan (GapiDraw)

Liam Gladdy and Ted Mount (PocketTV beta-testers)

Enjoy!

[Guest picard_beta]

thanks for the workaround.

do you think using just the GXINFO extescape code to get the information needed would work? if GXBeginDraw returns the real address then GXINFO should return it too.

[Guest The PocketTV Team]

thanks for the workaround.

do you think using just the GXINFO extescape code to get the information needed would work? if GXBeginDraw returns the real address then GXINFO should return it too.

Yes, GXINFO returns the same address.

[Guest Paul [MVP]]

Does this also solve the problem with screen update stopping if the screen goes to low power mode?

P

Posted from my SmartPhone!

[Guest The PocketTV Team]

"]Does this also solve the problem with screen update stopping if the screen goes to low power mode?

Not sure what the problem is.

But games and all other applications should call SHIdleTimerReset every 9 sec or so to prevent the Shell timeout (which brings the Home screen), and they should probably also call SystemIdleTimerReset to prevent the system to enter the power-saving mode.

I did not know about the problem on the C500, but a similar issue exist on the i600. If an active app doesn't call SystemIdleTimerReset (when it is active e.g. playing video or game), the phone can go to sleep (low power) mode after a timeout.

Currently, on the C500, PocketTV doesn't call SystemIdleTimerReset, so I imagine that it does not prevent the system from going to low-power mode (could someone confirm that by testing with PocketTV 0.15.1 ?).

If this is confirmed, we'll call SystemIdleTimerReset and confirm that it solves this issue.

BTW, for more info on those, see

http://msdn.microsoft.com/library/default....cshell_vigo.asp

and

http://msdn.microsoft.com/library/default....eTimerReset.asp

[Guest The PocketTV Team]

"]Does this also solve the problem with screen update stopping if the screen goes to low power mode?

Paul, can you ellaborate and describe precisely what this problem is ?

I mean, for the people like us who don't have the device...

[Guest Paul [MVP]]

Say if you are playing SPVMan, everything is fine, but when you don't touch the keys for a short period of time and the screen 'dims', then the redraw on the screen stops.

The game continues (you can hear the sound of you being eaten by ghosts, lol), but the screen doesn't generally update until you exit the game (sometimes it seems to stutter update tho!)

P

[Guest cactusbob]

Exactly the same problem with Slurp!! If you keep playing it's OK, but as soon as you pause long enough for the screen to dim (as Paul says), it locks up, or rather it appears to. You can still exit back to the homescreen, so it doesn't lock the phone.

CB

[Guest The PocketTV Team]

> when you don't touch the keys for a short period of time

how long ?

are you sure that all those apps call SystemIdleTimerReset and SHIdleTimerReset as they need to ?

does the same thing happen when you play a video with PocketTV and don't touch the keys ?

[Guest The PocketTV Team]

Exactly the same problem with Slurp!! If you keep playing it's OK, but as soon as you pause long enough for the screen to dim (as Paul says), it locks up, or rather it appears to. You can still exit back to the homescreen, so it doesn't lock the phone.

Apparently on the C500, calling SHIdleTimerReset every 9 sec is sufficient to prevent the screen from dimming.

Normally games and video apps should call SHIdleTimerReset every 9 sec (i.e. less than the minimum timeout of 10 sec) when playing, i.e. not paused or stopped.

when paused or stop, they should *not* call SHIdleTimerReset.

calling SystemIdleTimerReset does not appear to be necessary on the C500, but it should not hurt. It *is* necessary on the Samsung i600.

[Guest Croccy22]

Ok,

So say in the case of the sample gapidraw minimal application. How would i incorporate the fix to get this runing right. Or would this need to be done by Johan as part of the actual gapidraw dll?

Matt

Croccy22

[Guest Marko31]

Up ! :)

[Guest Croccy22]

Erm where?

What I was asking for is what code would I put into the gapidraw minimal application to get it to function correctly.

How do you call GXBeginDraw and what do you do with the real address of the buffer? or does it sort that out itself.

Matt

PS Could someone just paste some sample code of the solution, ie detect the c500 and then apply the fix. I am a gapidraw user so knowing where to put the code would also be helpfull.

[Guest The PocketTV Team]

Erm where?

What I was asking for is what code would I put into the gapidraw minimal application to get it to function correctly.

I believe the code that need to be modified is inside GapiDraw. Check with the developers of the GapiDraw library if they have a version that works well on the C500.

The official answer of GapiDraw authors is in this thread:

http://www.pocketmatrix.com/forums/viewtop...pic.php?t=18014

Johan, from GapiDraw, wrote:

<< Please wait until Orange responds officially to this issue. If they cannot release a fix in a timely manner we will release updates to the GapiDraw library that corrects this issue. It's nothing you can correct on a user-level with GapiApplication. >>

We think that Orange will not be able to come-up with an Over The Air provisionning trick that will magically fix all their C500. Even if they do, the problem would remain in all the other C500 that are branded differently, like Qtek 8010 and iMate 3.

If Orange or HTC provide a firmware upgrade (the most likely scenario), only a small fraction of the C500 users will install the upgrade on their device (5% or less).

So we think the only viable solution for developers is to implement the workaround, regardless of what Orange or HTC do in the future. Also, developers should make sure that if Orange comes up with a fix, it will not "break" apps that use the workaround.

For example, applications should not use the C500 workaround if GXIsDisplayDRAMBuffer() actually returns 0 (no DRAM buffer).