PocketMatrix

There isn't any MotoQ 9H specific code in PocketHAL. But I am also unaware of any problem with it.

Let me know if you need help tracking this down.

well, it looks like there is the same orientation problem as with other Qs. I'll check if I can get a log from one of those.

https://www.imate.com/product.aspx?product=810f

https://www.imate.com/support/Specs/SpecSheet_810-F.pdf

PocketHAL applications appear rotated so the application bottom is to the right.

The log is from version 1.0.4, but the problem is the same as on 1.0.5

OEM String: "ONTIM"
PocketHAL (Version 1.0.4)
Display::Create( hwnd = 7C07BE70, W:0, H:0, O:1, 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:320, H:240, X:2, Y:640, FB:4F626080
DriverVGA: Native orientation is 0
DriverVGA: Found W:320, H:240, D:16
DriverVGA: Offset is 0
DriverVGA: Final framebuffer address = 4f626080
CreateDriver( 00000008 )
Initializing video driver...
DriverVGA: Initialize()
Driver initialized!
RotationDriver: Initialize()
Success, returning display params to caller (W:240, H:320, O:1, S:2)
PocketHAL (Version 1.0.4)
Display::Create( hwnd = 7C07BE70, W:240, H:320, O:1, S:2 )
Initializing display...
CreateDriver( 00000008 )
Initializing video driver...
DriverVGA: Initialize()
Driver initialized!
RotationDriver: Initialize()
Success, returning display params to caller (W:240, H:320, O:1, S:2)
PocketHAL (Version 1.0.4)
Display::Create( hwnd = 7C07BE70, W:240, H:320, O:0, S:2 )
Initializing display...
CreateDriver( 00000008 )
Initializing video driver...
DriverVGA: Initialize()
Driver initialized!
Success, returning display params to caller (W:320, H:240, O:0, S:2)

OK, attached is the picture of what happens on device.

We always call PHAL::Display::Create() with orientation returned by PHAL::GetShellOrientation(). If shell orientation changes, we destroy display and call Create again.

When we start on other devices, Create is called once.

But when we start on hummer, it looks like GetShellOrientation returns different values before and after Display::Create. (?) We do not have access to device, so we are not sure what happens exactly.

Also to help you some comments from i-mate: i-mate 810-F is one of the only phones in the world that has a "native landscape screen". Whilst other devices have screens that are positioned in a landscape orientation they are actually portrait screens rotated 90 degrees - ours is actually natively landscape. What this means is that our screen is 320 x 240 - whilst others are 240 x 320. The thing that may confuse your app is that 320x240 is considered the natural position of the screen (i.e. 0 degrees)

So then the display works properly... You initialize with orientation = 1 at first (and you get a 240x320 screens).

Then you initialize again with orientation = 0, which gets you a 320x240 screen. Again as expected.

There might be a problem with GetShellOrientation(). I will investigate tonight.

Ok, I compiled the yet-unreleased 1.0.6 with logging enabled. I also added some more logging for the shell orientation.

Can you give this one a try? I believe it will work as-is...

Finally some feedback from i-mate team: "When the application started it was in portrait mode. Once I went to “MENU-ADD-APPLICATIONS” the screen rotated to the CORRECT landscape orientation."

We check ShellOrientation (and reset display if changed) in WM_SETTINGCHANGE (but this message did not fire) and also before opening any form or menu (exactly the described case).

Here is the log of new version from hummer (bad guy) and from qtek (good guy). It seems hummer is returning garbage instead of screen orientation? It fluctuates randomly... :(:(

We have an icon in Winterface which reads device orientation periodically to show it to the user, (but does not reset display if changed) that's why all this GetShellOrientations in the log.

OK it sounds like PocketHAL thinks this is the usual 320x240 device that reports the wrong orientation (MotoQ, Blackjack, etc) and compensate for it (when it shouldn't).

I will take a look at the code over the weekend.

Isn't Windows Mobile development fun? Every device does it differently... =(

OK, I implemented a fix. Please give it a try and let me know how it goes.

If this works, I will release this as 1.0.6.

This version will also produce a log.

Finally this version WORKS FINE on i-mate hummer!

Here is another bug report from LG incite (this report is from products all running PocketHAL 1.0.5).
We'll try to send this user something assembled with latest 1.0.6 prerelease and get log files.

Winterface - This freezes in full screen mode but can work very smoothly (and fast) as a Today Plugin (in windowed mode without PocketHAL) showing the taskbar.
Weather - Freezes
FunContact - Freezes
SMS-Chat - Freezes
EyePhoto - Freezes

I wanted to try your applications due to their uniform interface and wanted to find better alternatives to S2U2, S2V, iContact and Pocket CM Contacts. Also, all of your applications a finger friendly and consistent in their looks (very simple yet sleek interface) which appeals to me very much.

My Device is :LG Incite (CT810)
Screen: WQVGA (240x400)
OS: Windows Mobile 6.1

It appears that the applications do work but the screen seems frozen, if I minimize the application using a hardware button and switch to it using the taskmanager, I can see that the screen has been updated with the latest button I tried to press within the application.
Eg:

I load up winterface and it freezes during startup loading animation. After this, I minimize it and switch back to it using taskmanager. Now I can see winterface menu. I press the options button (no screen update, seems frozen) and minimize the application and switch back to it. Winterface has actually shows the modal options dialog.