PocketHAL 1.0.5 Released

[Kzinti]

PocketHAL 1.0.5 is available.

- Fixed orientation issue with the following devices (all 320x240): Blackjack SGH-i601, Asus M530w, Samsung i320, Ubiquio 503g
- Fixed timer drift issue on the SPV E200

You can download PocketHAL here: http://www.droneship.com/downloads.html

Donators can obtain the registered copy (without the logo/banner) by e-mailing us.

[hrissan]

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",

[Kzinti]

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?

[hrissan]

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)

[Kzinti]

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.

[hrissan]

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]

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...

[Kzinti]

Yes I do clear that structure to zero properly.

It does look like a problem with the device and I am not sure I can do much about it.

[hrissan]

OK, so be it, We'll just add this incompatibility to our product FAQ.

[zzz]

Hi!

The orientation problems seem to be back again Now on Moto Q9C - it starts rotated 90 degrees, not in landscape mode.

Here s the log (from a logged RC2 version I had):

Code: Select all

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19

OEM String: "MotoQ9c" PocketHAL (Version 1.0.4) Display::Create( hwnd = 7C08E830, W:320, H:240, 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:49A00080 DriverVGA: Native orientation is 0 DriverVGA: Found W:240, H:320, D:16 DriverVGA: Offset is 0 DriverVGA: Final framebuffer address = 49a00080 CreateDriver( 00000008 ) Initializing video driver... DriverVGA: Initialize() Driver initialized! Success, returning display params to caller (W:240, H:320, O:0, S:2)

19 lines; 0 keywds; 29 nums; 79 ops; 1 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

Unfortunately, I don't own this device, it's a support request from one of the customers, but I hope this info would be enough.

Thanks in advance,
Anatoliy

[Kzinti]

Yes, this does look like the same problem the original MotoQ has. Stay tuned, I should be able to post a test version here tonight.

[Kzinti]

I can't believe companies are still releasing devices without testing them properly... Anyways.

I have implemented the classic Motorola Q fix for the Motorola Q9C. Can you give this version a try and let me know if it works properly? I have enabled logging so we can get updated information about the device.

<Deleted Test attachment>

[zzz]

I have implemented the classic Motorola Q fix for the Motorola Q9C. Can you give this version a try and let me know if it works properly? I have enabled logging so we can get updated information about the device.

Thanks, Kzinti, but unfortunately it still starts rotated. Here is the new log:

Code: Select all

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19

OEM String: "MotoQ9c" PocketHAL (Version 1.0.5) Display::Create( hwnd = 7C0898D0, W:320, H:240, 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:49A00080 DriverVGA: Native orientation is 0 DriverVGA: Found W:240, H:320, D:16 DriverVGA: Offset is 0 DriverVGA: Final framebuffer address = 49a00080 CreateDriver( 00000008 ) Initializing video driver... DriverVGA: Initialize() Driver initialized! Success, returning display params to caller (W:240, H:320, O:0, S:2)

19 lines; 0 keywds; 29 nums; 79 ops; 1 strs; 0 coms    Syntactic Coloring v0.4 - Dan East

[Kzinti]

That is weird, it didn't detect the device at all (hence no patch applied). Might be a bad build, I am not sure.

Here is another try:

<Deleted Test2 attachment>

[Kzinti]

OK, I found the problem. I did something really stupid in the detection code. Try this version and it should work this time.