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

Developer

Forums

Forums:

Hi all,

There always is the status bar, which contains the status of the communication,

Battery etc., on screen top in handset. Is thare any way to shield it to realize

true the full screen? any suggestions?

LOL
You wish! This is Brew, man! Welcome to the esoteric world of Qualcomm.

LOL
You wish! This is Brew, man! Welcome to the esoteric world of Qualcomm.

It couldn't be that the carriers or OEMs objected, eh? ;)

It couldn't be that the carriers or OEMs objected, eh? ;)

it should be upto end users to decide , like a windows game asking to be full screen or windowed, especially if future cellphones want to attempt the 'harcore' gamer market.
if the carriers or OEMS are the ones objecting then it should be said, then we can add notes to our games to tell our customers who they can complain too about it, as can we.
Motorola T720 forces it, yet the MPX200/220 doesn't, so is it verizon doing it ? ATT&T sell both the T720 and the MPX200

it should be upto end users to decide , like a windows game asking to be full screen or windowed, especially if future cellphones want to attempt the 'harcore' gamer market.
if the carriers or OEMS are the ones objecting then it should be said, then we can add notes to our games to tell our customers who they can complain too about it, as can we.
Motorola T720 forces it, yet the MPX200/220 doesn't, so is it verizon doing it ? ATT&T sell both the T720 and the MPX200

In all honesty, I don't even think the carriers are sophisticated enough to have an own opinion about stuff like an annunciator. Like most things software-related I am almost positive they've had outside consulting, and as is the case so many times, the recommendations that have been made on the subject have been very poor. At least that's how it presents itself to me.

In all honesty, I don't even think the carriers are sophisticated enough to have an own opinion about stuff like an annunciator. Like most things software-related I am almost positive they've had outside consulting, and as is the case so many times, the recommendations that have been made on the subject have been very poor. At least that's how it presents itself to me.

Many carriers have very distinct requirements for the behavior of a handset - where do you think the privacy alerts on TAPI calls came from? Carriers have also influenced such things as the behavior of BREW when the clamshell is closed, the access to annunciators, whether BREW is suspended when an SMS is received while a data call is open, if the IPosdet interface is enabled on commercial phones, etc. etc.
Even so, I believe full screen access is planned for a future release - the problem is just getting everyone to agree on one thing.

Many carriers have very distinct requirements for the behavior of a handset - where do you think the privacy alerts on TAPI calls came from? Carriers have also influenced such things as the behavior of BREW when the clamshell is closed, the access to annunciators, whether BREW is suspended when an SMS is received while a data call is open, if the IPosdet interface is enabled on commercial phones, etc. etc.
Even so, I believe full screen access is planned for a future release - the problem is just getting everyone to agree on one thing.

Good to hear that, Max. Thanks for the heads-up.

Good to hear that, Max. Thanks for the heads-up.

Looks like there is not a method now to realize the full screen,very pity.
Anyway, thanks all above.

Looks like there is not a method now to realize the full screen,very pity.
Anyway, thanks all above.

Dragon,
I can assure you that some carriers at least have very strong thoughts regarding annunciators and spend a signifigant amount of time specifying behaviour to OEMS. They also spend a LOT of time working with OEMs on other things regarding network access behaviour, SMS/Voice/Data interaction etc. etc. I think you are selling them a little short with such comments.

Dragon,
I can assure you that some carriers at least have very strong thoughts regarding annunciators and spend a signifigant amount of time specifying behaviour to OEMS. They also spend a LOT of time working with OEMs on other things regarding network access behaviour, SMS/Voice/Data interaction etc. etc. I think you are selling them a little short with such comments.

don't sell dragon short on his side either, i doubt theres many, or any, at qualcomm or verizon with his experience in the games industry.
other carriers allow full screen access no problem, future phones are likely to have fullscreen access too, so its entirely possible and frequent.
What he is looking for is to make the best games for the people who are the important ones in all of this, the end users, we can give them a choice, full screen or not, but we can't give a choice if the OS doesn't support it, it also makes sure that brew is competitive with other mobile OS's.
talking about it, gets these things changed, we've already influenced changes in other areas and intend to influence others.

don't sell dragon short on his side either, i doubt theres many, or any, at qualcomm or verizon with his experience in the games industry.
other carriers allow full screen access no problem, future phones are likely to have fullscreen access too, so its entirely possible and frequent.
What he is looking for is to make the best games for the people who are the important ones in all of this, the end users, we can give them a choice, full screen or not, but we can't give a choice if the OS doesn't support it, it also makes sure that brew is competitive with other mobile OS's.
talking about it, gets these things changed, we've already influenced changes in other areas and intend to influence others.

Yep - fair enough. Was simlpy making the point that carriers do spend a lot of time looking at things like this, and do not make these decisions/requirements lightly.

Yep - fair enough. Was simlpy making the point that carriers do spend a lot of time looking at things like this, and do not make these decisions/requirements lightly.

Point taken. ;)

Point taken. ;)

BREW 3.0 does have a mechanism for allowing apps to choose whether to display the annunciator bar. This preference may either be encoded into the app's MIF, or set on the fly with IDISPLAY_SetPrefs(). Currently, OEM support of this feature is optional.

BREW 3.0 does have a mechanism for allowing apps to choose whether to display the annunciator bar. This preference may either be encoded into the app's MIF, or set on the fly with IDISPLAY_SetPrefs(). Currently, OEM support of this feature is optional.

Good to hear that there is at least the notion, but since Qualcomm decided to make it optional once again, you know it's going to be completely screwed up and unusable.
What Brew needs is more consistency and a clearly outlined behavior, combined with a stringent OEM quality control to make sure these features are properly implemented. As long as OEMs can get by with all the firmware bugs, and without fixing them even when they are discovered, all these features aren't worth the paper they've been written on.
I still try to figure out how EVERYONE involved could overlook that vibration bug on all the Audiovox phones. "Oh, yes, it vibrates. Cool, we're done!" ... yes, but didn't anyone notice that it never stops and that you actually have to remove the battery from the phone to get it to stop?

Good to hear that there is at least the notion, but since Qualcomm decided to make it optional once again, you know it's going to be completely screwed up and unusable.
What Brew needs is more consistency and a clearly outlined behavior, combined with a stringent OEM quality control to make sure these features are properly implemented. As long as OEMs can get by with all the firmware bugs, and without fixing them even when they are discovered, all these features aren't worth the paper they've been written on.
I still try to figure out how EVERYONE involved could overlook that vibration bug on all the Audiovox phones. "Oh, yes, it vibrates. Cool, we're done!" ... yes, but didn't anyone notice that it never stops and that you actually have to remove the battery from the phone to get it to stop?

Happens on some of the LG's too
I like the new one of the user pressing ### and switching on debug weight causing problems :)

Happens on some of the LG's too
I like the new one of the user pressing ### and switching on debug weight causing problems :)

Shouldn't happen on non-test enabled phones...

Shouldn't happen on non-test enabled phones...

yep i know that, but still it slips through as a bug now and again :)
its especially difficult for testers to button mash on test enabled phones, but since you can test on a non test enabled phones its catch-22
maybe a future option is to disable the debug shortcuts in the menus on TE phones, pressing ### isn't all that unlikely, it happens in a lot of our games.

yep i know that, but still it slips through as a bug now and again :)
its especially difficult for testers to button mash on test enabled phones, but since you can test on a non test enabled phones its catch-22
maybe a future option is to disable the debug shortcuts in the menus on TE phones, pressing ### isn't all that unlikely, it happens in a lot of our games.

This has been addressed in BREW 3.1. It very very unlikely that these debug modes can be accidently activated, since you need to turn on debug mode with ###BREWDEBUG# before any of the individual debug functions may be activated.
Specifically, you need to enter ###BREWDEBUGx, where x is the key that you want to use to activate other debug modes. So if x is #, as above, then you activate a specific debug function with ###n#, where n is an integer specifying the function.
The debug weight mode is now ###10#.

This has been addressed in BREW 3.1. It very very unlikely that these debug modes can be accidently activated, since you need to turn on debug mode with ###BREWDEBUG# before any of the individual debug functions may be activated.
Specifically, you need to enter ###BREWDEBUGx, where x is the key that you want to use to activate other debug modes. So if x is #, as above, then you activate a specific debug function with ###n#, where n is an integer specifying the function.
The debug weight mode is now ###10#.

thats cool, not quite as simple as a menu option but certainly quite useable.
i wonder how long it'll be before i get debug report on some game that uses exactly that sequence :)

thats cool, not quite as simple as a menu option but certainly quite useable.
i wonder how long it'll be before i get debug report on some game that uses exactly that sequence :)

mohlendo wrote:Shouldn't happen on non-test enabled phones...Is this true? I seem to remember turning on debug mode on a friend's phone before, and that phone was not test-enabled.
An app on the Audiovox CDM-8940 (BREW 2.1) will crash when displaying text while Debug Weight mode is on. Does this mean that NSTL will pass apps that crash after a "####"?
--t

mohlendo wrote:Shouldn't happen on non-test enabled phones...Is this true? I seem to remember turning on debug mode on a friend's phone before, and that phone was not test-enabled.
An app on the Audiovox CDM-8940 (BREW 2.1) will crash when displaying text while Debug Weight mode is on. Does this mean that NSTL will pass apps that crash after a "####"?
--t

http://brewforums.qualcomm.com/showthread.php?t=5967
It's only an issue on 2.0 phones.

http://brewforums.qualcomm.com/showthread.php?t=5967
It's only an issue on 2.0 phones.

Hi Max,
but Tom mentioned that CDM8940 which is a BREW 2.1 phone has the same issue, could you please confirm this?
Thanks!
Jean

Hi Max,
but Tom mentioned that CDM8940 which is a BREW 2.1 phone has the same issue, could you please confirm this?
Thanks!
Jean

Yes, the FAQ explains how different BREW versions implement debug sequences.

Yes, the FAQ explains how different BREW versions implement debug sequences.

The idea that BREW doesn't offer developers the option to go full screen is absurd and infuriating. Is there even a way to tell how large the status bar is? What a massive inconvenience both for the developer and end user that directly and negatively impacts the quality of all BREW applications. On such small screens, every pixel counts. Please make this feature standard as soon as possible.

The idea that BREW doesn't offer developers the option to go full screen is absurd and infuriating. Is there even a way to tell how large the status bar is? What a massive inconvenience both for the developer and end user that directly and negatively impacts the quality of all BREW applications. On such small screens, every pixel counts. Please make this feature standard as soon as possible.

actually brew does allow it, its the carriers or OEMs that disallow it.
You can get the height of the bar via the device info ( mostly ) and its in the docs, but its not always correct and some time it returns full screen size instead, so best to generate your own db.

actually brew does allow it, its the carriers or OEMs that disallow it.
You can get the height of the bar via the device info ( mostly ) and its in the docs, but its not always correct and some time it returns full screen size instead, so best to generate your own db.

Wow, old thread. Like Charlie says, you can turn off the annunciators in BREW 3.1+ through BREW either by setting the display prefs in the MIF or calling IDISPLAY_SetPrefs() (requires declaring a dependency on AEEPRIVID_DISPSETTINGS). Unfortunately, many carriers require that the annunciator bar always be displayed, so this trumps what BREW allows you to do.

Wow, old thread. Like Charlie says, you can turn off the annunciators in BREW 3.1+ through BREW either by setting the display prefs in the MIF or calling IDISPLAY_SetPrefs() (requires declaring a dependency on AEEPRIVID_DISPSETTINGS). Unfortunately, many carriers require that the annunciator bar always be displayed, so this trumps what BREW allows you to do.

Wasn't the question whether an app can go full-screen? Isn't that supported on some handsets through a MIF flag or IDISPLAY_SetPrefs call of some sorts?

Wasn't the question whether an app can go full-screen? Isn't that supported on some handsets through a MIF flag or IDISPLAY_SetPrefs call of some sorts?

1. turn on/off annunciator
You can call API IDISPLAY_SetPrefs.
2. modify annunciator height
The height of annunciator defined by a macro BREW_OFFSET_Y, you can modify it as what you want.
Notice: this macro defined both in OEMFeatures.h and OEMCommondisp.h. You need to modify them all.

1. turn on/off annunciator
You can call API IDISPLAY_SetPrefs.
2. modify annunciator height
The height of annunciator defined by a macro BREW_OFFSET_Y, you can modify it as what you want.
Notice: this macro defined both in OEMFeatures.h and OEMCommondisp.h. You need to modify them all.

Hi,
can any one let me know how can I set this privilege?
I tried going through all tabs settings of MIF but dont know how to set this provilege/dependency.

Hi,
can any one let me know how can I set this privilege?
I tried going through all tabs settings of MIF but dont know how to set this provilege/dependency.

You need to add the AEEPRIVID_DISPSETTINGS privilege in the MIF file in order to use the IDISPLAY_SetPrefs.

You need to add the AEEPRIVID_DISPSETTINGS privilege in the MIF file in order to use the IDISPLAY_SetPrefs.