Find Your Device:
Or Continue to Thread: [INFO] Building the Linux kern…
20th May 2011, 11:55 AM |#39  
OP Sony Mobile Developer
Thanks Meter: 611
Hi all, there are, as you can see below, some things I need to follow up in order to get progress and get you some better answers. But below is what I can say today (with help from James).

@kiz1983 and im_iceman and Giblet-dono
Currently we don’t support SEUS for phones that has been unlocked. I have initiated discussions if we can support that going forward, but there are several things that needs to be investigated before I can give you an answer (e.g. will it affect customer call centers, repair centers, which SW should be used for unlocked phones, how to identify phone model if other things has been modified, are there security concerns for unlocked phones etc). Will get back to you as soon as I have more information. Sorry that I can’t give a better answer at this time.

It is like m3dteam is saying, it is the HW display that is limited to 30Hz. That you see an increase in performance could be because the build you are testing has changed other this as well. For instance I also see that it is running Froyo, which also had some performance improvements. But in general really hard to say what has caused the improvement in the benchmark. FYI, we have seen benchmarks reporting fps above 60fps on a screen that can only do 60Hz thus actually giving an inaccurate results.

@elpapo (turn the led off)
James answer to this:
Changing the values in /sys/class/leds is only a temporary thing. As soon as Android wants to light up the backlight again, it will overwrite the values. Also, a reboot will completely reset all values in /sys/class/leds. The information about how to control the backlight was more intended for people wanting to build custom roms, as this information will tell them how to control the LEDs.
Basically, it works like this:
An Android application says “I have a notification”. This is communicated via Androids internal frameworks into something called liblights, which has a couple of states like “notification”, “charging” etc. liblights then writes into the /sys/class/leds files to light up the appropriate LEDs.
The reason for it being like this is that not every phone has an identical setup when it comes to LEDs. Some might have backlit keys, some might not. Some might have an RGB LED for notifications, some might have a trackball that lights up instead.
In short, liblights allows the OEMs (Such as Sony Ericsson) to translate “notification” into “blink green on the RGB, and light up the keypad backlight”.
However, liblights isn’t a very complicated piece of code, from our understanding custom ROM builders have their own liblights implemented.

Will get back as soon as I get progress on certain topics.

The Following 6 Users Say Thank You to KalleD For This Useful Post: [ View ]