Related
okay, so apparently SCEF02 FW users r stuck with video recording fps drop when recording in low light conditions (and no official solution from samsung yet)
more about the problem here:
http://forum.xda-developers.com/showthread.php?t=1443658
the only FW that seems to fix the problem is the SIEG03, which indicates that the problem is software related and CAN be fixed
however it disables flash in video recording mode & LED torch
so can't the devs figure a way to edit SIEG03 firmware to give us flash support?
links that may help (thanks bartekaki for providing it):
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
personally, I'll pay 10$ if it happens (or more if necessary)
who else???
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
suzaku said:
https://github.com/GalaxySII/samsung...a/video/m5mo.c
Click to expand...
Click to collapse
Dude, you can't even copy/paste links from others's posts...
I'll chip another 10$.
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
bartekaki said:
you copied the link from my post wrong way and it doesn't work:
correct is:
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
Click to expand...
Click to collapse
thx man
radkor said:
Dude, you can't even copy/paste links from others's posts...
Click to expand...
Click to collapse
I thought that since I linked to the original whole thread then it's ok...sorry I'll fix it
karendar said:
As much as I love the idea, I think having the source for the phone SIEGE03 comes from also might help. Because the hooks for flash would have to be cross referenced and switched over to properly work (If it is that simple.)
Click to expand...
Click to collapse
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
suzaku said:
this FW came from the I997 (infuse 4G), and this phone already has flash so I think it's possible
what do u mean by source? sorry I'm a newb
Click to expand...
Click to collapse
SIEGE03 is a firmware. This firmware is required to run the camera... To access the camera functions, we need a driver. This driver is compiled from source code which is what the link above is...
What probably happened here is that the Infuse uses the same camera module and interface. The flash though might use a different register or address scheme in the source code of the Galaxy S2 to interface with the firmware. So someone would have to figure out the difference between the m5mo.c source code from the Galaxy S2 and the I997 to see if it can be fixed through driver. Otherwise we'd have to reverse engineer the firmware which is too much energy wasted.
The problem with this method is that we'll need to compile a new version of the camera driver. And that, I am not the person to do it.
Another solution would be to pull the camera driver from a stock I997's ROM and overwrite it on our phone to see if it works.
I got a galaxy s2 here last friday (coming from a htc desire), and this week i got around to using the camcorder function. Immediately noticed the stutter issue, checked the forums and the current firmware situation, and switched out my SCEF02 for the SIEG01. Of course it fixed the stutter but broke the flashlight, so i spent an evening looking into fixing it. Here's how far i got...
The firmware binary
First of all the SIEG01 firmware binary itself. I did a hex compare with SCEF02 and there are so many differences (hundreds when set to 16 byte difference comparison) it'd be almost impossible to find the incorrect memory address for the flashlight function control (at least in my limited ability).
Next up i tried looking for seperate sections within the firmware to frankenstein a fix. There was only one certain boundary i found with an identical address, that's around the 166FF area, where both files are padded with FF's to the same position (following is ASCII denoting the firmware version). That's a pretty clear indicator that it's a seperate part of the rom, so, i switched out the bottom half of SCEF02 into SIEG01. The result was no stutters, no flashlight. Likewise replacing the bottom half of SCEF02 with that of SIEG01 resulted in stutters and a working flashlight.
So in short, regarding the firmware itself, the section controlling the flashlight function is somewhere before 166FF in the binary. Everything in that first half of the firmware is reasonably similar between the two firmwares, but not identical. Mostly it's single byte changes (probably just the same variables stored in different addresses), and most of the similar sections are offset by roughly a word of data or more. I didn't spend hours looking through to discover where the extra words of data crept in though.
The driver
You could spend weeks tinkering with values within the first 1300KB of the binary trying to find the flashlight section alone, never mind the specific variable/register for the flashlight mode itself, so i moved on to checking the right values were being set by the driver (m5m0.c).
https://github.com/GalaxySII/samsun...-i9100-gingerbread/drivers/media/video/m5mo.c
the relevant function appears to be m5mo_set_flash on line 858, and the function works pretty simply. First there's a case switch to set the values of two variables called flash and light which will be sent to the firmware. The final case is the one for the flashlight function, and needs flash to be -1 and light to 0x03:
Code:
case FLASH_MODE_TORCH:
light = 0x03;
flash = -1;
break;
If flash is less than 1 then no control command is sent to the firmware for the flash, so we can disregard that (i think). That just leaves the light function. i'll just quote the code here:
Code:
m5mo_writeb(sd, M5MO_CATEGORY_CAPPARM,
M5MO_CAPPARM_LIGHT_CTRL, light);
m5mo_writeb is the function sending (writing) the command to the firmware, sd i believe is the device itself, M5MO_CATEGORY_CAPPARM and M5MO_CAPPARM_LIGHT_CTRL are describing where to send the value of light to, on the device. I think it's safe to say M5MO_CATEGORY_CAPPARM is correct since the flash works fine and the same constant is used for the flash control code directly below the light code. It's also used for a bunch of other functions such as capture size etc.
In C code, variables that're defined in all uppercase are usually constants, so you need to go into m5m0.h to find the value for M5MO_CAPPARM_LIGHT_CTRL. line 272 will show you "#define M5MO_CAPPARM_LIGHT_CTRL 0x40". For the sake of being sure, line 180 also has "#define M5MO_CATEGORY_CAPPARM 0x0B".
Time to check out the Infuse source code and compare...
https://github.com/Entropy512/linux_kernel_sgh-i997r/tree/master/drivers/media/video
first of all m5m0.c, line 1411 you'll find m5m0_set_flash. The layout of the function is slightly different, it's still a switch case, but instead of using temporary variables to hold the values to send the flash and light, the values are just sent within the cases themselves. Anyhow, the light control section:
Code:
case FLASH_MODE_TORCH:
err = m5mo_writeb(client, M5MO_CATEGORY_CAPPARM, M5MO_CAPPARM_LIGHT_CTRL, 0x03);
CHECK_ERR(err);
break;
Again no command is sent to the flash, only the torch, and that value is 0x03 again. The same function and arguments are being sent as with the i9100 code earlier, so all that's left is to check the constants being used. Time to hop to m5mo.h for the infuse.
Line 183 "#define M5MO_CATEGORY_CAPPARM 0x0B" matches our i9100 driver. Line 282 "#define M5MO_CAPPARM_LIGHT_CTRL 0x40" matches our i9100.
Now there are some differences between the m5m0_set_flash functions and also in the m5m0_writeb functions for the two devices, but the values they're using to control the light are the same in both cases.
One thing of interest is that the infuse doesn't support autoflash which is light 0x04 and flash -1. However if you hook up the phone to your pc, run ADB and use the camcorder in low light or any flashlight apps, you can use dmesg to verify 0x03 is being sent, as the dmesg output will contain "m5m0_set_flash: E, value 0x03".
Essentially i think this rules out it being a driver issue. I mean i could be wrong, but it looks like the flashlight control values are identical for both devices. It seems like the issue is within the first section of the firmware binary, somewhere.
Hopefully this is of some use to anyone looking into a fix for the SIEG01 flashlight problem.
Thanks for share your investigation Myshkinbob. Very interesting.
I do believe is an "easy" firmware fix too.
As you did, i compared both firmwares binaries and took the hope for finding the flash part in the code. Without a reference there is too many unknown data for a trial and error. I mean i tried to copy-paste some code differences in the firmwares but no succes.
Since nothing looks broken i will keep trying...
It'd be good to get SGS II simulator on Windows. Without it, it's PITA to load every time APK into phone and reboot it to test one variable lol
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
wish i could help somehow...
Myshkinbob said:
Something occured to me this morning, that might help if people are trying to hex edit the firmware binary to fix the flashlight.
Rather than messing with SIEG01 trying to enable the flashlight, you could get far more success editing SCEF02 to disable the flashlight. How so?
Well it's common sense that it's far easier to break something than to fix it.
Apply that logic to this firmware, it's a lot easier to replace a specific working value with a random wrong value, than it is to replace a specific wrong value with a specific working value.
What i mean is it'll be a lot easier to break the working flashlight in SCEF02 than guess the right value for SIEG01. Once you break SCEF02 you'll know where the flashlight control values are in the firmware, and from there you can attempt to insert them into SIEG01.
By FF'ing out small sections of the SCEF02 firmware prior to the boundary section around the 16000 offset, testing the firmware on the phone, then repeating, you could eventually get to where you break the flashlight for it. I'd suggest working back from the face detection copyright notice at the beginning of that 16000 boundary.
Once you break the flashlight in SCEF02, you've just identified which part of the firmware controls the flashlight.
From there it'd just be a matter of locating that similar section within SIEG01, and further narrowing down the specific values(s) that need correcting.
I'm not saying it'd be guaranteed to work, but it'd be an approach worth trying if people are already attempting random hex edits on the firmware.
I guess the success of it depends on the structure of the binary, whether it's a raw assembly code executable image referencing memory and register addresses, or some sort of packed OS image that is expanded and then runs on the camera chip with it's own driver embedded into it for the flashlight.
Click to expand...
Click to collapse
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
suzaku said:
interesting approach indeed
it'll be a lot easier to break the working flash on SCEF02, problem is, it's gonna take a lot of time since it's based purely on trial and error
Click to expand...
Click to collapse
I'm pretty sure that's how samsung codes anyway, we're just lending them a hand in doing so. haha
how's it going guys? any news?
wish I could help but I'm a complete noob
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
blunted09 said:
just thought id bump the thread to get some attention...
btw, does the firmware actually improve camera quality? for pics that is...
Click to expand...
Click to collapse
Well this firmware really improves the overall quality of the pics but in shooting vids it really shines. Only thing so far missing is flash light during video capturing.
I would have moved to SIEG03 if it had had support of LED
me too, flashlight is a little bit to important for me
Since I'm not allowed to post in the dev forum, I'll just leave this here:
The light sensor code on the HTC vision is out of date. It can only return 10 light levels, which range from 0..1024. I've been told this is apparently a Froyo standard and that modern phones return from 0..10240.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/libsensors/LightSensor.cpp
wtf, can't even link to things as a new user?!?
On line 143, you can see the 10 constants that the light sensor code picks between. They are supposed to be in "Lux", but can anyone with a photography rig confirm this? Looking at this chart,
engineeringtoolbox dot com/light-level-rooms-d_708.html
1024 lux is an overcast day. If that's the maximum it can report, that seems like a particularly ****ty light sensor.
Is the hardware that bad, or is the Cyanogenmod code not taking full advantage?
Once we can figure out what the light sensor readings should be, I'll submit a patch to fix the default Automatic Brightness settings (which right now are totally out of sync with the hardware light levels). See line 40 here.
github dot com/CyanogenMod/android_device_htc_vision/blob/gingerbread/overlay/frameworks/base/core/res/res/values/config.xml
Anyhow, only 9 more posts to go before I can participate in the CM9 dev thread
Definitely submit a CM bug report explaining this. Then when you can post links, post a link to the issue thread and everyone will happily plus 1 it.
Hardware is not that bad - this is a CM problem. I've patched mine so it works properly, also, don't use CM. My recommendation.
Thanks for the encouragement. I've filed a bug here. My etiquette may or may not get a warm reception there, so +1s would be appreciated.
code.google [dot] com/p/cyanogenmod/issues/detail?id=4796
I agree with the comment, you should submit it as a patch on gerrit cm review
code.google.com/p/cyanogenmod/issues/detail?id=4796
Alright, installing git now, let's see if I can use it properly.
I might just submit the easy update to the default config.xml AutoBrightness values. My C++ is pretty crap and I doubt I can tell what's going on with the light sensor code.
That seems like an ugly kludge, but it is an open source project after all...
ERROR - JOKES NOT ALLOWED AS NEW USER
What a pain to sync the entire CM source with my crappy internet connection... the 'repo' script recommended in the Gerrit howto hangs overnight.
Code:
repo init -u git://github.com/CyanogenMod/android.git -b gingerbread
repo sync -j16
Killing and restarting the script seems to start again from scratch, so I'm making no forward progress.
I wonder if there's a way to submit patches to gerrit by way of github or some other remote git hosting service?
While setting up git / repo to submit a change to Gerrit, I learned two things - the G2 / Desire Z has a Capella Microsystems CM3602 Light sensor, and the reason the lux values are screwed up - cyanogen did it!
https://github.com/CyanogenMod/andr...mmit/2b53447ec6b2a3fd3e299428d359b3603db19025
Why, I don't understand. The change reason is "Match lightsensor values to kernel". Anyone know more?
Nice, I saw your gerrit submission here http://review.cyanogenmod.com/#change,12845
I hope it gets some good feedback!
Thanks c00ller, I wish I could have added some explanation to the change submission. It would make it a lot easier for a reviewer to figure out what's going on. The real fix would be to change the Vision's lightsensors values to the standard 10..10240 . But without knowing why cyanogenmod reverted them to 1..1024, there's a lot of potential confusion.
The reason for the change is, like the commit message says:
"Match lightsensor values to kernel"
If you look at the kernel source,
Code:
github.com/CyanogenMod/htc-kernel-msm7x30/blob/android-msm-2.6.35/arch/arm/mach-msm/board-vision.c#L317
you can see that these are exactly those levels:
Code:
static struct microp_function_config microp_lightsensor_function = {
.name = "light_sensor",
.category = MICROP_FUNCTION_LSENSOR,
.levels = { 0x1, 0x3, 0x5, 0x13, 0x1A, 0x45, 0xDB, 0x135, 0x1F2, 0x3FF },
.channel = 3,
.int_pin = 1 << 9,
.golden_adc = 0xC0,
.ls_power = capella_cm3602_power,
};
He probably just forgot to adjust the sensor <-> display level mappings in the config.xml (which is what you did in your patch):
Code:
review.cyanogenmod.com/#change,12845
I tried it and it works fine, and I gave it +1
Aha, thanks for the explanation m0viefreak!
I still don't understand exactly where in the code the hardware sensor outputs should be translated into engineering "lux" units. Libsensors seems like the right place to me (naiive non-programmer).
I'd like to advocate for migrating to the gingerbread light sensor standard, since some cyanogenmod auto brightness functionality assumes its 1..10240 lux light sensor range. For example, the "reset threshold".
Is the kernel code using the obsolete 1..1024 range for reverse-compatibility with froyo?
Thanks for bringing this up. I was actually just wondering if the kb backlight issue on Vision keeps coming up because of incorrect light sensor range.
..although this would seem to suggest that the backlight would be on all the time, rather than never on...anyway
I was going to talk to somebody about this but didn't know who to tell about this issue. The brightness can be right at times but the brightness can be changing every few seconds.
Sent from my HTC Vision using xda premium
Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5
azrash said:
Any update on the submitted Gerrit change?
Sent from my HTC Vision using Tapatalk 2 Beta-5
Click to expand...
Click to collapse
Was wondering the same thing.
Same here.
Would anyone be willing to file a glitch/issue in the CM7 github for me?
Any news on this one?
When the light sensor can work properly, than battery life would also get a boost.
Can someone maybe post a link to a (flashable)file to get the right readings from the light sensor? Or tell me if there's a editable file on the system partition I can manually edit?
While searching deeper into build.prop tweaks, I came across this article. It was originally posted in Jeff Mixon's blog. At the moment the whole site is inaccessible, so it probably is a good idea to have it in full here (thanks to Google cache).
While its focused on ICS, some of the points made are aplicable to GingerBread too.
Examining build.prop tweaks for Android ICS: A comprehensive guide
(from: http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/)
Android devices are great. They can easily be hacked and tweaked to seemingly no end. There’s a lot of great info out there detailing step-by-step instructions on how to perform various enhancements to your particular device. Unfortunately, there is also a fair amount of misinformation being disseminated via forums and blogs that can have a very negative effect on your device. Just because you can change something doesn’t necessarily mean you should. In this guide, I will walk through various common Android build.prop settings and evaluate whether or not you should actually change them on your Android ICS device, MythBusters style.
windowsmgr.max_events_per_sec – BUSTED
As the name implies, this property specifies how quickly the system is allowed to process certain events before throttling occurs. Specifically, this property is used by the InputDispatcher when processing screen touch and movement events. This value will really only come in to play with extremely rapid touch events, such as swiping or scrolling. The default value for this property is 90, and Google explains why:
Code:
// This number equates to the refresh rate * 1.5. The rate should be at least
// equal to the screen refresh rate. We increase the rate by 50% to compensate for
// the discontinuity between the actual rate that events come in at (they do
// not necessarily come in constantly and are not handled synchronously).
// Ideally, we would use Display.getRefreshRate(), but as this does not necessarily
// return a sensible result, we use '60' as our default assumed refresh rate.
result = 90;
Many build.prop tweaks set this value to 300, but it seems this is a bad idea. As Google points out, Android maxes out at 60fps. The default value is already allow for a possible max_events_per_sec of 90. Even if you allow for 300 max_events_per_sec, you’ll only ever see 60 of these events in any given second. Therefore, any value much higher than 90 is unlikely to have any noticeable impact on your experience in general. Additionally, setting this value too high can starve other UI events that need to get processed, viz. touch inputs. You’re not likely to feel like your device is running very smoothly when it is busy processing thousands of scroll events instead of responding immediately to you clicking to try and open a link or an app. There may be some specific scenarios where increasing this value does appear to improve system feedback, but changing this value for all UI events across the board will likely cause more problems than it will solve.
dalvik.vm.heapgrowthlimit and dalvik.vm.heapsize - BUSTED
Android devices are getting buffer every day and along with that, the amount of RAM devices have available has increased significantly. Devices with 1GB of RAM are now common; some are even equipped with 2GB already.
This is one property that has cropped up recently in various build.prop recommendations for ICS. Typical suggested values range from “48m” all the way up to “256m”, likely motivated by the common misconception that more is better. The real purpose of this property is much less obvious than one might initially guess. It is also another one you should probably avoid changing.
In ICS, the dalvik.vm.heapgrowthlimit property takes over as the effective dalvik.vm.heapsize property. Applications will be restricted to the value set by this property by default. Google has this to say about it:
Code:
// The largest size we permit the heap to grow. This value allows
// the user to limit the heap growth below the maximum size. This
// is a work around until we can dynamically set the maximum size.
// This value can range between the starting size and the maximum
// size but should never be set below the current footprint of the
// heap.
An indeed, we can see this enforced in several places in the Heap and HeapSource structures. Including:
Code:
if (overhead + HEAP_MIN_FREE >= hs->maximumSize) {
LOGE_HEAP("No room to create any more heaps "
"(%zd overhead, %zd max)",
overhead, hs->maximumSize);
return false;
}
heap.maximumSize = hs->growthLimit - overhead;
As we see here, the heap’s maximum size is determined by the growthLimit variable on the HeapSource structure. We can also see a check to ensure there is enough total heap space available to begin with before attempting to create the new heap. At first blush, it looks like like growthLimit (dalvik.vm.heapgrowthlimit) is redundant and synonymous with maxiumSize (dalvik.vm.heapsize). It seems that could set the dalvik.vm.heapgrowthlimit to 64M and the dalvik.vm.heapsize to 256M and only the growthLimit value would be used to govern a heap’s maximum size. That’s where this interesting method comes in:
Code:
/*
* Removes any growth limits. Allows the user to allocate up to the
* maximum heap size.
*/
void dvmClearGrowthLimit()
{
...
gHs->growthLimit = gHs->maximumSize;
size_t overhead = oldHeapOverhead(gHs, false);
gHs->heaps[0].maximumSize = gHs->maximumSize - overhead;
gHs->heaps[0].limit = gHs->heaps[0].base + gHs->heaps[0].maximumSize;
...
}
This method effectively removes any limitation set by dalvik.vm.heapgrowthlimit and sets the maximum heap size to the value defined by dalvik.vm.heapsize (or the hard-coded default of 16M). This method is wired up straight to the Dalvik runtime implementation as a native call and we can see it defined here:
Code:
static void Dalvik_dalvik_system_VMRuntime_clearGrowthLimit(const u4* args, JValue* pResult)
{
dvmClearGrowthLimit();
RETURN_VOID();
}
...
const DalvikNativeMethod dvm_dalvik_system_VMRuntime[] = {
...
{ "clearGrowthLimit", "()V",
Dalvik_dalvik_system_VMRuntime_clearGrowthLimit },
...
};
And if we keep chasing this rabbit “up” the rabbit hole, we can see it finally in action here in the ActivityThread Java class:
Code:
if ((data.appInfo.flags&ApplicationInfo.FLAG_LARGE_HEAP) != 0) {
dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
}
This flag is set by a relatively new attribute (API level 11) which you can add to the application element in an Android application’s manifest file.
So what does this all mean? The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
debug.performance.tuning – BUSTED
This property doesn’t appear to exist in the ICS code base. Incidentally, I also don’t see it in Gingerbread (2.3.6). It’s possible this value is specific to only certain custom implementations of Android, such as Cyanogenmod, but as far as I can tell, this one does nothing.
video.accelerate.hw – BUSTED
Again, this one appears to do nothing in ICS.
persist.adb.notify – CONFIRMED
This one disable the USB debugging notification when you have your device connected to a computer. We can see this used here:
Code:
private void updateAdbNotification() {
if (mNotificationManager == null) return;
final int id = com.android.internal.R.string.adb_active_notification_title;
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;
This is a good one to disable (set to “0″) if you want to declutter your notification bar.
persist.sys.purgeable_assets – BUSTED
This one claims to free up memory, however it is nowhere to be found in the Android code base. This one is a patch made to Cyanogenmod 7 to do some Bitmap hackery. It may not even exist in CM9. Unless you are running CM7, or possibly CM9, this property has no effect.
persist.sys.use_dithering – BUSTED
Another Cyanogenmod-specific property. This will have no effect on stock ICS.
dalvik.vm.execution-mode – BUSTED
This property can set the execution mode of the Dalvik VM. The VM can run in three modes: fast, portable, and very likely JIT. It is possible to compile Android without JIT support, but the default is to include it. In general, JIT is the execution mode you are going to want on your device. This is why you will see most build.prop files setting this property to “init:jit”. However, this is unnecessary since the default execution mode is JIT:
Code:
#if defined(WITH_JIT)
gDvm.executionMode = kExecutionModeJit;
#else
...
As I mentioned before, WITH_JIT compiler flag is set by default in ICS, thus there is no need to define this setting in your build.prop. If WITH_JIT flag was set to false, setting the execution mode to JIT would have no effect anyway.
dalvik.vm.dexopt-flags – PLAUSIBLE
This property can set various options that affect how the Dalvik runtime performs optimization and verification. Suggested values range from turning bytecode verification off completely to enabling object registry mapping and precise garbage collection. Setting “v=n” will turn off bytecode verification, which while in all practicality is unlikely to cause any problems directly, it is a severe violation of the whole Java trust and security model.
On the other hand, setting “m=y” will turn on the register map for tracking objects to garbage collect. Incidentally, this also enables “precise” garbage collection, which, as you may have guessed is a slightly more accurate way to track objects for garbage collection. By accurate we mean less likely to falsely identify an object as still in use when in fact it is no longer being used. This would, in theory, be a more efficient mechanism to free up unused objects, and thus increase available memory (RAM).
Enabling precise GC seems like a good idea as long as your device has the muscle to spare, but I can not find enough information to know for sure what the total implication is to using precise GC versus conservative. I suspect it likely a trade-off of more cpu cycles per collection to obtain more free RAM. You will have to decide which one is more important to you based on your device capabilities and personal tolerance levels. This is assuming that the difference will even be perceptible in a real-world environment, which I suspect would be less than profound, if any at all.
ro.media.dec.jpeg.memcap – BUSTED
This property is one of many that promises to make your audio and visual experience better. Unfortunately, not only is it only related to JPEG decompression, it is completely unused in ICS (and Gingerbread for that matter) and has no effect on your device.
At first, it looks kind of promising:
Code:
// Key to lookup the size of memory buffer set in system property
static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
Ok, cool. The property exists at least. However, that’s the only place this is referenced. The KEY_MEM_CAP is never used anywhere. If we look a little closer, we’ll come across this:
Code:
/* Check if the memory cap property is set.
If so, use the memory size for jpeg decode.
*/
static void overwrite_mem_buffer_size(j_decompress_ptr cinfo) {
#ifdef ANDROID_LARGE_MEMORY_DEVICE
cinfo->mem->max_memory_to_use = 30 * 1024 * 1024;
#else
cinfo->mem->max_memory_to_use = 5 * 1024 * 1024;
#endif
}
This looks like exactly where this property should be used, but isn’t. The value is clearly hardcoded here. In fact, if we look up the Skia project source tree on Google code, we can see that the latest version has this variable commented out now with the following comment:
Code:
/* For non-ndk builds we could look at the system's jpeg memory cap and use it
* if it is set. However, for now we will use the NDK compliant hardcoded values
*/
//#include <cutils/properties.h>
//static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
ro.media.enc.hprof.vid.bps – CONFIRMED
This one is generally grouped together as a general “media” enhancement tweak. This particular property controls the “high” bit rate at which videos are encoded using the Android stock camera application. That means if you are using a third party camera app, this setting will have no effect. Let’s take a look at the snippet.
Code:
mVideoBitrate = getInt("ro.media.enc.hprof.vid.bps",
"ro.media.enc.lprof.vid.bps",
360000, 192000);
While the default values may seem very low, these are very unlikely to ever be necessary. When a device manufacturer deploys the production ROM, they will define many properties in a different property file (viz. “system.prop”), which will contain values specific to the hardware. Those values are going to be used instead of the hard coded ones we see here.
For example, if I launch a shell on a Galaxy S3 and run the following command:
Code:
getprop ro.media.enc.hprof.vid.bps
I will get a value back of “12000000″, even though I do not have this property defined in my build.prop. This is because it was defined in the default.prop file by Samsung knowing the capabilities of the device and the camera.
This setting can definitely be useful if these values are important to you, just be sure you’re not setting the value to the same (or worse yet lower!) than what is already defined on your device. While you’re at it, you may want to tweak some of the other values:
Code:
ro.media.enc.hprof.aud.bps
ro.media.enc.hprof.codec.vid
ro.media.enc.hprof.codec.aud
ro.media.enc.hprof.aud.hz
The names are pretty self-explanatory, but you can find out more info about each one with a little bit of Google’ing.
Summary
The build.prop file is a powerful tool for root users to modify the behavior of various aspects of the Android experience. However, there are no secret values here that are going to instantly make your phone run faster, better, smarter, or more efficiently. In fact, if you don’t know what you are doing, you can actually decrease the performance of your device. Over time I will investigate more build.prop properties to determine which ones can actually enhance your Android experience and which ones only create a placebo effect.
Nice But...
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic
krishneelg3 said:
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic
Click to expand...
Click to collapse
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium
It work 200%
If u do it correctly
I increased my GPRS class from 10 to 12
And it work
Tested on mini cm10
if I helped press thanks :thumbup:
ElmirBuljubasic said:
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium
Click to expand...
Click to collapse
Elmir what's a good setting 120? 110?
Sent from my Ascend G300 using Tapatalk 2
ro.HOME_APP_ADJ=0 This line sends the settings app to cache and frees some RAM in addition to blocking the Xperia launcher to not restart when leaving a heavy application.
this line works on GB
sorry for my bad English
Nice copy and paste
Great :thumbup:
Sent from my E15i using xda app-developers app
Most of the big performance boosts we've had lately have come from the Krait optimised Bionic library, and things like Linaro's strict aliasing patches (Linaro's compiler by itself makes nearly no difference, it really isn't the magic bullet a lot of so-called 'devs' are trying to give people the impression it is - my own builds have been done with Linaro's toolchain for a long time and it does nada by itself.)
However, it seems to me from watching the GIT repos of some of the more optimised ROMs appearing lately that developers are playing with various CFlags to try and optimise for this specific platform. As we know, there isn't a specific flag (either mtune or mcpu) for Krait:
Code:
Permissible names are: `arm2', `arm250', `arm3', `arm6', `arm60', `arm600', `arm610', `arm620', `arm7', `arm7m', `arm7d', `arm7dm', `arm7di', `arm7dmi', `arm70', `arm700', `arm700i', `arm710', `arm710c', `arm7100', `arm720', `arm7500', `arm7500fe', `arm7tdmi', `arm7tdmi-s', `arm710t', `arm720t', `arm740t', `strongarm', `strongarm110', `strongarm1100', `strongarm1110', `arm8', `arm810', `arm9', `arm9e', `arm920', `arm920t', `arm922t', `arm946e-s', `arm966e-s', `arm968e-s', `arm926ej-s', `arm940t', `arm9tdmi', `arm10tdmi', `arm1020t', `arm1026ej-s', `arm10e', `arm1020e', `arm1022e', `arm1136j-s', `arm1136jf-s', `mpcore', `mpcorenovfp', `arm1156t2-s', `arm1156t2f-s', `arm1176jz-s', `arm1176jzf-s', `cortex-a5', `cortex-a7', `cortex-a8', `cortex-a9', `cortex-a15', `cortex-r4', `cortex-r4f', `cortex-r5', `cortex-m4', `cortex-m3', `cortex-m1', `cortex-m0', `cortex-m0plus', `marvell-pj4', `xscale', `iwmmxt', `iwmmxt2', `ep9312', `fa526', `fa626', `fa606te', `fa626te', `fmp626', `fa726te'.
Krait supports vfpv4 and neon, so we should be using at least -mfpu=neon-vfpv4 on top of whatever cflags are currently thought best...
Somebody must have a Krait-based system that can run GCC4.6/4.7? - Rather than guessing, can't we take a look at what mtune/mcpu=native throws out on Krait? Or does 'native' not work on ARM?
For example: -march=native on my desktop gives me the following:
Code:
-march=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=corei7-avx
I'd imagine this is all standard corei7-avx stuff, bar the cache sizes, but corei7-avx is pretty specific to a Sandy Bridge/Ivy Bridge-based system, whereas there is nothing specific to Krait.
If we really wanted to push the boat out, we could use acovea to see what the fastest specific flags are (although I guess you'd want to use different source to that acovea ships with as it's probably not too relevant to typical uses of an Android device )
Any thoughts on this matter? Am I just madly obsessed with things that make no difference? I'm going to put together some new AOKP PUB builds today since that's my favourite ROM but it would be interesting to have the insight of somebody who actually knows what they're talking about...
Azurael said:
Somebody must have a Krait-based system that can run GCC4.6/4.7? - Rather than guessing, can't we take a look at what mtune/mcpu=native throws out on Krait? Or does 'native' not work on ARM?
Click to expand...
Click to collapse
I asked the same question to myself.
Even made the toolchain at device (HTC One). (arm-gentoo based)
Tried various gcc, linaro's also.
Just one result: -mtls-dialect=gnu
Hi, there
EAS kernel (mainly Energy Aware Scheduler) was firstly proposed by ARM few years ago and nowadays used more widely in custom ROM, although the OEMs didn't support it. The main obstacle of developing EAS kernel is the busy-cost-data for a specified CPU. Fortunately, Pixel 2 uses the same CPU as our XiaoMi 6 and Google shared the data in AOSP. Developers can directly use it for sagit. But EAS is not just a piece of data, we need drivers to make it work better for us.
The CPU scheduler supported in EAS is the famous /schedutil/ governor. This governor is unique and very different from others that it handles the frequencies based on system load. In our sagit kernel, there are already WALT (Window Assistant) codes left by Codeaurora, which can be used to predict the system load. So far, everything seems ready except of boosting things.
SchedTune was born for that. It creates 5 cgoups for different kinds of tasks, one of which is the /top-app/. Settings for this group will significantly affect the user experience. However, AFAIK, there are still no applications in userspace to control the interface, aka /schedtune.boost/. Its value can be altered from 0 to 100. Kernel developers often hard-coded some values to trigger the boost action. But /top-app/ should not be boosted forever. For example, if you're watching a video or listening some music, boost is not preferred for such sustainable tasks. To solve this issue, Joshuous introduced a mechanism call "Dynamic SchedTune Boost", see Ref. It dynamically set the boost for each cgroup task using slot-based tracking system. It is perfect in itself. But if we go through all boost techniques in the kernel, a giant of coupling system will appear and disturb our mind.
Let me try to sort it out.
In the original kernel released by XiaoMi, there are already a few boosting methods implemented by QCOM. Boosting inerface is created and coorperated with performance daemon in userspace. The first one is /proc/sys/kernel/sched_boost. The value is received from a daemon and afterwards triggers a bunch of tasks in the kernel. Codes for these tasks are deeply embedded in HMP, which for now seems impossible to coexist with EAS. To save this interface, Josh again wrote a stub function to build a connection between this interface and boost in schedtune, but he didn't count the value of sched_boost, which was defined from 0 to 3. The problem here becomes simple that we shall map [0 3 2 1] to [0..100]. Thus, I made an effort to write down a function as follows:
C:
return data > 0 ? (4 - data) * 33 : 0;
The factor 33 is trivial and can be changed as you wish. I take 5 for conservative boosting. The returned value is then directly written to the interface /schedtune.boost/ for /top-app/. A positive side effect is that the code can naturally switch on/off the boost status.
The second boost is carried out by codes in soc/qcom/msm_performance.c, which set min/max CPU frequencies upon user touch. Do you remember the original idea behind the /interactive/ CPU governor? xD It's a bit annoying to pull-up the min frequencies constantly in background and waste energy. It seems safe to partially disable this boost in the kernel and just reserve the sysfs name.
The last one locates in cpu-boost.c, cooperated with HMP codes to boost CPU based on event notifier. Totally disable this feature.
After reviewing all boost techniques, we know that CPU frequency is no doubt most critical factor of all. I don't know why QCOM implemented so many boosts, even coupled with each other. I know that msm8998 performs very well without them. I build an experimental EAS kernel, driven by a combination of /schedutil/ and /schedtune/. Tested few days in a small community, it is running good with respect to power efficiency.
Kernel Source
Sorry, no prebuilt kernel here, just sharing the idea about EAS and boost.
After reading more resources, I gathered new information on this topic. The schedtune.boost value of "top-app" was controlled by /libperfmgr/ daemon in userspace, which has been used on Google Pixel phones for years. Therefore, optimization in kernel side seems not that neccessary with libperfmgr.
@strongstCommunity Admin may consider deleting this thread. Thank you.
THREAD LOCKED
Requested by OP.
Regards,
shadowstep
Forum Moderator