Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I looked through ths archives here but I couldn't find any conclusive information on the subject, so I'll try again.

Is there a way in Brew 1.1 to prevent the handset from going into sleep mode and turning off the backlight?

When your BREW phone goes to sleep mode it sends EVT_APP_NO_SLEEP event. Upon receiving this event, return TRUE, this will indicate BREW that your application doesn't want to go to sleep mode, thereby keeping the backlight on.
regards
ruben

When your BREW phone goes to sleep mode it sends EVT_APP_NO_SLEEP event. Upon receiving this event, return TRUE, this will indicate BREW that your application doesn't want to go to sleep mode, thereby keeping the backlight on.
regards
ruben

I understand that EVT_APP_NO_SLEEP is part of Brew 2.0 and does not exist in Brew 1.1, so I can't use it, really. The 1.1 SDK doesn't even contain a definition for this event.

I understand that EVT_APP_NO_SLEEP is part of Brew 2.0 and does not exist in Brew 1.1, so I can't use it, really. The 1.1 SDK doesn't even contain a definition for this event.

yes, that´s true, in 1.1 this is not defined, but it some handsets seems to send and event, it may worth a try,
DBGPRINTF("%d",eCode); in your handle event

yes, that´s true, in 1.1 this is not defined, but it some handsets seems to send and event, it may worth a try,
DBGPRINTF("%d",eCode); in your handle event

Could anyone with the Brew 2.0 SDK installed please look up the value for EVT_APP_NO_SLEEP for me, please?

Could anyone with the Brew 2.0 SDK installed please look up the value for EVT_APP_NO_SLEEP for me, please?

it is as follows
#define EVT_APP_NO_SLEEP 0x405

it is as follows
#define EVT_APP_NO_SLEEP 0x405

Thanks so much, Ruben. Very much appreciated.

Thanks so much, Ruben. Very much appreciated.

I am trying this on a VX4400 with BREW 1.1, and I don't get an event. Is there another way to keep the backlight from turning off? Is there a way I can fake a key event for example?

I am trying this on a VX4400 with BREW 1.1, and I don't get an event. Is there another way to keep the backlight from turning off? Is there a way I can fake a key event for example?

You can use the IDISPLAY_Backlight() function to turn it back on, but it's not very elegant. The backlight will turn off and then back on, creating a flicker.

You can use the IDISPLAY_Backlight() function to turn it back on, but it's not very elegant. The backlight will turn off and then back on, creating a flicker.

I have tried returning TRUE to the 405 event but the backlight still goes off. I am building my app with BREW 1.1 API although I am running on the LG VX 6000 which is a BREW 2.0 device. I have not tested to see if the 405 event is occuring (LOGGER does not work on the VX6000).
I tried the IDISPLAY_Backlight function and it works fine. I see no flicker on my LG VX6000 phone. However, when I leave my game the backlight will be stuck on as long as you do not leave Get-It-Now menu. This means all games thereafter will have the backlight stuck on.
Of course turning off the backlight when I leave the game, leaves the handset with no backlight.
I have not tried this on other phones.

I have tried returning TRUE to the 405 event but the backlight still goes off. I am building my app with BREW 1.1 API although I am running on the LG VX 6000 which is a BREW 2.0 device. I have not tested to see if the 405 event is occuring (LOGGER does not work on the VX6000).
I tried the IDISPLAY_Backlight function and it works fine. I see no flicker on my LG VX6000 phone. However, when I leave my game the backlight will be stuck on as long as you do not leave Get-It-Now menu. This means all games thereafter will have the backlight stuck on.
Of course turning off the backlight when I leave the game, leaves the handset with no backlight.
I have not tried this on other phones.

We have used IDISPLAY_Backlight() on a variety of phones for one of our applications. It works differently on every phone. What can you do, if the OS doesn't run the same on each phone? Just do your best and document the different behavior in your spec you send to NSTL.

We have used IDISPLAY_Backlight() on a variety of phones for one of our applications. It works differently on every phone. What can you do, if the OS doesn't run the same on each phone? Just do your best and document the different behavior in your spec you send to NSTL.

...or just ignore the backlight, like most everyone else. :)

...or just ignore the backlight, like most everyone else. :)

That is eactly what I am going to do!

That is eactly what I am going to do!

For our app, we call SetBacklight every 2 seconds. On some phones (Vx4400, Vx6000 & CDM9500), that keeps the backlight on constantly with no flicker. For the T720 and A530 it only turns on the backlight once it is actually off.
So, we check which phone we are running on at startup. On the T720 and A530, we call every 1/4 second to turn on the backlight. This works pretty well on the A530, which just dims a bit but never goes out completely. The T720 not as nice, but still passable: it will flicker off but generally not long enough to have any impact on the game -- our test audience hasn't complained about it.
I don't recommend calling SetBacklight on every tick. On the T720 that locked up the phone, presumably because of events generated from backlighting going on and off.
I guess next step is to try to check for this backlight off event and see if that works on the T720.

For our app, we call SetBacklight every 2 seconds. On some phones (Vx4400, Vx6000 & CDM9500), that keeps the backlight on constantly with no flicker. For the T720 and A530 it only turns on the backlight once it is actually off.
So, we check which phone we are running on at startup. On the T720 and A530, we call every 1/4 second to turn on the backlight. This works pretty well on the A530, which just dims a bit but never goes out completely. The T720 not as nice, but still passable: it will flicker off but generally not long enough to have any impact on the game -- our test audience hasn't complained about it.
I don't recommend calling SetBacklight on every tick. On the T720 that locked up the phone, presumably because of events generated from backlighting going on and off.
I guess next step is to try to check for this backlight off event and see if that works on the T720.

When I first tried keeping the backlight on in my first games, I found the flickering it creates on the t720 unacceptable. Ever since it is not an issue for me at all. I will not even try to keep it on.
But I guess everyone has a different threshold to that.

When I first tried keeping the backlight on in my first games, I found the flickering it creates on the t720 unacceptable. Ever since it is not an issue for me at all. I will not even try to keep it on.
But I guess everyone has a different threshold to that.

Quote:I don't recommend calling SetBacklight on every tick. On the T720 that locked up the phone, presumably because of events generated from backlighting going on and off.
In our games we do exactly as you said turning on the backlight each 1/4 second and we never got the T720 locked up.
In the beginning, the phone crashed sometimes due to the ISOUNDPLAYER interface but it's now fixed. I'd say that the lock problem you had seen on the T720 has to do with something else and not to the backlighting...
By the way, the EVT_APP_NO_SLEEP doesn't work on the T720...

Quote:I don't recommend calling SetBacklight on every tick. On the T720 that locked up the phone, presumably because of events generated from backlighting going on and off.
In our games we do exactly as you said turning on the backlight each 1/4 second and we never got the T720 locked up.
In the beginning, the phone crashed sometimes due to the ISOUNDPLAYER interface but it's now fixed. I'd say that the lock problem you had seen on the T720 has to do with something else and not to the backlighting...
By the way, the EVT_APP_NO_SLEEP doesn't work on the T720...

It was definitely the Backlight call. But we were calling it every timer tick (30ms), plus every event. So it was just too much. It's always possible I was somehow calling it wrong, or before having completed some critical initialization, but I didn't change anything except frequency (and not calling it in the event handler).
We dropped it to 1/4 second on the T720 and A530 and that fixed it.
Also, neither the T720 nor the A530 -- our two flicker-phones -- generate the APP_NO_SLEEP event

It was definitely the Backlight call. But we were calling it every timer tick (30ms), plus every event. So it was just too much. It's always possible I was somehow calling it wrong, or before having completed some critical initialization, but I didn't change anything except frequency (and not calling it in the event handler).
We dropped it to 1/4 second on the T720 and A530 and that fixed it.
Also, neither the T720 nor the A530 -- our two flicker-phones -- generate the APP_NO_SLEEP event

does turning the backlight on avoid entering sleep mode (slower frame rate)? the turning back light on works on Samsung A610, but it doesn't wake it up from sleep mode, the frame rate is still slow...
Thanks,
Jean

does turning the backlight on avoid entering sleep mode (slower frame rate)? the turning back light on works on Samsung A610, but it doesn't wake it up from sleep mode, the frame rate is still slow...
Thanks,
Jean

No, the light is unrelated to the sleep mode. To avoid that the phone goes into sleep mode you will have to catch the EVT_APP_NO_SLEEP event as described previously - though it does not work on all phones.

No, the light is unrelated to the sleep mode. To avoid that the phone goes into sleep mode you will have to catch the EVT_APP_NO_SLEEP event as described previously - though it does not work on all phones.

thank, Dragon! I tried catching the EVT_APP_NO_SLEEP event on A610, and it doesn't work as expected... so I guess there's no other way to avoid this on A610?
Thanks,
Jean

thank, Dragon! I tried catching the EVT_APP_NO_SLEEP event on A610, and it doesn't work as expected... so I guess there's no other way to avoid this on A610?
Thanks,
Jean

put something in your event handler to display "unknown" (or all) events, and see if you get any events before it goes into sleep mode.
-Tyndal

put something in your event handler to display "unknown" (or all) events, and see if you get any events before it goes into sleep mode.
-Tyndal

no event is received before going to sleep mode on A610...
Thanks,
Jean

no event is received before going to sleep mode on A610...
Thanks,
Jean

hi all,
we have develped a game for both brew 2.0,1.1 versions, we have no problem in keeping backlight on in brew2.0 phones,but if we try the same on 1.1 phones it is degrading the performance, the rendering lag can be easily seen.
my question is if i remove the backlight option, will my application be legible to pass TRUE brew testing,
is it mandatory for the application to always keep the back light on,to pass the TRUE brew testing.
any help will be greately appreciated.
thanks in advance.
mujeeb.

hi all,
we have develped a game for both brew 2.0,1.1 versions, we have no problem in keeping backlight on in brew2.0 phones,but if we try the same on 1.1 phones it is degrading the performance, the rendering lag can be easily seen.
my question is if i remove the backlight option, will my application be legible to pass TRUE brew testing,
is it mandatory for the application to always keep the back light on,to pass the TRUE brew testing.
any help will be greately appreciated.
thanks in advance.
mujeeb.

Yes, you can pass TBT without handling the backlight.

Yes, you can pass TBT without handling the backlight.

hi dragon,
many many thanks,
i have been getting replies to most of my queries from you itself,i am pleased with it,
i really appreciate you for being so patient in replying to the queries,
thanks again,
Mujeeb.

hi dragon,
many many thanks,
i have been getting replies to most of my queries from you itself,i am pleased with it,
i really appreciate you for being so patient in replying to the queries,
thanks again,
Mujeeb.

Anytime. :)

Anytime. :)