Please help get the word out! (about this WM2003 Second Edition video driver issue...)

[The PocketTV Team]

We are trying to get the word to all Pocket PC and Smartphone manufacturers (OEMs) that they *must* implement the driver escape code GETRAWFRAMEBUFFER in their new devices that will be running Windows Mobile 2003 Second Edition (WM2003-SE).

Unfortunately our previous posting was deleted by some Moderator who apparently has no idea of the gravity of the situation (or does not understand it).

No GAPI (Game API) for video in WM2003-SE: Basically video games and video applications (like PocketMVP and PocketTV) will not be able to use GAPI in WM2003-SE, because MSFT managed to completely break it (i.e. make it impossible to use). MSFT is aware of this limitation and does not intend continue supporting GAPI in future versions of Windows Mobile.

Fortunately there is way around this issue is through a new video driver escape code defined by MSFT called GETRAWFRAMEBUFFER, that provides direct access to the display frame buffer (similar to what GAPI does). Unfortunately most Pocket PC and Smartphone manufacturers have not heard of the new escape code, because MSFT did not do a good commucation job, and there is no test in the Microsoft platform SDK that checks that GETRAWFRAMEBUFFER is implemented. So there is no guarantee that it will be implemented in the video drivers!

It is critically important that GETRAWFRAMEBUFFER be implemented in both hi-res (VGA) *AND* lo-res WM2003-SE devices. MSFT does not make this point clear, as they suggest that GETRAWFRAMEBUFFER is only necessary in hi-res devices.

The situation is serious: If we do nothing to inform OEM's, probably more that half of the new Pocket PCs and Smartphones will not have GETRAWFRAMEBUFFER, and since GAPI is seriously broken on WM2003-SE, this means that video games and video players will either have awful performances, or just not work on those devices. And you (the user or the game developer) will get pissed. And the manufacturers will get pissed because of bad reviews and customer returns. When the new devices will be released, it will be too late to fix the problem!

I hope Pocket PC thoughts can help making sure this comes to the hears of all the OEM's.

There is some information on GETRAWFRAMEBUFFER on the Microsoft website:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwm2k3/html/dpi_awareness.asp

Note that the data returned by GETRAWFRAMEBUFFER should always assume that the frame buffer is oriented in the native Portrait orientation, regardless of the orientation of the UI. This in not clear in the MSFT documentation. To add some confusion, there is a bug in the implementation of GETRAWFRAMEBUFFER in the emulators.

In order to test video drivers on WM2003-SE devices, we have created a BETA version of PocketTV (http://discussion.brighthand.com/showthread.php?s=&threadid=103149) that tests if GETRAWFRAMEBUFFER is correctly implemented on WM2003-SE devices and displays a message when it is not the case.

More bad news: please read http://www.pocketpcthoughts.com/forums/viewtopic.php?p=233239#233239

[JustinGTP]

So how do you we get this "Serious word" out to manufacturers and how do I not know you are pulling a fast one? :wink:

[The PocketTV Team]

> So how do you we get this "Serious word" out to manufacturers

You increase the chance that they will know about that by posting this info on places where some of their engineers may see it.

And since this serious situation will impact all the game developers (a pretty significant part of the mobile software industry), you make sure that game developers know about the problem and contact the OEM's directy if they can, to make sure they know about that.

> and how do I not know you are pulling a fast one?

I'm not sure what you mean.

If you are wondering if this is not a joke: no, it is not. We were at the Microsoft Mobility Conference laste week, where we had the chance to talk with many people from Microsoft, so we have a pretty clear idea of the situation. We are also directly in contact with some OEM's.

[Jason Dunn]

I'll do my best to pass the word along, but my experience tells me that it's already too late to get these changes made. :(

[The PocketTV Team]

I'll do my best to pass the word along, but my experience tells me that it's already too late to get these changes made. :(

Thanks!

No, it is NOT too late! OEM's have not yet released their new products, they are still working on the firmware and debugging their drivers.

And we are not talking about a "change": GETRAWFRAMEBUFFER is already defined by MSFT in the WM2003-SE specification. But MSFT did not make sure that OEM's were made aware of it and that they *must* implement it. And since it does not affects their WMP (which uses its own internal private API, not GAPI), they don't really care that much.

Inplementing GETRAWFRAMEBUFFER is very simple for them, since this call does nothing else than return the address of the raw frame buffer and information about its organization (width, heigth, xPitch, yPitch, pixel format), and make sure this address is always mapped in the address space of the application.

No video game will work on the new WIN2003-SE devices that don't implement GETRAWFRAMEBUFFER.

[Fishie]

Damn, thats a bitch

[Kiki]

bump

[The PocketTV Team]

Short version:

On some WM2003-SE devices, even if GETRAWFRAMEBUFFER is implemented in the video driver, applications and games that access the raw frame buffer they will always crash (possibly freeze or hard-reset the device) when the user presses the <rotate screen> button.

The problem also affects MSFT's own WMP (Windows Media Player!).

Long version:

I am trying to use GETRAWFRAMEBUFFER for direct access to the raw frame buffer on an early device running a BETA of WM2003-SE.

When the UI is in Portrait orientation, everything works just fine.

But as soon as the UI gets rotated to Landscape (in this case, "Landscape left-handed"), the data that was originally returned by GETRAWFRAMEBUFFER becomes immediately invalid, causing the app that was using it to crash with an access violation.

Basically, when the video driver of this device is notified that rotation must
be changed, it changes the organization of its frame buffer memory in a way the becomes incompatible with what was returned GETRAWFRAMEBUFFER (e.g. maybe the frame buffer address changes, or the xPitch etc).

And since the application does NOT get notified BEFORE the rotation is done in the driver, any application or game that was drawing in the raw frame buffer when the rotation was initiated by the user (i.e. press the rotation button) will crash.

This is the situation that I was fearing the most. It is very serious IMHO, and I cannot think of a good workaround.

This means that applications cannot use the raw frame buffer on some devices in which the video driver changes the raw frame buffer memory organization when the UI is rotated. Naturally this depends of the video hardware and driver, and we have another device (from another OEM) where there is no such problem.

Is my analysis correct ?

Possible solutions:

1) The best to solve the problem would be, in that case, to notify the applications in a synchronous way, before changing anything in the driver, so that applications that access directly the raw frame buffer can stop doing so until they know what is the new address and organization of the raw frame buffer after the rotation.

Unfortunately this is not currently implemented in the WM2003-SE OS, which is frozen (according to MSFT).

2) Another way (more restrictive) would be to force all the OEM's to keep the same memory organization when screen rotation occurs. Apparently some do, but it may be difficult or impossible with some type of video hardware.

But at least, it is *VERY* important that OEM try to keep the same memory organization when rotation occurs, if they can, until a better solution can be found.

3) Applications could try to prevent the user from causing a rotation by pressing the <rotate screen> button when they know that rotating the UI could cause them to crash.

I am not sure if this is possible. The application, when active, could try
to find if a button is mapped to the screen rotation. In that case, the
application could re-map the button to prevent a rotation.

How can you tell if a button is mapped to <rotate screen> ?

Looking at devices like the new Motorola MPx which rotates depending on the hinge used to flip the phone opened, is it possible to prevent the rotation from occuring ?

-t

[Thierry]

No GAPI (Game API) for video in WM2003-SE: Basically video games and video applications (like PocketMVP and PocketTV) will not be able to use GAPI in WM2003-SE, because MSFT managed to completely break it (i.e. make it impossible to use). MSFT is aware of this limitation and does not intend continue supporting GAPI in future versions of Windows Mobile.

OK, so what are we missing here? You say that GAPI is "broken". What does that mean?

Microsoft's documentation says that GAPI will be emulated to provide backward compatibility to legacy applications and that you can access the whole screen by defining the "HI_RES_AWARE" resource.

Future version of Windows Mobile will have DirectX Mobile, so GAPI won't be needed.

What is the problem here? Something to do with screen rotation?

[The PocketTV Team]

Their "emulation" can only work when application call GXOpenDisplay with GX_FULLSCREEN only once, at the very beginning.

Applications and games that use GAPI but also have a UI (i.e. use menus or dialog boxes in some of their screens) will not work, and those that call GXOpenDisplay and GXCloseDisplay at different point will not work.

Also, apparently, if the device is in Landscape orientation, calling GXOpenDisplay will freeze the device.

Applications that assume that GXEndDraw does nothing (which is the case on 99% of the devices) and ommit to call it will not work (but in that case, it's the application's fault, because they do not follow the guidelines).

It's a bit more complicated, but that's the Cliff Notes. In one word, the display part of GAPI is broken on WM2003-SE, and if you were using GAPI for video, now you should use GETRAWFRAMEBUFFER.

What this means is that 90% of the Pocket PC games and video applications (available at Handango, PocketGear, etc) will not work on WM2003-SE devices (until they are addapted to use GETRAWFRAMEBUFFER). PocketMVP is still part of the 90%. PocketTV now uses GETRAWFRAMEBUFFER, so it should work.

> Future version of Windows Mobile will have DirectX Mobile, so GAPI won't be needed.

Of course, but WM2003-SE does not have DirectX Mobile.

[Thierry]

If this is all true, then all we have to do is write our own implementation of GX.DLL and distribute it with our apps (or even by itself).

I can believe that there will be issues and gotchas, but I am having a hard time believing that devices will ship with so many GAPI problems. Applications that do not call GXBeginDraw()/GXEndDraw() each frame or that cache the pointer returned by GXBeginDraw() don't deserve to run anyways.

Can't wait for HP to release the update for the 2210 so that I can try it out.

[JasonFul]

... And since it does not affects their WMP (which uses its own internal private API, not GAPI), they don't really care that much.
...


Windows Media Player does not use any private APIs. It uses GETRAWFRAMEBUFFER, GAPI, and GDI just as any ISV application would.

______________
Jason Fuller
Software Development Lead
Microsoft Mobile Devices Product Group

[The PocketTV Team]

> Windows Media Player does not use any private APIs. It uses GETRAWFRAMEBUFFER, GAPI, and GDI just as any ISV application would.

Some people at MSFT told me that WMP was using its private direct draw dll.

But under this layer, yes, apparently WMP uses GETRAWFRAMEBUFFER when it is available.

In fact that's why WMP is also a victim of the bug described here:
http://www.pocketpcthoughts.com/forums/viewtopic.php?p=233239#233239

But when GETRAWFRAMEBUFFER is not available, apparently WMP does not use GAPI on WM2003-SE, it uses GDI.

We have a device where GXOpenDisplay hangs when in Landscape and that has no GETRAWFRAMEBUFFER. If WMP was trying to use GAPI on this device, it would freeze, but it does not.

[Thierry]

If there is a private DirectDraw DLL for WMP, then why not use it.

[The PocketTV Team]

If there is a private DirectDraw DLL for WMP, then why not use it.
You can try.

I don't think it's fully implemented yet and there is no libraries (.lib) files available. It's "Work in Progress". Only MSFT can use it.

[Thierry]

If there is a private DirectDraw DLL for WMP, then why not use it.
You can try.

I don't think it's fully implemented yet and there is no libraries (.lib) files available. It's "Work in Progress". Only MSFT can use it.

If thats the only option we have, I will do it. You don't need a .lib to load a DLL and access it's entry points. It may take some time to figure out everything, but it definitely can be done.

[The PocketTV Team]

If there is a private DirectDraw DLL for WMP, then why not use it.
You can try.

I don't think it's fully implemented yet and there is no libraries (.lib) files available. It's "Work in Progress". Only MSFT can use it.

If thats the only option we have, I will do it. You don't need a .lib to load a DLL and access it's entry points. It may take some time to figure out everything, but it definitely can be done.
Even if you do that, it would not solve the issue described there:
http://www.pocketpcthoughts.com/forums/viewtopic.php?p=233239#233239

That's because the video drivers are not currently capable of supporting correctly the rotation, even with direct draw.

In fact, even WMP has the problem described in the URL above.

[Thierry]

That's because the video drivers are not currently capable of supporting correctly the rotation, even with direct draw.

In fact, even WMP has the problem described in the URL above.

This is pretty easy to work around: just trap the access violation and stop accessing the screen until you are notified of the rotation.

Seriously, stop alarming everyone for no good reasons. Programmers will find a way around the issues, if there is any left with the actual devices.

If WMP crashes when you rotate the screen, you can be sure MS will fix it before it is released.

[The PocketTV Team]

In the case of WMP there is no access violation. It just draws the video at completely wrong places.

Thanks for your concerns. You may think it's no big deal, no cause for alarm.

However, all the OEM's are aware of the issue, their enginneers are evaluating it, and from what we hear, they (and MSFT) agree it's pretty serious.

When you will realize that most video games will not work well on WM2003-SE devices, you may change your mind, but it will be too late.

It would not help at all to downplay these issues.

[Thierry]

It might be a serious issue. But as long as the Pocket PC has a screen, it will be possible to access it. One way or another.

[The PocketTV Team]

It might be a serious issue, but as long as the Pocket PC has a screen, it will be possible to access it, one way or another.
Yeah, I'm sure you'll solve the problem in PocketHAL :)

Actually the best way for you (on devices that have the ATI chip) is to use the ATI SDK, like we do.

This requires signing an NDA with ATI. But it solves all the issues related to using the raw frame buffer on WM2003-SE devices that have the ATI chip.

[Thierry]

Yeah, I'm sure you'll solve the problem in PocketHAL :)

You bet.


Actually the best way for you (on devices that have the ATI chip) is to use the ATI SDK, like we do.


The Imageon 100 is slow when transferring data from RAM. SDK or not. And the SDK is probably not that useful for PocketHAL since I am not doing video decompression.

This requires signing an NDA with ATI. But it solves all the issues related to using the raw frame buffer on WM2003-SE devices that have the ATI chip.

I know how that works... I have NDAs with a few companies. But not ATI. They simply do not answer my emails (I've tried to apply 3 times). Do you have a contact there I can use?


BTW you guys are doing something REALLY annoying: you distribute the Imageon 100 DLL with PocketTV and install it on every device (ATI or not). When PocketTV runs, it loads that DLL (even though it is obviously not using it). This caused me a lot of problem as I am also using that DLL on ATI PocketPCs. When PocketTV was running in the background, I would (wrongly) detect an ATI chip and access the DLL, causing access violations. This took me a while to figure out.

[The PocketTV Team]

> The Imageon 100 is slow when transferring data from RAM. SDK or not.

I was talking about the Imageon 3200, which is very fast, especially if the video frame buffer is allocated in the Internal memory (that's the case with the frame buffer)

> And the SDK is probably not that useful for PocketHAL since I am not doing video decompression.

The SDK gives you access to the raw surfaces. It is very useful, even if you don't use compression.

MPEG compression acceleration is provided by a different part of the SDK, which you don't need to use unless you implement video compression.

> I know how that works... I have NDAs with a few companies. But not ATI. They simply do not answer my emails (I've tried to apply 3 times). Do you have a contact there I can use?

I can help you with that. Please contact us directly using the "Contact" link at the bottom of the www.pockettv.com page (don't use PM).

[The PocketTV Team]

BTW you guys are doing something REALLY annoying: you distribute the Imageon 100 DLL with PocketTV and install it on every device (ATI or not). When PocketTV runs, it loads that DLL (even though it is obviously not using it). This caused me a lot of problem as I am also using that DLL on ATI PocketPCs. When PocketTV was running in the background, I would (wrongly) detect an ATI chip and access the DLL, causing access violations. This took me a while to figure out.
That's because you do not use the right way to detect if the ATI Chip is present.

You should never say that if the dll is present, the chip must be there. It's not the correct way, and any application can have the dll installed and loaded.

If the ATI dll is present, you should call AtiCore_ProcessAttach to detect if the chip is there.

The reason why the dll gets loaded is that PocketTV uses it to detect if the chip is present. It does not assume that only the e740 has the ATI 100. It would be wrong, for example the e750 also has it.

Same goes with the ATI 3200. You should never assume that it is there or not, you should use the ATI-provided routines to detect if the hardware is present (and available).

However, this discussion is completely off-topic.

[Thierry]

You should never say that if the dll is present, the chip must be there. It's not the correct way, and any application can have the dll installed and loaded.

If the ATI dll is present, you should call AtiCore_ProcessAttach to detect if the chip is there.

Which is precisely what I do. And AtiCore_ProcessAttach() crashes.

However, this discussion is completely off-topic.

Agreed. I'll stop here.

[Fishie]

Dont stop please, I like this.

[Thierry]

We cannot continue as this would mean violating NDAs with ATI.

[PetiteFlower]

I think it would be fascinating if I had any idea what half the stuff you were talking about was :)

Anyway lay-woman's POV--if it affects WMP, then the OEMs will see it in their beta tests and hopefully fix it or get MS to fix it. WMP is an integral part of the OS so it kinda has to work. So in a way, it's good that the bug affects it.

Good luck anyway!

[DisplayDriver]

Very frustrated when working with GETRAWFRAMEBUFFER and GXDMA for WM2003-SE. Actually, WM2003-SE always assume the device will start in native Portrait mode and the WMP will screw up when you program the device to start in Landscape mode.

I have been trying to contact MS but no reply yet.

[The PocketTV Team]

The Dell Axim X30 is the first SP2003SE Pocket PC that we know that does NOT implement GETRAWFRAMEBUFFER.

Apparently they did not even try to run PocketTV in their tests. If they had, they would have seen a big error message warning them of the issue.

Shame on Dell!

[Fishie]

In other news I went back to regular Win Mobile 2k3 after my SE upgrade a couple of weeks ago.

The performance hit for graphics intensive stuff was just too big and as the PTV team here said many games became horribly horribly broken.

Ill prolly wait for the next Toshiba now and keep the E800, or maybe the Asus or something.

Thanks for the discusion here guys it was really informative.

[Skoobouy]

*sniff sniff*. I know that scent. I've smelled it before. But where? Oh yes, now I remember: the first PXA-250 X-Scale 400MHz PPC 2k2s; the beleageured Toshiba e750, iPaq 3900, and Axim X5. It's Summer 2002 again, and we're doing the New-Wave-of-Hot-Shot-Machines-That-Suffer-Technical-Issues-Dance! 0X

I think I need a drink. :?

[Fishie]

*sniff sniff*. I know that scent. I've smelled it before. But where? Oh yes, now I remember: the first PXA-250 X-Scale 400MHz PPC 2k2s; the beleageured Toshiba e750, iPaq 3900, and Axim X5. It's Summer 2002 again, and we're doing the New-Wave-of-Hot-Shot-Machines-That-Suffer-Technical-Issues-Dance! 0X

I think I need a drink. :?


Hahahaha, its just slower.

Everything else about it was better IMO, but hey im a gamer and I feel the need for speed so back i went.

For most regular people even with the machine being slower im sure itl be seen as a big improvement.

[The PocketTV Team]

We think we have been able to work around the GETRAWFRAMEBUFFER issue on the x30 (with no loss of performances).

You should use PocketTV 0.14.4, now available from the download section on www.pockettv.com .

More information in this thread:
http://www.aximsite.com/boards/showthread.php?s=&threadid=43812

[david291]

The Dell Axim X30 is the first SP2003SE Pocket PC that we know that does NOT implement GETRAWFRAMEBUFFER.

Apparently they did not even try to run PocketTV in their tests. If they had, they would have seen a big error message warning them of the issue.

Shame on Dell!
I'm not surprised. I have a similar frustration related to their wireless implementation on the X3 and X30. They don't seem to care and I can't get access to the right people to get them to fix it.

Although in my case, we sell our software in a vertical market, and I can simply tell our resellers/installers not to buy Dell hardware. Dell loses more than we do, but I'd still like to have the option of using the X30 hardware. More choice is a good thing.

[The PocketTV Team]

Well, we discovered another related problem that affects the x30 (and probably all other QVGA WM2003SE devices that do not implement GETRAWFRAMEBUFFER).

Basically games and other video applications have no way to find the address of the raw frame buffer if the screen is in landscape orientation when the application is lauched.

Read this for technical details: http://www.pocketpcthoughts.com/forums/viewtopic.php?t=31405

We will implement a hard-coded workaround for the x30, but this problem affects all games and video applications (like Betaplayer).

:(

[The PocketTV Team]

We are trying to get the word to all Pocket PC and Smartphone manufacturers (OEMs) that they *must* implement the driver escape code GETRAWFRAMEBUFFER in their new devices that will be running Windows Mobile 2003 Second Edition (WM2003-SE).

Unfortunately our previous posting was deleted by some Moderator who apparently has no idea of the gravity of the situation (or does not understand it).

No GAPI (Game API) for video in Pocket PC WM2003-SE: Basically video games and video applications (like PocketMVP and PocketTV) will not be able to use GAPI in Pocket PC WM2003-SE, because MSFT managed to completely break it (i.e. make it impossible to use). MSFT is aware of this limitation and does not intend continue supporting GAPI in future versions of Windows Mobile.

Fortunately there is way around this issue is through a new video driver escape code defined by MSFT called GETRAWFRAMEBUFFER, that provides direct access to the display frame buffer (similar to what GAPI does). Unfortunately most Pocket PC and Smartphone manufacturers have not heard of the new escape code, because MSFT did not do a good commucation job, and there is no test in the Microsoft platform SDK that checks that GETRAWFRAMEBUFFER is implemented. So there is no guarantee that it will be implemented in the video drivers!

It is critically important that GETRAWFRAMEBUFFER be implemented in both hi-res (VGA) *AND* lo-res WM2003-SE devices. MSFT does not make this point clear, as they suggest that GETRAWFRAMEBUFFER is only necessary in hi-res devices.

The situation is serious: If we do nothing to inform OEM's, probably more that half of the new Pocket PCs and Smartphones will not have GETRAWFRAMEBUFFER, and since GAPI is seriously broken on WM2003-SE, this means that video games and video players will either have awful performances, or just not work on those devices. And you (the user or the game developer) will get pissed. And the manufacturers will get pissed because of bad reviews and customer returns. When the new devices will be released, it will be too late to fix the problem!

I hope Pocket PC thoughts can help making sure this comes to the hears of all the OEM's.

There is some information on GETRAWFRAMEBUFFER on the Microsoft website:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwm2k3/html/dpi_awareness.asp

Note that the data returned by GETRAWFRAMEBUFFER should always assume that the frame buffer is oriented in the native Portrait orientation, regardless of the orientation of the UI. This in not clear in the MSFT documentation. To add some confusion, there is a bug in the implementation of GETRAWFRAMEBUFFER in the emulators.

In order to test video drivers on WM2003-SE devices, we have created a BETA version of PocketTV (http://discussion.brighthand.com/showthread.php?s=&threadid=103149) that tests if GETRAWFRAMEBUFFER is correctly implemented on WM2003-SE devices and displays a message when it is not the case.

More bad news: please read http://www.pocketpcthoughts.com/forums/viewtopic.php?p=233239#233239