This site is no longer active and is available for archival purposes only. Registration and login is disabled.

PocketHAL 1.0.5 Released


PocketHAL 1.0.5 Released

Postby Kzinti » Apr 22, 2008 @ 5:23am

Last edited by Kzinti on Mar 29, 2009 @ 12:07am, edited 1 time in total.
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby hrissan » May 12, 2008 @ 9:06am

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",
Attachments
powerdeamon.zip
(17.79 KiB) Downloaded 2160 times
hrissan
pm Member
 
Posts: 30
Joined: Mar 10, 2007 @ 1:38pm


Postby Kzinti » May 12, 2008 @ 5:33pm

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?
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby hrissan » May 13, 2008 @ 7:55am

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)
hrissan
pm Member
 
Posts: 30
Joined: Mar 10, 2007 @ 1:38pm


Postby Kzinti » May 13, 2008 @ 8:24am

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.
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby hrissan » May 13, 2008 @ 11:16am

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.
hrissan
pm Member
 
Posts: 30
Joined: Mar 10, 2007 @ 1:38pm


Postby hrissan » May 13, 2008 @ 11:22am

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...
hrissan
pm Member
 
Posts: 30
Joined: Mar 10, 2007 @ 1:38pm


Postby Kzinti » May 13, 2008 @ 7:00pm

Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby hrissan » May 14, 2008 @ 6:47am

hrissan
pm Member
 
Posts: 30
Joined: Mar 10, 2007 @ 1:38pm


Orientation on MotoQ 9C

Postby zzz » May 14, 2008 @ 1:11pm

zzz
pm Member
 
Posts: 8
Joined: Apr 7, 2008 @ 3:24pm
Location: Donetsk, Ukraine


Postby Kzinti » May 14, 2008 @ 6:28pm

Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby Kzinti » May 15, 2008 @ 3:17am

Last edited by Kzinti on May 17, 2008 @ 12:27am, edited 1 time in total.
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby zzz » May 16, 2008 @ 3:52pm

zzz
pm Member
 
Posts: 8
Joined: Apr 7, 2008 @ 3:24pm
Location: Donetsk, Ukraine


Postby Kzinti » May 16, 2008 @ 5:03pm

Last edited by Kzinti on May 17, 2008 @ 12:26am, edited 1 time in total.
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Postby Kzinti » May 17, 2008 @ 12:25am

Attachments
PocketHAL_ARM_MotoQ9C_Test3.zip
Test3 for MotoQ9c
(68.6 KiB) Downloaded 2058 times
Kzinti
pm Member
 
Posts: 3238
Joined: Jan 13, 2002 @ 5:23am


Next

Return to PocketFrog & PocketHAL


Sort


Forum Description

SDKs for fast and robust device-independent access to Pocket PC display hardware.

Moderators:

sponge, Kzinti

Forum permissions

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

cron