Broken BREW API call on latest E815 firmware | developer.brewmp.com Broken BREW API call on latest E815 firmware | developer.brewmp.com

Developer

Broken BREW API call on latest E815 firmware

Hello,

Just thought I should share this.

We had a game that was live on the E815 and no issues were found during testing, but a recent firmware update has had severe side effects.

It turns out that the BREW API call: IBITMAP_NativeToRGB(IBitmap *pIBitmap, NativeColor clr) does not work properly. It returns strange values. It is not hard to debug, (try placing 1 bit in various positions and see where it gets mapped to with this API call).

I would check any apps you have that are LIVE to make sure they are displaying properly on the E815 (unless your sure they don't use this call).

This is kinda sad because any game that went through the extra effort of trying to stay device independent (using this call) would become broken with the latest firmware, while apps that hardcoded the 18bit conversion would be fine.

I guess this goes to show you once again..... THE LESS API CALLS YOUR APPLICATION USES THE SAFER IT IS!!!!

Has anyone heard about an update to this? Does this leave us now checking the firmware version and hardcoding values based on it? Terrific. Like you said, so glad we made it 'platform independent'.
Is it possible to roll back your firmware, or maybe have a store do it for you? We had purchased this phone as our demo phone and hadn't specifically targetted it yet so I am somewhat loath to change our code just for this. I am sure we will support it in the end though....

Has anyone heard about an update to this? Does this leave us now checking the firmware version and hardcoding values based on it? Terrific. Like you said, so glad we made it 'platform independent'.
Is it possible to roll back your firmware, or maybe have a store do it for you? We had purchased this phone as our demo phone and hadn't specifically targetted it yet so I am somewhat loath to change our code just for this. I am sure we will support it in the end though....

Hey,
Motorola knows of the issue so maybe it will be fixed in a future firmware upgrade.
This is not a big problem though. You just need to compile a unique version for the E815 where you use your own function instead the BREW one. I actually just used preprocessor commands to redefine the BREW function to my own macro which was 1 line of code.

Hey,
Motorola knows of the issue so maybe it will be fixed in a future firmware upgrade.
This is not a big problem though. You just need to compile a unique version for the E815 where you use your own function instead the BREW one. I actually just used preprocessor commands to redefine the BREW function to my own macro which was 1 line of code.

Michael,
We are doing something similar. However, I was a little surprised at the actual results of the color mapping. I used a V710 to print out the results of the RGBtoNative result (also 18bit color) and then did the same on the E815. Strangely, I got the exact same result. From the output on the screen and your post, I expected to see different numbers there. What is the correct color mapping transform for the E815?
Further, I have noticed that the FillRect routine appears consistent with what I expect out of 18-bit RGB color, but the DrawText does not... Why would these produce different results with the same input?
Thanks for posting this, its always nice to hear that someone else has found an issue and you aren't just smoking something.... :)

Michael,
We are doing something similar. However, I was a little surprised at the actual results of the color mapping. I used a V710 to print out the results of the RGBtoNative result (also 18bit color) and then did the same on the E815. Strangely, I got the exact same result. From the output on the screen and your post, I expected to see different numbers there. What is the correct color mapping transform for the E815?
Further, I have noticed that the FillRect routine appears consistent with what I expect out of 18-bit RGB color, but the DrawText does not... Why would these produce different results with the same input?
Thanks for posting this, its always nice to hear that someone else has found an issue and you aren't just smoking something.... :)

The native calls that we use are IFONT_DrawText and IBITMAP_FillRect, along with IBITMAP_RGBtoNative.

The native calls that we use are IFONT_DrawText and IBITMAP_FillRect, along with IBITMAP_RGBtoNative.

On further investigation, it appears as if the E815 can only draw gray scale font colors and backgrounds. Has anyone else seen this behavior? I use the same exact color value as my FillRect, but I get various levels of gray.

On further investigation, it appears as if the E815 can only draw gray scale font colors and backgrounds. Has anyone else seen this behavior? I use the same exact color value as my FillRect, but I get various levels of gray.

Hey,
So here is what we use:
#define IBITMAP_RGBToNative(p, c) BGRA2NATIVE(c)
#define IBITMAP_NativeToRGB(p, c) NATIVE2BGRA(c)
where for 18bit color we have the following defines
#define BGRA2NATIVE(c) (((c>>27) & 0x001f) | ((c>>13) & 0x07e0) | (c & 0xf800))
#define NATIVE2BGRA(c) (((c&0x001f) << 27) | ((c&0x07e0) << 13) | (c & 0xf800))
I find it curious that you did not notice any difference between these functions on the V710 and the E815. That is the first thing I did. I however, did notice a difference. Actually, just looking at the E815 output BY ITSELF shows how its messed up. I don't remember what the output was but I remember it being very obvious that it was wrong.
The way I came up with the transform is by looking at the way the V710 did it. Let's put it this way, it works, it passed NSTL, and its LIVE and working on the handset.
I don't know about the other API calls. Our games try to stay away from as many API calls as possible to avoid issues just like this. The game that had this problem was the only one we have that tried to do things properly by using this API call and what did we get for it? This wonderful problem. So we only use API calls only when there is no other option.
Let me know if you want more info on this I can find my email to Motorola describing the problem in detail and how to reproduce it.

Hey,
So here is what we use:
#define IBITMAP_RGBToNative(p, c) BGRA2NATIVE(c)
#define IBITMAP_NativeToRGB(p, c) NATIVE2BGRA(c)
where for 18bit color we have the following defines
#define BGRA2NATIVE(c) (((c>>27) & 0x001f) | ((c>>13) & 0x07e0) | (c & 0xf800))
#define NATIVE2BGRA(c) (((c&0x001f) << 27) | ((c&0x07e0) << 13) | (c & 0xf800))
I find it curious that you did not notice any difference between these functions on the V710 and the E815. That is the first thing I did. I however, did notice a difference. Actually, just looking at the E815 output BY ITSELF shows how its messed up. I don't remember what the output was but I remember it being very obvious that it was wrong.
The way I came up with the transform is by looking at the way the V710 did it. Let's put it this way, it works, it passed NSTL, and its LIVE and working on the handset.
I don't know about the other API calls. Our games try to stay away from as many API calls as possible to avoid issues just like this. The game that had this problem was the only one we have that tried to do things properly by using this API call and what did we get for it? This wonderful problem. So we only use API calls only when there is no other option.
Let me know if you want more info on this I can find my email to Motorola describing the problem in detail and how to reproduce it.

It is strange and definitely due to a firmware revision I am sure. Our E815 showed the exact same results as our V710. Do you know what firmware revision your E815 has? You mentioned previous versions did not have the problem, do you know those version numbers? I only have one E815 in house...
What we did find was that IFONT_DrawText was not able to draw color, only gray scale. Again, one of the only native calls we use, and it bites us. Time to drop in the custom font renderer....
Bottom line, the best way to ensure handset portability, avoid the API. Sad, but true. Thanks again for your post.

It is strange and definitely due to a firmware revision I am sure. Our E815 showed the exact same results as our V710. Do you know what firmware revision your E815 has? You mentioned previous versions did not have the problem, do you know those version numbers? I only have one E815 in house...
What we did find was that IFONT_DrawText was not able to draw color, only gray scale. Again, one of the only native calls we use, and it bites us. Time to drop in the custom font renderer....
Bottom line, the best way to ensure handset portability, avoid the API. Sad, but true. Thanks again for your post.

Hey,
Unfortunatly I do not remember the firmwares that this did NOT occur on. However, I checked our current E815 and it still has this issue. The firmware it DOES occur on is "8720_01.17.03". I do not know however what firmware this STARTED happening on.
Botton line is there are commerical firmware out for the E815 that have this issue so even if a future update fixes the issue there might be lots of customers that have the older firmware.
Let me know if you need anything else. There should be a section on Broken BREW API calls since it seems this happens a lot.

Hey,
Unfortunatly I do not remember the firmwares that this did NOT occur on. However, I checked our current E815 and it still has this issue. The firmware it DOES occur on is "8720_01.17.03". I do not know however what firmware this STARTED happening on.
Botton line is there are commerical firmware out for the E815 that have this issue so even if a future update fixes the issue there might be lots of customers that have the older firmware.
Let me know if you need anything else. There should be a section on Broken BREW API calls since it seems this happens a lot.

Seems like I've been caught by this bug on the E815 (so Brew 2.1). When I display in Brew Font 11 or SYSB font, I get color text. When I use the 11B font, I only get black or white, but strangely, the underline option is in the color requested. It does work in shades of grey, however.
Someone mentioned using your own font library. Is there a commercial off the shelf product or an open source library providing Brew fonts? I can't bump our production schedule to build this in-house.
Maybe someone attending the Brew conference saw a vendor with some fonts?
Thanks,
Andy
PS: We are trying (desperately) to maintain one code base/build for every ARM phone. I'm going to look for a way to detect E815 at runtime and kill the color for this option, any advice would be great. Thanks, -ap.

Seems like I've been caught by this bug on the E815 (so Brew 2.1). When I display in Brew Font 11 or SYSB font, I get color text. When I use the 11B font, I only get black or white, but strangely, the underline option is in the color requested. It does work in shades of grey, however.
Someone mentioned using your own font library. Is there a commercial off the shelf product or an open source library providing Brew fonts? I can't bump our production schedule to build this in-house.
Maybe someone attending the Brew conference saw a vendor with some fonts?
Thanks,
Andy
PS: We are trying (desperately) to maintain one code base/build for every ARM phone. I'm going to look for a way to detect E815 at runtime and kill the color for this option, any advice would be great. Thanks, -ap.

That is a 'known issue' on the E815. For some reason, some of the fonts will only do grayscale.
Our applications utilize the PID to determine if it is an E815 and then adjust the color of font blitting to be black and white accordingly. It means the application looks a little different than on other platforms, but its the fastest solution by far.
There are external font renderers, but that is way more involved than changing the color based on the PID.

That is a 'known issue' on the E815. For some reason, some of the fonts will only do grayscale.
Our applications utilize the PID to determine if it is an E815 and then adjust the color of font blitting to be black and white accordingly. It means the application looks a little different than on other platforms, but its the fastest solution by far.
There are external font renderers, but that is way more involved than changing the color based on the PID.

I am assuming you mean "DeviceInfo.dwPlatformID". Thanks.
And, I remembered to ZEROAT the struct and set its size before calling.
Since I've got to do the "set color to grey" piece, I decided to build an abstraction layer that grabs the PID and locates an associated bitfield (index by PID) in an external file. The bitfield then sits in my root structure. If I encounter any other "special" handsets, I can use another bit from the bitfield to trigger the alternate behavior. Sure, I'll need to reprogram the phone software for each new alternate/bit, but any new handset(s) that happen to share the same problem will be added to the data file rather than the code. May be overkill, but it just feels better doing it this way.
Cheers,
Andy

I am assuming you mean "DeviceInfo.dwPlatformID". Thanks.
And, I remembered to ZEROAT the struct and set its size before calling.
Since I've got to do the "set color to grey" piece, I decided to build an abstraction layer that grabs the PID and locates an associated bitfield (index by PID) in an external file. The bitfield then sits in my root structure. If I encounter any other "special" handsets, I can use another bit from the bitfield to trigger the alternate behavior. Sure, I'll need to reprogram the phone software for each new alternate/bit, but any new handset(s) that happen to share the same problem will be added to the data file rather than the code. May be overkill, but it just feels better doing it this way.
Cheers,
Andy