HP rx5900 series firmware issues cause display problems

[The PocketTV Team]

Users have reported incorrect / garbled display when running PocketTV on the new HP Ipaq rx5900 series.

Since PocketTV uses the same technique used by many games and video application for direct access to the frame buffer, it is likely that other applications and games will experience similar problems.

We don't have actual information about the problem on this device, but apparently it is caused by one of the following:

- The orientation returned in incorrect (orientation 0 should always correspond to Portrait orientation on Pocket PC devices)

- The frame buffer data returned by GETRAWFRAMEBUFFER or by GAPI is not in the Portrait orientation (on Pocket PC, GETRAWFRAMEBUFFER and GAPI should always return data corresponding to a Portrait-oriented buffer).

Please let us know if you have more information regarding those firmware issues on the HP Ipaq rx5900 series.

Thanks!

[The PocketTV Team]

[Digby]

In looking at the HP website, this device appears to be a native landscape device (320x240).

I was under the impression that GAPI and GETRAWFRAMEBUFFER would return the memory address of pixel (0, 0) when the display is in its native orientation. I take "native orientation" on this device to be a width of 320 and height of 240 pixels.

Are you saying that GETRAWFRAMEBUFFER isn't returning these values?

I'd be interested to know what's returned in the DDSURFACEDESC struct when you create a DDraw primary surface and lock it. I'm done with using that GAPI/GETRAWFRAMEBUFFER nonsense and I only use DDraw now.

[The PocketTV Team]

[Digby]

[The PocketTV Team]

[joshbu [MSFT]]

[The PocketTV Team]

> Well, AFAIK, no device should be able to return DMDO_180. The fact that HP was able to get away with it seems to indicate that something’s up. I'll look into it.

that was our impression, too - unless of course if a third-party application did set the orientation to DMDO_180, which is not disallowed, but can cause all sorts of problems, since manufacturer's drivers generally do not rotate the D-pad key correctly in this case. another questionable situation...

but we have the proof that this happens on this device (when the orientation is set to portrait with the standard Setting screen applet), because it triggers a fail-safe test on DMDO_180 in our code!

> In the meantime, it's also worth noting: we don't test every device by every OEM. We produce a test suite and a logo program to assist the OEMs in QA.

i know, but unfortunately there are some important things that are not correctly tested by the platform test suite. the latest example is the very serious "spurious private messages" bug that is described here: http://www.modaco.com/Motorola-Q-Spurio ... 42539.html

we discovered yesterday that this bug is present on the new O2 Xda Zinc. It was first reported 8 months ago (on the Motorola Q) and confirmed by Motorola engineers, and we have reported it numerous times to make sure MSFT knows about it, but ne never got any feedback that it got on the MSFT radar, and the fact that new O2 Xda Zinc has the bug probably indicates that no-one at MSFT is aware of this issue.

[joshbu [MSFT]]

OK, so I spoke with one of our low level GDI guys, and basically here's what he said:

The return value from ChangeDisplaySettingsEx is allowed to be any of the orientation values for Windows Mobile. The reason is that it represents both the way the screen is installed in the device and the way the OS is currently set.

He did seem to indicate that DirectDraw should still always be providing the correct data for screen buffer iteration.

I'll still look into this golf game. Maybe it is an app issue?

[The PocketTV Team]

the problems that we reported are not DirectDraw related.

see our detailed posting here: http://www.modaco.com/index.php?showtop ... ntry804775

basically GETGXINFO (and therefore GAPI) return a buffer that is landscape oriented.

the buffer returned by GETGXINFO should always be Portrait oriented.

this is not explicitely defined in any MSFT documentation, but unless it is the case, GAPI will not work correctly.

so it is a bug caused by a fuzzy / ambiguous MSFT specification. if a call (like GETGXINFO or GETRAWFRAMEBUFFER) returns a buffer that is un-related to the current UI orientation (which is the case for theos two calls), then the orientation of this buffer should be "absolute" i.e. related to DMDO_0 (the "native" orientation of Pocket PC's, which is portrait).

also, "The return value from ChangeDisplaySettingsEx is allowed to be any of the orientation values for Windows Mobile" might be true, but it contradicts what MSFT engineers told developers at the last MEDC conference:

i remember asking a MSFT engineer at the last MEDC conference if we should worry about making sure that applications should run in the DMDO_180 orientation, and the answer i got was: don't worry about it, the Settings only allow 3 orientations: Portrait (DMDO_0) and Landscape right and left, but not "up-side-down" DMDO_180. That was true at the time, but the advice given proved to be wrong, he should have said: "yes, some device will run in DMDO_180 orientation, so make sure you support it."

Another interesting fact regarding "The return value from ChangeDisplaySettingsEx is allowed to be any of the orientation values for Windows Mobile": if you set most other devices to a DMDO_180 orientation (using third-party software), the D-pad keys either won't work or will not be rotated correctly. this means that most OEM drivers do not support DMDO_180 orientation. this indicates that OEM's are not aware that they should support DMDO_180 orientation in their drivers.

it also indicates that the MSFT platform tests does not test that OEM's D-pad drivers supports DMDO_180 orientation correctly (on all versions of the OS where ChangeDisplaySettingsEx is implemented, i.s. 2003SE and upper).

> I'll still look into this golf game. Maybe it is an app issue?

this golf game uses GAPI, and because of the problem in GETGXINFO, GAPI returns a landscape-oriented buffer. and since GAPI is supposed to always returned a Portait oriented buffer, it can confuse many GAPI-based applications and games.

[joshbu [MSFT]]

[The PocketTV Team]

[rcp]