a problem that impacts all games on the Axim x30 and some other WM2003SE devices

[The PocketTV Team]

ChangeDisplaySettingsEx hangs on WM2003SE devices.

I think this problem has been reported, but is there a solution ?

For example, the following code snipplet (similar to the example on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui40/html/cerefrotatingcontentofscreen.asp ) will hang on a Dell Axim x30 if display_orientation is different from the current orientation.

DEVMODE devMode = {0};
devMode.dmSize = sizeof devMode;
devMode.dmFields = DM_DISPLAYORIENTATION;
devMode.dmDisplayOrientation = display_orientation;

ChangeDisplaySettingsEx((const TCHAR *)NULL, &devMode, (HWND)NULL, CDS_RESET, NULL);

If the screen is currently rotated to landscape and display_orientation is DMDO_0 (Portrait), ChangeDisplaySettingsEx hangs.

Also, interestingly, this bug seems to impact GXOpenDisplay.

GXOpenDisplay apparently calls ChangeDisplaySettingsEx to reset the screen to Portrait, and because ChangeDisplaySettingsEx hangs, this causes GXOpenDisplay to hang when the screen current rotation is not Portrait.

For us (and for all game developers!), it's a real show-stopper:

On devices like the Dell Axim x30, the IOControl GETRAWFRAMEBUFFER is not implemented, and the only way to get the raw frame buffer address is through GAPI. But when the screen is rotated to landscape when the application is lauched, GXOpenDisplay hangs (because of the problem described above), and any attempt to programatically reset the display to Portrait by calling ChangeDisplaySettingsEx will also hang!

So basically, when an application or game is launched when the screen is oriented in landscape, the application cannot get the raw frame buffer address. On the other hand, if the application is lanched when the screen is in portrait, and then if the screen is lated rotated to landscape, applications have no problem accessing the raw frame buffer.

I suspect that this problem affects all games on the x30.

It also affects applications like PocketTV and Betaplayer.

[picard]

i don't have a x30 and couldn't figure out what was wrong with landscape GAPI usage. i just got reports of crash. this would explain (but you said 'hang' and not 'crash'...)

never the less i already changed the code. i went a little more deeper :) unfortunatelly it's not a perfect solution either. i use the extescape code gxinfo to get the framebuffer information when raw framebuffer not impleneted (gx.dll uses this too). only problem is that i can't determine if it's dram buffered or not (but i don't think any new qvga device will come out that way. and vga devices can be detected)

#define GETGXINFO 0x00020000

typedef struct GXDeviceInfo
{
long Version; //00 (should filled with 100 before calling ExtEscape)
void * pvFrameBuffer; //04
unsigned long cbStride; //08
unsigned long cxWidth; //0c
unsigned long cyHeight; //10
unsigned long cBPP; //14
unsigned long ffFormat; //18
char Unused[0x84-7*4];
} GXDeviceInfo;

ps: actually i could detected dram buffered mode with writing a pixel and check the value with gdi...

[The PocketTV Team]

OK, we'll try that, it seems to be a good idea (albeit undocumented). Thanks for the tip.

> actually i could detected dram buffered mode with writing a pixel and check the value with gdi

no, you cannot. GXOpenDisplay hangs when screen is in landscape :)

and vga devices can be detected
there is no problem with VGA devices, since they all implement GETRAWFRAMEBUFFER .

[picard]

not with gapi. i meant the address returned by gxinfo.

if gapi is using dram buffered mode then gxinfo would return the backbuffer address. and the problem is how can we detect if gxinfo returns the video memory address or backbuffer address (without opening gapi)

could you check if there is gxdma.dll on x30? i can't imagine any other way to call the orientation change during GXOpenDisplay (without changeing the gx.dll) so the question if they used custom gx.dll or original gx.dll with a special gxdma.dll (no dram buffering, just changing and restoring orientation. it could be possible and it would be a better solution as using a custom gx.dll)

[The PocketTV Team]

BTW I confirm that GETGXINFO works, thanks.

We have implemented this workaround in PocketTV 0.14.15 (free download from www.pockettv.com ).

Now it works fine on the Axim x30 when lanched from a landscape screen.

I also confirm that Betaplayer does no crash, it hangs, when launched from a landscape screen on the Axim x30. This is most likely caused by this problem.

I suspect that many games will hang when lauched from landscape screen on the Axim x30. This problem affects games that use GAPI directly.

Games that use PocketHAL or GapiDraw might not have the problem, if those underlying libraries implement a workaround.

[picard]

that was fast :)

i just wanted to state the i didn't upload the corrected BetaPlayer yet...

[The PocketTV Team]

i just wanted to state the i didn't upload the corrected BetaPlayer yet...You are so slow, Picard, you should be ashamed :)

[Jereboam]

Just wanted to say that seeing two developers talking turkey and wanting to help each other out is a pretty cool thing to see...

Way to go guys.

Otherwise you've confused the hell out of me... ;)

J'bm

[The PocketTV Team]

yeah, thanks...


this problem *might* impact PocketHAL. this is under investigation.

first results indicate that PocketHAL does not call GXOpenDisplay on the x30, therefor it would not be affected.

in any case we are also helping the PocketHAL developer to implement a workaround if needed.

[fast_rx]

by the way, apparently this problem impacts PocketHAL, so if you have a game that uses PocketHAL, it will most likely freeze if you lannch it from the landscape screen on the x30.

Hmmm...

I just moved to using the new version of pocketFrog - which uses PocketHAL underneath - and I do NOT have problems with running while in landscape mode on an x30

It still runs the display as portrait, and the buttons are rotated, but there's no freezing or crashing involved.

[Thierry]

by the way, apparently this problem impacts PocketHAL, so if you have a game that uses PocketHAL, it will most likely freeze if you lannch it from the landscape screen on the x30.

I would appreciate it if you would wait for confirmation that PocketHAL is broken before posting that it is. As fast_rx says, I am getting reports that it works as-is. PocketHAL uses multiple drivers and it's quite possible that GAPI isn't even used on the x30. I need to investigate this device some more to make sure that everything is OK.

we are also helping the PocketHAL developer to implement a workaround.

Your help is much appreciated. I am currently investigating whether or not PocketHAL is affected by this. As I already told you, no one ever mentionned any problem with PocketHAL and the x30 in landscape mode. Au contraire, I am getting reports that it works perfectly.

[The PocketTV Team]

I do NOT have problems with running while in landscape mode on an x30.
The problem would be only when you launch the application after having rotated the screen to landscape.

You should have no problem if you launch the application from portrait, and later rotate to landscape.

If you want to test that, make sure the application is not running in background when you rotate to landscape. The best way to ensure that is to do a soft reset.

Now, I never said that PocketHAL was actually impacted by this problem.
Yes, as you said, it might not have the problem, if it does not actually call GXOpenDisplay.

I have edited a previous post to clarify that.

But any application or library that calls GXOpenDisplay (i.e. the GAPI initialization routine) will be impacted.

[fast_rx]

I do NOT have problems with running while in landscape mode on an x30.
The problem would be only when you launch the application after having rotated the screen to landscape.


PocketHAL and pocketFrog both make full screen apps - that usually exit completely. So, yes, the app is launched new in landscape mode and shows no sign of problems - except for the rotation of the d-pad controls.

[The PocketTV Team]

Ok, good, then!

I still recommend that any game or application developer that call GXOpenDisplay should test if their app works when launched on the x30 from landscape oriented screen.

[picard]

i don't have conformation yet, but i think the new SPV C500 Smartphone (with WM2003SE SP) doesn't implenet raw framebuffer and the gapi is drambuffered (probably this is why many games doesn't work well). so the gxinfo method has to be fine tuned for detecting backbuffer memory. in this case i see no other option but to use gapi.

[The PocketTV Team]

i don't have conformation yet, but i think the new SPV C500 Smartphone (with WM2003SE SP) doesn't implenet raw framebuffer and the gapi is drambuffered (probably this is why many games doesn't work well). so the gxinfo method has to be fine tuned for detecting backbuffer memory. in this case i see no other option but to use gapi.

what do you mean: the gxinfo method has to be fine tuned for detecting backbuffer memory ?

i thought that the pointer returned by the gxinfo method was always the address of the raw buffer. not true ?

also, is the raw frame buffer protected ?

why the hell did they decide to use a dram buffer ???

[The PocketTV Team]

By the way, in the past, some devices that were using GAPI DRAM buffer did that because their raw frame buffer could only be accessed using a 16-bit data bus. That was the case with the Casio E-125.

So in that case, even though we could have access to the raw frame buffer, all the routine to write in the frame buffer had to be modified so that they would never do a 32-bit write (only 16-bit would be written in that case).

I hope it's not the case with the SPV C500.

Another case was the iPaq 3900, where they decided to use DRAM buffer because they were affraid some apps would break if GAPI gxdp.cbxPitch was not 2. That was a bad decision from HP/Compaq, but easy to fix in the applications, as we could get access to the raw frame buffer easiely.

[The PocketTV Team]

I did more tests... GETGXINFO does not always return info about the *raw* frame buffer.

For example, on VGA devices (e.g. e800), GETGXINFO returns:

pvFrameBuffer 0x4e1305f0
cbStride = 480
cxWidth = 240
cyHeight = 320

Clearly this is not the same as the raw frame buffer obtained with GETRAWFRAMEBUFFER:

pFramePointer = 0x4e800000
cxStride = 2
cyStride = 960
cxPixels = 480
cyPixels = 640

I think that when GAPI uses DRAM buffer, GETGXINFO returns the info about the DRAM buffer, not the real frame buffer.

On some Smartphone with WM2003SE, it can be the same situation, if the physical resolution of the device is QVGA (rather than 220x176). It may be the case with the SPV C500.

[picard]

I think that when GAPI uses DRAM buffer, GETGXINFO returns the info about the DRAM buffer, not the real frame buffer.
exactly. gx.dll uses gxinfo extescape to get the address returned to the user. so it's not always the real frame buffer, but always the one returned by GXBeginDraw.

On some Smartphone with WM2003SE, it can be the same situation, if the physical resolution of the device is QVGA (rather than 220x176). It may be the case with the SPV C500.
i don't think it's QVGA. i'am still not sure if gapi is drambuffered on the c500, but there are signs :) i will post i have more info...

[The PocketTV Team]

i don't think it's QVGA. i'am still not sure if gapi is drambuffered on the c500, but there are signs :) i will post i have more info...
It's gonna be easy to find. I'll tell you the info that I can get.

[The PocketTV Team]

i don't have conformation yet, but i think the new SPV C500 Smartphone (with WM2003SE SP) doesn't implenet raw framebuffer and the gapi is drambuffered (probably this is why many games doesn't work well). so the gxinfo method has to be fine tuned for detecting backbuffer memory. in this case i see no other option but to use gapi.I started a new thread here for the GAPI issue on the SPV C500:

http://smartphone.modaco.com/viewtopic.php?p=438078#438078