Code Correct? Checking manner mode | developer.brewmp.com Code Correct? Checking manner mode | developer.brewmp.com

Developer

Code Correct? Checking manner mode

Forums:

Hello,

I'm trying to get the manner mode (silent or vibrate or normal) for a brew 3.0 device. But no matter what 3.0 device I try, it seems to return AEE_MANNER_MODE_NORMAL:

Heres the code. There are alot of debug statements in it because I was trying to trace what it was doing. Basically I get the following results: ISHELL_GETDEVICEINFO returns SUCCESS, but mode always contains 0, which is AEE_MANNER_MODE_NORMAL.

==========

uint32 mode = 0;
int size = sizeof(mode);
DBGPRINTF("ATTEMPTING MANNERMODE3 %d", size);
int res = ISHELL_GetDeviceInfoEx(m_pIShell, AEE_DEVICEITEM_MANNER_MODE, &mode, &size);
switch (res)
{
__case SUCCESS:
____DBGPRINTF("GETDEVICEINFO SUCCEEDED");
____switch (mode)
____{
______case AEE_MANNER_MODE_NORMAL:
________DBGPRINTF("MODE IS NORMAL");
________break;
______case AEE_MANNER_MODE_VIBRATE:
________DBGPRINTF("MODE IS VIBRATE");
________break;
______case AEE_MANNER_MODE_SILENT:
________DBGPRINTF("MODE IS SILENT");
________break;
______default:
________DBGPRINTF("MODE SOMETNG ELSE:%d", mode);
________break;
____}
____break;
__case EBADPARM:
____DBGPRINTF("GETDEVINFO FAILED, BADPARAM");
____break;
__case EUNSUPPORTED:
____DBGPRINTF("GETDEVINFO FAILED, NOT SUPPORTED");
____break;
__default:
____DBGPRINTF("GETDEVINFO FAILED, SOMETHING ELSE!");
____break;
// switch

most of these things are oem/device dependant, so if the code does what its supposed to do(and it looks like it does), likely its not implemented correctly on the phone. try a different device.
i haven't tried that api, so it maybe another brew 2/3 difference though.

most of these things are oem/device dependant, so if the code does what its supposed to do(and it looks like it does), likely its not implemented correctly on the phone. try a different device.
i haven't tried that api, so it maybe another brew 2/3 difference though.

Hi oddvark, i'd hit exactly the same problem as you. Code is perfect, function succeeds, value is always 0. Check out this thread.
No one seem to have a solution to this. I got this problem on the LGVX9800. What handset are u testing on?

Hi oddvark, i'd hit exactly the same problem as you. Code is perfect, function succeeds, value is always 0. Check out this thread.
No one seem to have a solution to this. I got this problem on the LGVX9800. What handset are u testing on?

The reason why I think this is odd because it happens on EVERY handset I try it on, so I assume it must be something we are doing wrong.

The reason why I think this is odd because it happens on EVERY handset I try it on, so I assume it must be something we are doing wrong.

sigh... such a simple call. I don't see anything wrong with the code at all. Maybe something is missing in the docs? I mean the BREW API docs sometimes doesn't match up with the actual API at all...
Any BREW tech support wanna shred some light on this?

sigh... such a simple call. I don't see anything wrong with the code at all. Maybe something is missing in the docs? I mean the BREW API docs sometimes doesn't match up with the actual API at all...
Any BREW tech support wanna shred some light on this?

In a lot of ways they are at the mercy of the OEMs to implement it, and given the frenetic nature of the cell phone market, features get dropped, especially stuff like this, its low on the list of things to get done for market.
Silent mode has always been problematic, some phones even ignore it themselves., so when the volume is muted they still play sound, and previously its been impossible to determine what mode its in, best to design around it instead

In a lot of ways they are at the mercy of the OEMs to implement it, and given the frenetic nature of the cell phone market, features get dropped, especially stuff like this, its low on the list of things to get done for market.
Silent mode has always been problematic, some phones even ignore it themselves., so when the volume is muted they still play sound, and previously its been impossible to determine what mode its in, best to design around it instead

charliex wrote:In a lot of ways they are at the mercy of the OEMs to implement it, and given the frenetic nature of the cell phone market, features get dropped, especially stuff like this, its low on the list of things to get done for market.
Silent mode has always been problematic, some phones even ignore it themselves., so when the volume is muted they still play sound, and previously its been impossible to determine what mode its in, best to design around it instead
100% behind you on that. But the least the OEMs can do is NOT TO RETURN SUCCESS value on that function. What were they thinking!$%!!@!@?! :mad:

charliex wrote:In a lot of ways they are at the mercy of the OEMs to implement it, and given the frenetic nature of the cell phone market, features get dropped, especially stuff like this, its low on the list of things to get done for market.
Silent mode has always been problematic, some phones even ignore it themselves., so when the volume is muted they still play sound, and previously its been impossible to determine what mode its in, best to design around it instead
100% behind you on that. But the least the OEMs can do is NOT TO RETURN SUCCESS value on that function. What were they thinking!$%!!@!@?! :mad:

the problem is that the API is succeeding in getting the value, its the value thats not being set correctly, which the api has no way of knowing, its probably just reading out of some internal location/register, i'd imagine that the api only returns a fail when the value doesn't exist or such.
maybe in future a simple GetMasterVolume API call would be nice

the problem is that the API is succeeding in getting the value, its the value thats not being set correctly, which the api has no way of knowing, its probably just reading out of some internal location/register, i'd imagine that the api only returns a fail when the value doesn't exist or such.
maybe in future a simple GetMasterVolume API call would be nice

AEE_DEVICEITEM_MANNER_MODE is not currently tested in our Porting Evaluation Kit, which is a set of tests OEMs run to verify BREW porting. What this means is that it's not going to be a gating factor in device acceptance, so reliability of this method on the device is going to be unlikely.
I've already raised this issue with our PEK development team.
In BREW 4.x there are going to be some fundamental changes to how volumes are handled by BREW (and additional tests to verify that they're actually implemented properly :o ).

AEE_DEVICEITEM_MANNER_MODE is not currently tested in our Porting Evaluation Kit, which is a set of tests OEMs run to verify BREW porting. What this means is that it's not going to be a gating factor in device acceptance, so reliability of this method on the device is going to be unlikely.
I've already raised this issue with our PEK development team.
In BREW 4.x there are going to be some fundamental changes to how volumes are handled by BREW (and additional tests to verify that they're actually implemented properly :o ).

Hi Mohlendo or other Brew moderators,
Is there any list of devices that are known NOT to support the proper response to a "manner mode" inquiry? If so, we can reduce our individual device requests to the BREW forum every time we run into this issue.
Thanks

Hi Mohlendo or other Brew moderators,
Is there any list of devices that are known NOT to support the proper response to a "manner mode" inquiry? If so, we can reduce our individual device requests to the BREW forum every time we run into this issue.
Thanks

I'm not aware of any devices that properly support fetching the manner mode device item.

I'm not aware of any devices that properly support fetching the manner mode device item.

How about setting the manner mode of the device? Is this as inconsistent as getting the manner mode of the device?

How about setting the manner mode of the device? Is this as inconsistent as getting the manner mode of the device?