[ZuinigeRijder]

Happy New Year

I made a new version of TouchLockPro, which supports now also a large number of Samsung phones having a Light Sensor and GSensor:

• SGH-i900 Omnia
  
• SCH-i910 Omnia
  
• GT-I8000 Omnia 2
  
• SCH-m490/m495 T*Omnia
  
• Omnia Pro
  
• GT-B7620 Armani
  
• GT-I8000 Omnia II
  
• SCH-i920 Omnia II

Note that I do not own a Samsung, so I could not test myself. I only tested that the non-Samsung users are not affected by the (small) changes and reviewed my own changes as good as possible. I hope that Samsung users can confirm it is working :cool:

Samsung made it difficult for developers, having different SDK redistributables for different phones and Windows Mobile 6.1 or 6.5. TouchLockPro supports both Samsung SDK redistributables. See Downloads for the Samsung SDK redistirbutables. Of course those need only be installed by people having an appropriate Samsung PhoneType.

People interesting in the Samsung API Specs and details of phones supported, see these documents under version control:
API-spec.2.1.0.pdf
API-spec1.2.1.pdf
Programming Guide.2.1.0.pdf

I have updated the TouchLockPro source code as such, that it is not needed to install the Samsung Windows Mobile SDK, if you want to compile TouchLockPro yourself.

Now hope this version is really working for Samsung users :confused:

This post has been edited by ZuinigeRijder: 04 January 2010 - 08:27 AM

[Sponsored Links]

[h4x0r3d]

ZuinigeRijder, on Jan 1 2010, 19:49, said:

Happy New Year

I made a new version of TouchLockPro, which supports now also a large number of Samsung phones having a Light Sensor and GSensor:

• SGH-i900 Omnia
  
• SCH-i910 Omnia
  
• GT-I8000 Omnia 2
  
• SCH-m490/m495 T*Omnia
  
• Omnia Pro
  
• GT-B7620 Armani
  
• GT-I8000 Omnia II
  
• SCH-i920 Omnia II

Note that I do not own a Samsung, so I could not test myself. I only tested that the non-Samsung users are not affected by the (small) changes and reviewed my own changes as good as possible. I hope that Samsung users can confirm it is working :cool:

Samsung made it difficult for developers, having different SDK redistributables for different phones and Windows Mobile 6.1 or 6.5. TouchLockPro supports both Samsung SDK redistributables. See Downloads for the Samsung SDK redistirbutables. Of course those need only be installed by people having an appropriate Samsung PhoneType.

People interesting in the Samsung API Specs and details of phones supported, see these documents under version control:
API-spec.2.1.0.pdf
API-spec1.2.1.pdf
Programming Guide.2.1.0.pdf

I have updated the TouchLockPro source code as such, that it is not needed to install the Samsung Windows Mobile SDK, if you want to compile TouchLockPro yourself.

Now hope this version is really working for Samsung users :confused:

any screenshots ?

[Ariekanarie]

h4x0r3d, on Jan 3 2010, 11:01, said:

any screenshots ?

You can look on his website in the sentence:
"I made a new version of TouchLockPro, which supports now also a large number of Samsung phones having a Light Sensor and GSensor:"

This post has been edited by Ariekanarie: 03 January 2010 - 09:42 AM

[ZuinigeRijder]

Ariekanarie, on Jan 3 2010, 10:41, said:

You can look on his website in the sentence:
"I made a new version of TouchLockPro, which supports now also a large number of Samsung phones having a Light Sensor and GSensor:"

Yes, here is a direct link to:
Youtube video


The Video shows the features of TouchLockPro. It is a bit long (9 minutes) but should give you the importand info how to use it, including Light Sensor and GSensor.

[Michal Vogl]

Ariekanarie, on Jan 3 2010, 10:41, said:

You can look on his website in the sentence:
"I made a new version of TouchLockPro, which supports now also a large number of Samsung phones having a Light Sensor and GSensor:"

I tried it, but no success. On my i8000 it doesn't work. Has anybody diferent experinece?

[Ender Psp]

Michal Vogl, on Jan 3 2010, 13:38, said:

I tried it, but no success. On my i8000 it doesn't work. Has anybody diferent experinece?

Works for me! Batt/Clock, lock and all settings.

Great app, just make sure you install Samsung Windows Mobile SDK (or from Samsung directly) before TouchLockPro:
http://www.zuinigerijder.com/TouchLockPro/...edist_2_1_0.cab

Haven't played with all the options yet. Will do and post.

Good point Snow02!

This post has been edited by Ender Psp: 03 January 2010 - 03:32 PM

[Snow02]

Ender Psp, on Jan 3 2010, 09:23, said:

Works for me! Batt/Clock, lock and all settings.

Great app, just make sure you do install before Samsung Windows Mobile SDK (or from Samsung directly):
http://www.zuinigerijder.com/TouchLockPro/...edist_2_1_0.cab

Haven't played with all the options yet. Will do and post.

Of course, you mean install the Samsung SDK before this app, not the other way around. The video looked like it has some good features. I'd be interested to see how it functions in day-to-day useability.

This post has been edited by Snow02: 03 January 2010 - 03:56 PM

[Ender Psp]

It should work if you install the sdk after, but probably after a soft reset

Everything works perfectly, with one exception:
- if locked, on an incoming call the screen doesn't unlock. I have installed a policy for locking the phone automatically on 15 minutes but I don't think it should affect this, since it happened within 15 minutes. So apparently the unlock on an incoming call doesn't work as expected. Will see if there's a workaround.

This post has been edited by Ender Psp: 03 January 2010 - 04:11 PM

[ZuinigeRijder]

Ender Psp, on Jan 3 2010, 16:34, said:

It should work if you install the sdk after, but probably after a soft reset

Everything works perfectly, with one exception:
- if locked, on an incoming call the screen doesn't unlock. I have installed a policy for locking the phone automatically on 15 minutes but I don't think it should affect this, since it happened within 15 minutes. So apparently the unlock on an incoming call doesn't work as expected. Will see if there's a workaround.

If you have a slide2answer solution, you can configure in the TAPI settings screen:

KeysOnly (LockWhenIncomingKeyOnly = 1)
Then you can answer via Slide2Unlock, but the hardware keys are still locked.

Strange however, that it does not unlock via light sensor or GSensor.

[ZuinigeRijder]

Snow02, on Jan 3 2010, 16:30, said:

Of course, you mean install the Samsung SDK before this app, not the other way around. The video looked like it has some good features. I'd be interested to see how it functions in day-to-day useability.

At the first install, TouchLockPro tries to identify your phone type. If the Samsung SDK is not installed yet, it will choose another phone type. You can however change the phone type in the TouchLockAction Settings screen manually, also if you did not have installed the Samsung SDK before installing TouchLockPro.

[Ender Psp]

ZuinigeRijder, on Jan 3 2010, 16:18, said:

If you have a slide2answer solution, you can configure in the TAPI settings screen:

KeysOnly (LockWhenIncomingKeyOnly = 1)
Then you can answer via Slide2Unlock, but the hardware keys are still locked.

Strange however, that it does not unlock via light sensor or GSensor.

Thanks for your assistance, ZuinigeRijder!

I don't have S2U. I have my work's policy which enforces the original WM lock after 15 mins.

However, I've been able to bypass the issue via checking "KeysOnly".
I've also unchecked "InCallTweak" (for me).

Unlocking via Gsensor works. I'm not sure how light sensor is supposed to work here?

Another issue I've noticed: with new settings (above), when I reject an incoming call, the notification appears (screen is locked already), the Gsensor unlock doesn't work anymore. It works again after unlock (either press lock and unlock or unlock after timeout).
LE: Apparently this only happens when there's no WM lock. If I lock it (by keeping lock pressed) or after 15 mins, the Gsensor unlock works (phone portrait-upsidedown-portrait).

This post has been edited by Ender Psp: 03 January 2010 - 05:21 PM

[ZuinigeRijder]

Ender Psp, on Jan 3 2010, 18:13, said:

Thanks for your assistance, ZuinigeRijder!

I don't have S2U. I have my work's policy which enforces the original WM lock after 15 mins.

However, I've been able to bypass the issue via checking "KeysOnly".
I've also unchecked "InCallTweak" (for me).

Unlocking via Gsensor works. I'm not sure how light sensor is supposed to work here?

Another issue I've noticed: with new settings (above), when I reject an incoming call, the notification appears (screen is locked already), the Gsensor unlock doesn't work anymore. It works again after unlock (either press lock and unlock or unlock after timeout).

Normally, when the light sensor senses light, it should automatically unlock. So in your pocket it is kept locked, when you take it out of your pocket it automatically unlocks after the default 1.5 secoinds. Is there a value showing in the Light Sensor Settings screen, right-upper corner? Maybe the light sensor does not work?

For the other GSensor issue, I would be glad if you could enable debug logging (LogDebug = 1 in the Other Settings screen), reproduce the scenario, note the exact time and post the debug log file in the root of your phone memory, \TouchLockPro.log.txt as zipped attachment. After doing that, you can disable debug logging again. Maybe that gives me a clue, including light sensor problem

[Ender Psp]

ZuinigeRijder, on Jan 3 2010, 17:20, said:

Normally, when the light sensor senses light, it should automatically unlock. So in your pocket it is kept locked, when you take it out of your pocket it automatically unlocks after the default 1.5 secoinds. Is there a value showing in the Light Sensor Settings screen, right-upper corner? Maybe the light sensor does not work?

For the other GSensor issue, I would be glad if you could enable debug logging (LogDebug = 1 in the Other Settings screen), reproduce the scenario, note the exact time and post the debug log file in the root of your phone memory, \TouchLockPro.log.txt as zipped attachment. After doing that, you can disable debug logging again. Maybe that gives me a clue, including light sensor problem

The Light sensor works and appears to affect the issue. If I uncheck UnlockOnLightSensor, I don't have the above problem. With it enabled, sometimes the screen blanks (phone locks) when I try the Gsensor unlock (portrait-upsidedown-portrait) in the middle of the operation (I suspect due to light changes sensed).

The above light sensor unlock (you described in 1st paragraph) doesn't seem to be working for me. I've tried this: keeping my finger over it until the call is in, then when the incoming call is displayed and I take the finger off (phone is face-up on the table the whole time and above the phone is a ceiling lamp so there's no doubt there's enough light) nothing happens after 1500 (1.5 sec? / the value displayed there)

I didn't mention, it does show "8 Samsung SDK compatible".

Will attach the logs in a few minutes (going for repro).

LE: logs attached:  Logs.rar (10.46K)
Number of downloads: 17
Everything happened at 17:47. I enabled debug, then put the phone face up (with light above phone). I kept the finger over the light sensor and made a call. When the call was displayed, I took off my finger and waited, but the light sensor didn't unlock the phone. Then I clicked ignore, and the screen went locked again (but not blanked). Then I picked the phone up and tried to do the Gsensor unlock: portrait-upsidedown-portrait, but in the middle of the operation the screen went blank again. I unlocked the phone via button and a couple of seconds later the time turned 17:48. So everything should be in the interval 17:47 (after the timeout) to 17:48.

Let me know if I can help otherwise!

Quick suggestion: Since I don't see the old battery icon anymore and I have no ideea if the phone is charging or not. Can you make the battery % blink (at a couple of seconds) or something from time to time as a notification? Or anything else you can think of!
LE: maybe you can swap the % with something else to suggest charging? Maybe "=", "+" or some other char when charging?

This post has been edited by Ender Psp: 03 January 2010 - 06:51 PM

[ZuinigeRijder]

Ender Psp, on Jan 3 2010, 18:40, said:

The Light sensor works and appears to affect the issue. If I uncheck UnlockOnLightSensor, I don't have the above problem. With it enabled, sometimes the screen blanks (phone locks) when I try the Gsensor unlock (portrait-upsidedown-portrait) in the middle of the operation (I suspect due to light changes sensed).

The above light sensor unlock (you described in 1st paragraph) doesn't seem to be working for me. I've tried this: keeping my finger over it until the call is in, then when the incoming call is displayed and I take the finger off (phone is face-up on the table the whole time and above the phone is a ceiling lamp so there's no doubt there's enough light) nothing happens after 1500 (1.5 sec? / the value displayed there)

I didn't mention, it does show "8 Samsung SDK compatible".

Will attach the logs in a few minutes (going for repro).

LE: logs attached: Logs.rar
Everything happened at 17:47. I enabled debug, then put the phone face up (with light above phone). I kept the finger over the light sensor and made a call. When the call was displayed, I took off my finger and waited, but the light sensor didn't unlock the phone. Then I clicked ignore, and the screen went locked again (but not blanked). Then I picked the phone up and tried to do the Gsensor unlock: portrait-upsidedown-portrait, but in the middle of the operation the screen went blank again. I unlocked the phone via button and a couple of seconds later the time turned 17:48. So everything should be in the interval 17:47 (after the timeout) to 17:48.

Let me know if I can help otherwise!

Quick suggestion: Since I don't see the old battery icon anymore and I have no ideea if the phone is charging or not. Can you make the battery % blink (at a couple of seconds) or something from time to time as a notification? Or anything else you can think of!

Thanks for the effort to provide the log files.

I see in the logging you did change the size/colour of the BattClock.
I see in the logging the GSensor moves

2010-01-03 17:47:26 -457606998 ========================POWER_STATE_UNATTENDED====================
- here the power button is pressed to power down

2010-01-03 17:47:26 -410094286 ==================================Lock=============================(true)
- as a result the phone is already locked

2010-01-03 17:47:35 -457606998 SetCallStatus(CALL_INCOMING): 0
- TouchLockPro detects incoming call

2010-01-03 17:47:36 -410094286 Light OFF: 0
2010-01-03 17:47:36 -1521455966 SetOrientation: FaceDown
- TouchLockPro does *NOT* see light, hmmmm, but it sees gsensor changes

2010-01-03 17:47:49 -1521455966 = GSENSOR ORIENTATION MATCH =: 1 numberOk: 1 numbersequence: 3 orientation: 3 Portrait
2010-01-03 17:47:49 -1521455966 = GSENSOR ORIENTATION MATCH =: 2 numberOk: 1 numbersequence: 3 orientation: 3 Portrait
2010-01-03 17:47:49 -1521455966 = GSENSOR ORIENTATION MATCH =: 3 numberOk: 1 numbersequence: 3 orientation: 3 Portrait
2010-01-03 17:47:49 -1521455966 = GSENSOR ORIENTATION MATCH =: 4 numberOk: 1 numbersequence: 3 orientation: 3 Portrait
..
2010-01-03 17:47:49 -1521455966 = GSENSOR ORIENTATION MATCH =: 2 numberOk: 2 numbersequence: 6 orientation: 6 FaceUp
..
2010-01-03 17:47:50 -1521455966 = GSENSOR ORIENTATION MATCH =: 1 numberOk: 2 numbersequence: 4 orientation: 4 UpsideDown
2010-01-03 17:47:50 -1521455966 = GSENSOR ORIENTATION MATCH =: 4 numberOk: 2 numbersequence: 4 orientation: 4 UpsideDown
..
2010-01-03 17:47:50 -1521455966 = GSENSOR ORIENTATION MATCH =: 2 numberOk: 3 numbersequence: 5 orientation: 5 FaceDown
2010-01-03 17:47:50 -1521455966 ==================COMMAND BY GSENSOR ORIENTATION==========================: 2
2010-01-03 17:47:50 -1521455966 Execute(): !LOCKSUSPEND

So in your orientation moves, another GSENSOR sequence is triggered than the !UNLOCK, the !LOCKSUSPEND.
You can disable the other GSENSOR moves, if you do not want to lock the phone via a GSENSOR move. Or define another non-conflicting GSENSOR move for that.

Later on in the logging the orientation moves were correctly:
2010-01-03 17:47:58 -1521455966 = GSENSOR ORIENTATION MATCH =: 1 numberOk: 3 numbersequence: 3 orientation: 3 Portrait
2010-01-03 17:47:58 -1521455966 ==================COMMAND BY GSENSOR ORIENTATION==========================: 1
2010-01-03 17:47:58 -1521455966 Execute(): !UNLOCK

But it looks like the Light Sensor is *NOT* working.
When you go to the TouchLockAction Light Sensor settings screen, what are the readouts in the upper right corner?

[Ender Psp]

ZuinigeRijder, on Jan 3 2010, 19:13, said:

Thanks for the effort to provide the log files.

I see in the logging you did change the size/colour of the BattClock.

[...]

But it looks like the Light Sensor is *NOT* working.
When you go to the TouchLockAction Light Sensor settings screen, what are the readouts in the upper right corner?

Had to change the size, because part of the old battery icon was showing (on the right of TLP). The color was just for convenience

LightSensor value is 0 (zero).

Quote

So in your orientation moves, another GSENSOR sequence is triggered than the !UNLOCK, the !LOCKSUSPEND.
You can disable the other GSENSOR moves, if you do not want to lock the phone via a GSENSOR move. Or define another non-conflicting GSENSOR move for that.

That's interesting. For sure I never put the phone on landscape, I tried portrait-upsidedown-portrait. Not sure why 2-landscape is triggered there? However, I've disabled the !LOCKSUSPEND on 2-portrait, and seems to work fine now.

I've disabled the light sensor too for now, as indeed it appears not to work in TLP (I know for sure it works otherwise, and I can test that easily).

This post has been edited by Ender Psp: 03 January 2010 - 08:41 PM

[KitchMD]

My light sensor isn't working and shows 0 for my i920. I know it works though. If you go to \windows and click on lcdtest.exe, you can test all the sensors in the phone. It shows the light sensor is working fine.

[ZuinigeRijder]

Ok, so there seems to be something wrong with my code for accessing the light sensor.
In my code I was working with DWORD instead of UINT. I do not know if that could cause the problem. I also added debug logging.

Would you please so kind to test the test version.
It is an exe, you can just copy to somewhere on your phone.
Steps to reproduce:
- Enable debug logging in TouchLockAction
- Stop the installed and running TouchLockPro by starting TouchLockPro in the Programs folder and deactivate it
- Start the test version and wait till the BattClock appears (takes 60 seconds)
- Start TouchLockAction via the programs menu and check the readout in the Light Sensor Settings menu
- Stop the test version by executing the test version again (deactivate)
- Post the \TouchLockPro.log.txt again

Hope this gives me more insight why it is not sensing light

Attached File(s)

•  TouchLockPro.exe (45.5K)
  Number of downloads: 39

[ZuinigeRijder]

Aaah. I think I found the bug. There was a space at the end of the routine name for getting the procaddress:

pfnSmiLightSensorGetIlluminance = (PFN_SmiLightSensorGetIlluminance)GetProcAddress(hSamsungLib, L"SmiLightSensorGetIlluminance ");

instead of

pfnSmiLightSensorGetIlluminance = (PFN_SmiLightSensorGetIlluminance)GetProcAddress(hSamsungLib, L"SmiLightSensorGetIlluminance");

Here is the test version with this bug solved. Hope this is the only bug?

Attached File(s)

•  TouchLockPro.exe (45.5K)
  Number of downloads: 72

[KitchMD]

ZuinigeRijder, on Jan 3 2010, 16:24, said:

Ok, so there seems to be something wrong with my code for accessing the light sensor.
In my code I was working with DWORD instead of UINT. I do not know if that could cause the problem. I also added debug logging.

Would you please so kind to test the test version.
It is an exe, you can just copy to somewhere on your phone.
Steps to reproduce:
- Enable debug logging in TouchLockAction
- Stop the installed and running TouchLockPro by starting TouchLockPro in the Programs folder and deactivate it
- Start the test version and wait till the BattClock appears (takes 60 seconds)
- Start TouchLockAction via the programs menu and check the readout in the Light Sensor Settings menu
- Stop the test version by executing the test version again (deactivate)
- Post the \TouchLockPro.log.txt again

Hope this gives me more insight why it is not sensing light

Here it is...

Attached File(s)

•  touchlockpro.log.txt (115.99K)
  Number of downloads: 31

[Ender Psp]

ZuinigeRijder, on Jan 3 2010, 21:35, said:

Aaah. I think I found the bug. There was a space at the end of the routine name for getting the procaddress:

pfnSmiLightSensorGetIlluminance = (PFN_SmiLightSensorGetIlluminance)GetProcAddress(hSamsungLib, L"SmiLightSensorGetIlluminance ");

instead of

pfnSmiLightSensorGetIlluminance = (PFN_SmiLightSensorGetIlluminance)GetProcAddress(hSamsungLib, L"SmiLightSensorGetIlluminance");

Here is the test version with this bug solved. Hope this is the only bug?

Great codepatch, the light sensor works and unlock by it works too!

[Sponsored Links]