[Galaxy S II Original Android Development] pay.c:
Some suggestions for Siyah

Hey gokhan!

Hope you will read this post, as I am gonna summarize some suggestions, which would enhance Siyah by some practical functions imho.

1) Increase number of light sensor reading levels

I already posted this once - but at that time it was in the middle of bricked-devices-heat and therefore (totally understandable) has not been noticed. See post #5225.

The light sensor of the SGS2 is actually pretty good and not used up to it's full potential at all (nicely seen if you input *#0589# into you phone - the raw values of the sensor are shown then). Instead only four values are used in Siyah & stock ROM right now (see Kernel source: drivers\sensor\cm3663.c) - it's the known 15/150/1500/15000 levels.

Actualy it would be very easy to stock up, it seems: Adding some values in adc_table (e.g. 8 or whatever) in cm3663.c, that seems to be all that is needed. (According to the code at least) E.g. 10/20/50/100 etc.

That would be great for apps such as "Lux Auto Brightness" or CM9 light levels adjustment and stop the rather big (and somewhat blinding) jumping in display brightness levels.

2) Make Hit-home-button-four-times just a little bit configurable

The idea of hitting the home button four times is just f***ing great! Love it!!! But instead of inverse display mode, it would also be really really helpful if one could activate mdNIe Outdoor mode - imagine: Coming outside -> hitting home button four times and at last see something clearly! Maybe make it configurable in ExTweaks (either inverse mode or outdoor mode)? Would just LOVE it!

3) Discussion on CPU levels in general

That's not really a suggestion, but some discussion (sorry for that - if not interested pls ignore):

I am a little bit confused about the CPU rate levels in general: E.g. standard 200/500/800/1000/1200/1400. Let's take the conservative governor as (easiest-to-explain) example: All the governors more or less have a percentual CPU-load-threshold for ramp-up - e.g. 75% (AS EXAMPLE). If some process has exactly 100% cpu load on 200 MHz the governor will ramp up to 500 MHz - resulting in ~ 40% CPU load after that - everything super-ok. But the same situation (exactly 100% CPU load) on 1000 MHz results in 83% CPU load after ramp up to 1200 MHz - so actually it would have been better to ramp to 1400 MHz right away.

The "problem" I want to point at is, that the percentual levels of CPU rate increase are totally not according the *constant* CPU-load-thresholds of typical governors. Wouldn't it be much better if CPU rate increase would also be constant in terms of percentual rise? E.g. (!approximately!) 50% rise per CPU-rate step could end up in: 200 - 300 - 500 - 800 - 1200. That way, all ramp-ups would result in exactly the same CPU-load after ramp up - thus governors should work more consistent.

btw: Just a question: To what voltage do you switch with 300/400 MHz CPU rates? (Can't find the according .c in Kernel source to be honest) I am asking because of the stock-Samsung behaviour: In stock-Samsung kernel, a ramp up to 500 MHz causes the CPU voltage going to the level of 800 MHz. Just at a ramp-down to 500 MHz the actual 500 MHz voltage is used. Seems to be some kind of stabilizing algorithm.

SORRY for this monster post. I hope you'll find the suggestions interesting. Thanks a lot for all your work!

DONATE PEOPLE - DONATE!!! :D And (the f***) get the paid version of ExTweaks! ;)