PocketMatrix

We've got the problem on E-Ten X500 which happens on all versions of PocketHAL (tested 1.02, 1.04, 1.05).

We have lock-screen application, which consists of PowerDaemon (windowless unix-like executable which monitors power status) and PocketHAL application with user interface.

PowerDaemon uses
PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);
to tell device is should go into unattended mode instead of power off.
When the device is about to power off, it notices someone wants unattended mode and instead of power off it switches screen off and tells powerdaemon, which in turn launches PocketHAL application, which after successful start tells PowerDaemon "screen is now locked" so PowerDaemon uses.
PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE);
to tell device it can finally turn off. This complicated approach is neccessary, we cannot simplify it.

It works 100% nice on all our test devices (2 HTC, 1 ASUS) except E-Ten X500 where the PocketHAL application laucnhed in unattended mode crashes on first display->Swap();

display->BeginScene() returns true
display->GetBackBuffer() returns some backbuffer and we successfully paint to it.
display->Swap() crashes...

My idea is you do some check in BeginScene but omit it in Swap, not expecting that between these methods device state can change so that Swap will crash?

I attach simplified PowerDaemon source code where it launches Fireworks.exe from /Temp. We use Fireworks as a "paragon" of an PocketHAL application for test, because it is obviously "doing everything as Kzinti supposed",

I cannot find anything wrong with EndScene(). I am wondering if the framebuffer address returned by GETRAWFRAMEBUFFER doesn't get unmapped / invalidated somehow.

What kind of crash is this? Access violation? Something else?

Do you have a callstack and/or address for the access violation?

OK, here is PocketHAL log together with information on access violation.
You were right - access violation writing framebuffer.

OEM String: "X500V03"
PocketHAL (Version 1.0.4)
Display::Create( hwnd = 7C08A3B0, W:0, H:0, O:0, S:1 )
Initializing display...
VideoDetect::DetectDrivers()
GDIDriver: Detect()
GDIDriver: Found W:240, H:320, D:16
VideoDetect: OS Version is 5.2
DriverVGA: Detect()
DriverVGA: Raw info: W:240, H:320, X:2, Y:480, FB:00410020
DriverVGA: Native orientation is 0
DriverVGA: Found W:240, H:320, D:16
DriverVGA: Offset is 0
DriverVGA: Final framebuffer address = 00410020
CreateDriver( 00000008 )
Initializing video driver...
DriverVGA: Initialize()
Driver initialized!
Success, returning display params to caller (W:240, H:320, O:0, S:2)
(...)
0040EB50 str r4, [r0], #4 <-- access violation - r0 points to 00410020 (framebuffer address)

Interesting. So the first log file you sent me says the framebuffer is at 003b0020. Now this second one says it is at 00410020. Both log files have the same OEM ID "x500v3", meaning it is indeed the same device.

I am wondering if the framebuffer gets remapped to a different address when you power off the device (or while you are shutting it down).

Or worst: what if you can't use GETRAWFRAMEBUFFER will shutting down? Then we would be in a pickle...

Question your "normal" log file also says its the x500v3 and the framebuffer is 47D00000... Does that mean it sometimes work and when it does, the address is 47D00000? I am confused.

The device is the same. And it was not soft-reset between tests.

If we run in normal power mode, frame buffer always starts at 0x47d00000

If we run in unattended power mode, frame buffer starts in diiferent locations, but all of them are close to application virtual addresses, it definetely does not look like memory-mapped hardware area.

I have just run Fireworks in unattended mode about 20 times. Most often I got 442000 but also 441000 and sometimes other similar values.

This all looks like bug in WM code specific to E-Ten, so may be we should just forget about it and just accept that PocketHAL applications cannot start on E-Ten in unattended mode.

BTW: May be this address is close to application heap address, because it is just some garbage remained in stack?

RawFrameBufferInfo rfbi = {0}; <-- Do you have this zero out?

ExtEscape(hdc, GETRAWFRAMEBUFFER, 0, NULL,
sizeof(RawFrameBufferInfo), (char *) &rfbi);

Excuse me if I discuss subjects I know very little about...