[Kernel] [26/04] Perseus

Status
Not open for further replies.
Search This thread

psyntific

Senior Member
Aug 20, 2012
502
157
Pune
Re: [Kernel][30/01] Perseus

Guys,for anyone who would like their phone to be a little smoother,I suggest decreasing the utilization timeout in the GPU tab in STweaks to something like 50ms.If it's not placebo,which I seriously doubt,the improvement is quite noticeable,especially in scrolling,which is smooth from the moment I move my finger now.I don't know how it will affect battery life,but I don't think it'll make a dramatic difference...

Sent from my GT-I9300 using xda premium



Yea I think so too
 

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
Guys,for anyone who would like their phone to be a little smoother,I suggest decreasing the utilization timeout in the GPU tab in STweaks to something like 50ms.If it's not placebo,which I seriously doubt,the improvement is quite noticeable,especially in scrolling,which is smooth from the moment I move my finger now.I don't know how it will affect battery life,but I don't think it'll make a dramatic difference...

Sent from my GT-I9300 using xda premium
I've had issues with going that low in games, the Mali power management seems to get confused as the utilization isn't averaged enough over time and the GPU cores constantly switch on and off depending on load since their idle timeout is something like 25ms. Would hear what other people experience with this.
 
  • Like
Reactions: tolis626

rugolt

Senior Member
Dec 11, 2011
71
23
For the 2nd time this week my alarm clock did not work.
I have latest Perseus kernel, it never happened with any previous version.
Kinda bad cause I got late for work ;)
 

Infy_AsiX

Senior Member
Feb 13, 2012
965
389
Brisbane
Re: [Kernel][30/01] Perseus

I've had issues with going that low in games, the Mali power management seems to get confused as the utilization isn't averaged enough over time and the GPU cores constantly switch on and off depending on load since their idle timeout is something like 25ms. Would hear what other people experience with this.

indeed just tested and it seems choppier when lower.

?????? Galaxy S3 ??????
 

habylab

Senior Member
Dec 3, 2010
6,228
1,200
Re: [Kernel][30/01] Perseus

I've had issues with going that low in games, the Mali power management seems to get confused as the utilization isn't averaged enough over time and the GPU cores constantly switch on and off depending on load since their idle timeout is something like 25ms. Would hear what other people experience with this.

Works quite well at 75 for me.

Sent from my Galaxy S3 using Xda Premium. Long live the Galaxy S! :)
 

nfsmw_gr

Senior Member
Dec 25, 2010
3,806
1,954
29
Salamina,Greece
www.facebook.com
I've had issues with going that low in games, the Mali power management seems to get confused as the utilization isn't averaged enough over time and the GPU cores constantly switch on and off depending on load since their idle timeout is something like 25ms. Would hear what other people experience with this.

75ms works great for me!
Didn't try 50ms though,it seemed too low..:silly:
Btw,what is your opinion about linaro optimisations?Is it worth it or not?
 
Last edited:

habylab

Senior Member
Dec 3, 2010
6,228
1,200
Re: [Kernel][30/01] Perseus

75ms works great for me!
Didn't try 50ms though,it seemed too low..:silly:
Btw,what is your opinion about linaro optimisations?Is it worth it or not?

I think, from a user point of view having tried 5+ phones, the linaro chain helps greatly. In particular my Asus Transformer. Scrolling is now super smooth, and opening apps appear quicker.

Andrei, if you're in doubt, talk to Stratosk, maker of Semaphore, he has a lot of experience with Linaro. I'm sure you have an opinion though!

Trying 50 now, seems better actually!

Sent from my Galaxy S3 using Xda Premium. Long live the Galaxy S! :)
 

tolis626

Senior Member
Dec 31, 2009
2,518
598
Amaliada
Re: [Kernel][30/01] Perseus

I've had issues with going that low in games, the Mali power management seems to get confused as the utilization isn't averaged enough over time and the GPU cores constantly switch on and off depending on load since their idle timeout is something like 25ms. Would hear what other people experience with this.

Well,so far so good with 50ms.Games don't show any slowdowns and benchmarks back this up.Maybe it's about your GPU in particular.

Sent from my GT-I9300 using xda premium
 

Philips9

Senior Member
Dec 24, 2011
438
42
R: [Kernel][30/01] Perseus

I guys, is there a .zip to clean all setting of this kernel before flash another kernel (such as bloeffa kernel-clean)??

Sent from my GT-I9300 using xda app-developers app
 

dezeubby

Senior Member
Feb 9, 2011
195
14
I guys, is there a .zip to clean all setting of this kernel before flash another kernel (such as bloeffa kernel-clean)??

Sent from my GT-I9300 using xda app-developers app

I am using that zip (bloeffa kernel-clean) before every kernel install .

Now i am testing Siyah because i can't decide with what kernel to stick ... Siyah , Boeffla or Perseus ... With Perseus i got 1d 18h battery , sometimes 3g , some music , some games etc.
 
  • Like
Reactions: Philips9

sachilleas

Senior Member
Aug 1, 2008
869
186
Re: [Kernel][30/01] Perseus

What changes does Samsung's power saving mode do to the phone? Does it only work with stock kernel?
 

tincmulc

Senior Member
Apr 29, 2009
259
56
Sevnica
What changes does Samsung's power saving mode do to the phone? Does it only work with stock kernel?

Depends on which checkboxes you checked in power save options:
CPU power saving: only changes max frequency of the CPU to 1000MHz, all 4 cores can still come online as needed.
Screen power saving: Changes the refresh rate of the screen from 60 to 40 Hz. Also reduces screen brightness in some conditions.
Background color: Reduces brightness in the stock browser and email app.
Turn off haptic feedback: disables vibration for user interaction (for example button presses).

All these options work in perseus.
 
  • Like
Reactions: sachilleas

sachilleas

Senior Member
Aug 1, 2008
869
186
Re: [Kernel][30/01] Perseus

Depends on which checkboxes you checked in power save options:
CPU power saving: only changes max frequency of the CPU to 1000MHz, all 4 cores can still come online as needed.
Screen power saving: Changes the refresh rate of the screen from 60 to 40 Hz. Also reduces screen brightness in some conditions.
Background color: Reduces brightness in the stock browser and email app.
Turn off haptic feedback: disables vibration for user interaction (for example button presses).

All these options work in perseus.

Thank you for you answer! I only asked because when I have cpu power saving enabled (which means 1000 Mhz max cpu frequency, as you correctly said) stweaks keeps showing that the max cpu frequency is 1400 Mhz... What is wrong?
 

Highlander11

Senior Member
Jul 20, 2009
191
32
Newlands, Pretoria
Re: [Kernel][30/01] Perseus

Well,so far so good with 50ms.Games don't show any slowdowns and benchmarks back this up.Maybe it's about your GPU in particular.

Sent from my GT-I9300 using xda premium

I am also having great results with the value set to 50ms. I have also just installed ARHD v22.2 and the phone's scrolling was not close to smooth, until I changed the setting :D - it is amazing what a difference it has made!

Sent from my GT-I9300 using xda premium
 

habylab

Senior Member
Dec 3, 2010
6,228
1,200
Re: [Kernel][30/01] Perseus

Hope someone can help Andrei.

Sent from my Galaxy S3 using Xda Premium. Long live the Galaxy S! :)
 

carlos67

Senior Member
Oct 29, 2010
1,716
633
Guys,for anyone who would like their phone to be a little smoother,I suggest decreasing the utilization timeout in the GPU tab in STweaks to something like 50ms.If it's not placebo,which I seriously doubt,the improvement is quite noticeable,especially in scrolling,which is smooth from the moment I move my finger now.I don't know how it will affect battery life,but I don't think it'll make a dramatic difference...

Sent from my GT-I9300 using xda premium

Yup, confirmed. I did this 2 weeks ago and it does make a difference to scrolling. Mine set to 50 also.
 
  • Like
Reactions: tolis626

AndreiLux

Senior Member
Jul 9, 2011
3,209
14,598
I think I'll be killing Samsung's mDNIe profiles and have a single master sequence for everything. Any opinions on this? I'm still thinking on the best option into releasing the controls. I now have full proper control on all mDNIe effects in STweaks but still sorting out things.

I'm really in need of a person with some image processing knowledge and especially somebody with a colorimeter so we can calibrate an eventual master profile to the best possible. I'd be sharing the intermediary kernel with the volunteers so sort things out together.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 847
    Welcome to the Perseus kernel! I thought it would be a nice catchname considering the Galaxy/Universe/Pegasus themes.

    I'm trying to be more cutting-edge in terms of development in this kernel. In contrast to other kernels and philosophies of other developers, I don't believe giving the users more choice is a very smart thing to do. As such you won't find a dozen different governors or twenty different settings for this kernel. There is a optimal, or at least, most optimal setting on which the devices operate both in terms of performance and power management. For the average user this kernel will brings lots of benefits to battery life, screen improvement, fluidity and sound enhancements without having to set up any of the configurations.

    The kernel comes with a configuration application called STweaks, and is installed automatically with the kernel. You will find all advanced options in there.

    Don't be scared by the alpha denomination of the kernel, I'm just taking the traditional naming scheme where alpha designates feature development, beta is feature-completeness, and final will actually be when I'll actively stop developing the kernel. The kernel is very stable, and any bugs are fixed in hotfix versions (alpha x.y)

    The kernel is also being maintained and released cross-device for the I9305 (S3 LTE), N7100 (Note 2) and N7105 (Note 2 LTE) and shares the same base-source.

    Features / changelist:

    Perseus alpha36.3 (26/04):
    • Fixed slice lookup issue on ABB: It's recommended you put your slices back to default before flashing if you changed them to borderline stability values. Please upgrade.
    Perseus alpha36 (22/04):
    • Adaptive Body Bias control (ABB). (Experimental feature)

      Body biasing is taking advantage of transistor body effect for binning the chip depending on its quality. In fact, this is used on the latest Samsung SoCs both for reducing power consumption and validating bad chips by adjusting their electrical characteristics.

      The body bias is dictated by the voltage applied to the transistor gate (The usual voltages you're all used to) minus the voltage applied to the transistor body. The resulting bias can change the transistor's electrical characteristics in two possible ways:

      Before reading on: A transistor's voltage and operating frequency is defined/limited mostly on its threshold voltage. Wikipedia has a neat visual representation of this; voltage must raise to a certain point for the transistor to be able to switch and operate. This threshold voltage can be highly dependant on temperature, influenced by the body effect, and defined by the manufacturing process. What we're doing nowdays with undervolting is to get as near as possible to the upper bound of this threshold voltage.

      With that in mind:
      • Forward Body Bias

        A FBB is defined when the bias of the gate voltage minus body voltage is positive, meaning the gate voltage is higher than the body voltage. This has the effect of reducing the threshold voltage. By reducing it, you can achieve lower voltages, or be able to clock the transistor higher. However the side-effect of lowering the threshold voltage is that you are sacrificing power leakage, meaning that the lower the threshold voltage becomes, the higher leakage current in the transistor becomes. This leakage power rises exponentially with a linear lowering of the threshold voltage. This is what is called static transistor leakage.
      • Reverse Body Bias

        A RBB is defined when the bias of gate voltage minus body voltage is negative, meaning the gate voltage is lower than the body voltage. it has the direct opposite effect of FBB, it raises the threshold voltage thus you would need a higher gate voltage for switching, but however you also dramatically decrease static leakage.
      What happens is that you want to use RBB when idling, and a reduced RBB, or even FBB at very high clocks.

      Samsung currently uses this on top of voltage scaling to bin their chips. Here's an excerpt of the stock body biasing on the 4412 Prime chip (I'm using that one as an example as it has better adjusted ABB values over the Rev 1.1 chips).
      ZDOUXP9.png


      To find out your ASV group: You can read out your ASV group in /sys/devices/system/abb/abb_info now.

      I have rewritten the ABB scaling logic/driver for CPU, GPU, MIF and INT voltages.

      In the current implementation, since it would be insane to have paired-up gate-body voltages divides the frequency range in several slices; even Samsung uses only three voltage ranges on the DVFS scale. I divided the frequency ranges as follows:
      • CPU: Divided into four slices, with frequency ranges of 200], 800], 1600] and ]1600 Mhz.
      • GPU: Three slices: 160], 533] and ]533 Mhz.
      • MIF and INT: Both only two slices with the bottom frequencies for each as middle-threshold.

      As mentioned above, controls can be found in /sys/devices/system/abb/ and the entries are self-explanatory. You can also change the frequency slice limits per sysfs, however in STweaks I only included the voltages for each slice only for now.

      Disclaimer
      {
      And that's about it in that regard. I have tried testing things over last couple of weeks, but I haven't come to a solid conclusion yet beyond what's presented by the stock characteristics: It's up to you people to do some advanced testing on the matter. My limited empirical testing in terms of voltages tells me it works as intended, but if a user with advanced measuring equipment would do similar testing to what I did back on the 4210 it would be perfect. }
    • zRAM: Switched over from LZO to Snappy compression algorithm, this provides much faster compression and decompression than the LZO implementation which was in the current kernel. I updated the Snappy libraries to the latest original CSNAPPY implementation, so this is extremely new.
    • Some kernel internal updates to speed up hotplugging and improve I/O latencies.
    • A correctly (Unlike basically every other kernel out there till now) applied load averaging patch regarding fixing a Moiré pattern in the scheduler load calculations which was floating around.
    • Fixed mono and equalizer switches in the sound engine. (Thanks to sorgelig for beating me to it)
    • Fixed led controls to behave correctly with user-space apps.
    • mDNIe digital brightness reduction:

      You can now lower the brightness to basically nothing via this: it uses the mDNIe engine to digitally remove luminance from the RGB channel values, as opposed to reducing brightness via a proper backlight/display driver. The side effect of this is that you lose colour resolution somewhat, but is a practical and working method to reduce the too bright minimum values of our displays.

      You have three configurables:
      • A reduction rate which you want to apply, this is the intensity of the darkening you want to achieve.
      • The take-over point; the backlight driver gets fed brightness values from 0-255 (In reality values below 20 have no effect). The take-over point is the point where the digital brightness reduction starts, on a reverse scale. The reduction is applied linearly from 0, (Full reduction taking place), to the take-over point (Zero reduction). The stock slider doesn't go below 20 in the interface, so practically the full reduction rate is never applied unless you use a third-party brightness controller app, just to keep that in mind, but in practice it doesn't matter.
      • Auto-brightness input-delta: This is needed because the stock framework is retarded in the values it forwards to the kernel, you can adjust this to avoid having brightness reduction when you don't want it on auto-brightness.

        Somebody needs to edit config_autoBrightnessLevels, config_autoBrightnessLcdBacklightValues in framework-res.apk\res\values\arrays.xml to fix this.

        Optionally, if you use a third-party app like Custom Auto Brightness which allows backlight values of down to 0, you can avoid this problem.
      The register hook needs to be enabled to be able to use this function.
    • Increased the maximum brightness by 50 candela: the manual controls were limited to 250cd as maximum as opposed to 300cd which was only usable during auto-brightness, and unusable for any third-party apps.
    • Unaligned memory access throughout the kernel when applicable.
    • Switched over to GCC 4.7.3 Linaro toolchain for compiling.


    Perseus alpha35 (06/04):
    • Further rewrote the in-kernel audio controls:
      • Threw out the old detection methods for something more robust.
      • This particularly enables non-cellular applications such as Skype, Viber, and so on to be detected correctly. A "calling" state now includes any and all use-cases where the audio is outputted via the phone's earpiece. This fixes microphone levels for such apps to correctly use the calling sensitivity value.
      • Added microphone level for camera use, this state is enabled whenever a camera stream is active. It should give more options into adjusting things to your likings.
      • By now the sound engine has only little similarities to Boeffla, any bugs and feedback now go directly to me.
    • Developers only: MHS: Added a new small tool for tracking media use and reporting it to other in-kernel drivers. Capable of detecting video recording, decoding and camera streams for now. See commit for more info.
    • mDNIe control changes:
      • Removed several controls in STweaks simply because people misunderstood them or misused them, or they simply had no rational use.
      • Video detection, now with the help of MHS, is no longer limited to the stock video player. Any video players using hardware decoding will now be able to make use of edge enhancement, HDR and DNR, this includes any web-based players and the YouTube app.
    • Custom LED controls implemented; Exposed most variable controls for the notification LED via sysfs and STweaks (LED tab). :
      • Control LED brightness. Currently the OS dictates, depending on brightness detected by the light-sensor, wether to run the LED in a low-power mode or in a high-power mode, you can now set brightness for both.
      • Blinking control, this is basically the shape of the wave-pattern that the LED blinks in, you have several controls, best described the data-sheet description:
        aGP3lNe.png


        The fade-in time period is TT1 in the graph, while the fade-out period is TT2.
        Slope (1/2/3/4) detention time represents DT1,2,3,4 in the graph, it controls how "steep" the four different curves are.
      • The LED fading checkbox simply switches between having the detention times controlled by the sliders to having them to 0 (Stock blinking behaviour).
    • Increased default zRAM size to 400mB. This won't override your STweaks setting, so only new users will see the new value. Others should please adjust the value manually to your liking.

    Sources:

    https://github.com/AndreiLux/Perseus-S3

    Credit and thanks:

    gokhanmoral, netarchy, and anybody credited in the commits.


    TL;DR: before flashing aside from known issues in the second post.
    • This isn't an AOSP kernel. I won't work with CM and AOSP derivatives.
    • DOESN'T WORK ON SAMSUNG JELLYBEAN 4.2.1 ROMS.
    132
    where is the problem? this world is free of your property? This works are not "original" works but services to users who have freedom of choice. I respect your phenomenal job as you should do with it all, this is the fantastic world called open source. What is your fear? when something is useless not even supposed to get your attention. indifference

    Ot end

    Sent from my iPhone5 Fu**er S3 using The Blackened Kernel
    Please write Italian, I can make more sense of it than your English. Anyway I'm really not in the greatest mood since yesterday and the black crush fix, due to the unbelievable simplicity of the fix, and a certain person (Supercurio) sitting on this fix for months and not releasing it out of pure selfishness and egotism. This post will insult a lot of people and I honestly don't give a crap anymore.

    Offering a service brings with it the promise of the service actually being worth something. Too many so called developers here on XDA are publishing things worth literal ****. There is the argument that this is a forum where developers can learn to achieve something and are "progressing" towards more higher level of sophistication for their work. This argument is valid if you bring along with it the humility needed if you are in such a position.

    There's dozens and hundreds of people out there over-selling their work, SuperCharger script written by a script kiddy with probably the age corresponding his attitude. Useless developers like knzo releasing and false-advertising kernels which don't do ****. Eugene376 or whatever the number, releasing his monumental bullshít lie of CPUSleeper and even asking money for it. We still have people in the ROM forum asking about it and installing it, and even fricking developers including this crap into their ROMs. francisco, simone (Just to take from this forum) with their laughable commits without full understanding what some of those commits encompass. Phenomenal was still a respectable kernel on the S2, because phenomeno was only starting with his development at the time and was humble about it, but now on the S3 it reeks of false promises and excentric hyperbole in the current thread description. I have no respect for such people, and if any of you mentioned here are offended by it, live with it. It is a technical criticism of their products in the technical aspect of what XDA is supposed to be (In my view, but it seems that's declining).

    Am I angry at stupid users falling for snake oil and basically a distorted view of reality, and falling into the, as Gökhan likes to say, iPhone brand royality kind of idiocy? Of course that I am. I'm wasting hours upon hours going through source code to understand what is going on, and then comes people like franco which develops on 10 devices and none of the end product is worth a damn, releases something basically two degrees different than what a stock kernel is, and people are flocking just because of the brand name and believe in some superior magic happening in it. Tell you what, that's not the case.

    The only two persons developing here which a worth a damn in my view, aside from the CM team, are Gökhan and harunjo. The former whose C skills and knowledge are simply beyond 99% of developers here on XDA, including myself, and still has the incredible humility even now, after having the most successful single "product" out here on XDA. The latter because in a few weeks he went from nothing, to actually having more of a clue than some other developers around here. and maybe hardcore, whose work still eludes me to this day, but his "don't give a crap about nonsense" attitude is admirable. The difference is there, in the attitude.

    So I hope you see and understand where the problem is, because it affects the whole ecosystem and developer community if somebody releases crap or false promises. I've been indifferent and quiet it about it for quite some time now, but some bullshít needs to be called for what it is, bullshít.
    106
    Known issues [Updated 02/12]

    • None

    Older changelogs


    Perseus alpha34 (22/03):
    • Updated sound engine. Based on Boeffla (Andip71)sound but custom fork with rewritten system interface and some other code re-factorings.
      • Should fix all FM Radio issues.
      • Brings us saturation prevention for the equalizer.
      • Privacy mode.
      • Microphone level control
      • You now have control over the speaker equalizer via sysfs, please visit /sys/class/misc/wolfson-control/ the controls are self-explanatory.
      • I removed the equalizer pre-sets from STweaks, if you want, set them manually:

        Bass-extreme: 12 8 3 -1 1
        Bass and Treble: 10 7 0 2 5
        Treble: -5 1 0 4 3
        Classic: 0 0 0 -3 -5
        Pleasant for ears: 4 3 2 3 1
        Eargasm: 12 8 4 2 3
      • I recommend HeadphoneAmpControl (thread - Play Store) for controlling the volume directly on a hardware level; it will overwrite the digital volume of the OS and use the hardware amplifiers only.
    • Enabled ZRam by default with disk size of 200mB and swappiness of 90%.

      The ZRam control is found in the I/O Tab in STweaks. Set it to 0 to turn it off completely, any other value to turn swap on. Changing value takes about ~10-20 seconds depending how loaded the disk is with swap pages so don't piss your pants if it doesn't react immediately.
    • Applied a requested patch which allows PCs to be booted off from the phone storage.

    Perseus alpha33.2 (27/02):
    • Master profile is correctly calibrated.

      50kS6iV.png


      Detailed calibration report: Download
      Advanced colour management report: Download

      All thanks goes to Slimer777 for his excellent work.

    Perseus alpha33 (26/02):
    • Revamped and hopefully final version of mDNIe controls:
      • The controls work now on two levels: First we have a master sequence that overrides any and all of Samsung's settings; currently this version is released without calibration, however in the next minor version it will be updated with proper professional screen calibration. See the Note 2 thread to see what to expect here too. The master sequence is calibrated to sRGB norms on a precision level equalling and even surpassing the iPad3/4.

        The master sequence works as as the calibrated base; for people not wanting to bother further with any more controls, you simply enable this and you're done.

        Second part is the register hook, it catches effect values and modifies them by applying delta values available as controls in STweaks and in /sys/class/misc/mdnie/hook_control/.

        Leaving both these options will give you Samsung's default values, plus the black crush fix.

        The register hook, while used on Samsung's profiles, is not capable to alter effects which are not integrated in that screen profile's value sequence, the "Movie" profile for example lacks some effects present in the "Dynamic" profile. The same is valid when having different scenarios, the "Camera" scenario will use different effects in its base than the "UI" scenario. To fully explore all possible effects, use the Master profile as it integrates all effect values known.
      • Each control has a master kill-switch which enables or disables the effect. This varies by profile and scenario, so you have control to only "toggle" the switch, whatever its state may be in.
      • Digital noise reduction - Reduces and flattens out grain. Advanced controls are found in the hook_control folder with the dnr_ prefix.
      • High dynamic range - A HDR effect which brings out details in dark and extremely bright scenes.
      • Digital edge enhancement - An edge enhancement effect. What we previously called "sharpening". Divided in controls for radius, amount and threshold. Read the Wikipedia page for more information. More advanced controls found in the sysfs under the de_ prefix.
      • For the above three effects, scenario consideration is taken into account. You can enable/disable them depending when you want it to be applied. Please be aware only the stock applications trigger the scenarios. I will try to enable at least the video scenario depending on when the hardware decoder is active in the future so that they are enabled also in third-party video players.
      • Chroma saturation control - Same as in previous version but with fixed labels.
      • Colour temperature control - By default this is disabled on all profiles, however, if your screen has a tint to it, this is the first control you should try to fix as it alters temperature on all channels.
      • The SCR controls are colour channel filters working on the Red, Green, Blue, Yellow, Cyan, Magenta, White, and Black channels.
        Imagine the controls as manipulating the corners of the RGB cube:
        G1W6fON.png

        (Credit to Wikipedia for the graphic)

        By controlling the RGB coordinates of each corner/channel we can mould the cube into a different shape. At the same time the cube is projected onto a hexagon; the perimeter of the hexagon represents the colour hue, the radius of the hexagon from the middle represents chroma. We can use the chroma saturation controls to "push in" each corner of the cube, while moulding the corner's directions with the RGB controls. The RGB coordinates can be transformed into the HSL space space if needed, however I didn't include this function yet as I don't feel the need for it.

        STweaks has controls for the RGBYCMW channels, the K (Black) channel I left out because it makes no sense in altering it, but can be found in the sysfs folder.
      • Several controls have a "factory setting" switch, this are the burned in-hardware values for some controls, they overwrite the controls themselves.
      • Additionally to the controls exposed to STweaks, there are several other effects and modifiers exposed in the sysfs interfaces. This also includes the gamma curve controls for levels 0-255 in steps of 16.

        There are also some additional unidentified configurables which I wasn't able to properly give a name to or had no effects: Dithering, ABC (Seems to give a gamma brightness boost), SCC, UC, and MCM (Colour temperature) configurables whose exact effect isn't documented.

    Perseus alpha32 (29/01):
    • Charging control implemented. This is my own version.

      Charging currents:
      • Charging currents are dictated by input and charging current limits. The input current is the current flowing into the device through the USB port at 5V. The charging current is the current delivered to the battery at usually 4.35V. The device can have a higher charging current than input current because of the voltage differential, usually a 15% discrepancy. You can also have much higher input currents than charging currents, this can be useful when you are using the device in situations like gaming and charging your battery at the same time, provided your charger actually can provide the power.
      • There are 3 USB charger type categories: DCP / Dedicated Charging Ports which also includes AC chargers, but also special USB plugs; SDP / Standard Downstream Ports which usually includes almost all data enabled USB ports, and CDP / Charging Downstream Ports which includes also data enabled USB ports but which are designed to provide more power, usually on newer laptops where the USB port has a lightning logo next to it. More info here. - Technical explanation here.

      Charging logic:
      • Stable margin removal option. The charger chip is capable of detecting unstable charging sources; it dynamically reduces the input current in 100mA steps until it detects a stable voltage input [We don't have the charger chip datasheet, so the technical explanation is a bit blurry here on how it decides that it's unstable]. It further reduces it by 100mA as a safety margin, you can disable this now.
      • Complete disabling of unstable power detection. This simply ignores unstable power sources and leaves the input current limit at its set up value. This will fix charging problems people have been reporting. However, please use it at your own risk, the S3 chargers which have had these symptoms clearly have some issue in their hardware so you might actually kill them with this option enabled as there is no protection from the phone's side anymore.

        The actual input current limit can be read out in /sys/devices/platform/samsung-battery/power_supply/battery/current_max, so you can see the real limit there, it's the closest thing we have to the actual charging current on stock values since there is no hardware to read out the live currents.

      Voltage control:
      • Hard voltage control: 4.20, 4.35V, and 4.40V charging voltages are available. This is included for anybody running on third-party batteries, whom most of them have a 3.7V battery chemistry as opposed to the 3.8V on the stock battery. These batteries should be charged at 4.2V instead of 4.35V.
      • Soft voltage control: As opposed to the hard voltage control which is the voltage which the charger chip provides to the battery while charging, the soft-voltage is the battery voltage itself. 3.7V batteries have a top-off voltage of 4.2V and 3.8V again 4.35V. The default limit on the stock battery is 4.30V before the charger logic stops and considers the battery as full. This is also merely provided for 3rd party batteries which should be charged at lower voltages. If you overcharge your battery beyond these what are safe considered voltages, such as raising the default 4.30 top-off voltage to the design 4.35V or even higher, you are running into the risk of damaging the battery or even causing it to melt-down. Use at your own discretion.
    • mDNIe sharpness and RGB/YCM chroma saturation control in STweaks:

      I started implementing sharpness control in STweaks and went a bit over-board instead of a simple checkbox; You now have controls over the mDNIe registers as a delta offset value compared to the stock register values. I'm applying the offset to all mDNIe profiles and scenarios which have the specific post-processing effect active in that specific scenario. Meaning, that you start with the default profile; Dynamic / Standard / Natural / Movie and have the delta offset applied on top of that.
      • Sharpness delta. This is what brought most of the quality difference in hardcore's original tweaks. You can now fine-tune it to your own taste, and also take into regard that it produces a different effect for each screen profile while having the same delta - the base values between the profiles are different.
      • DE control - I don't know what this actually does and I couldn't discern much difference between the values, but it used to be disabled in hardcore's tweaks.
      • Chroma saturation control: This is composed of 2 values for each RGB/YCM channel. See the Munsell color system for a visual representation of the values controlled here. The chroma curve control describes the curve weight based on chroma intensity, the chroma gain is the chromatic gain that is being applied on the respective channel. Chromatic saturation weight is again another multiplier for all channels combined. I have not managed to properly identify the chroma grey threshold and its effects.

      Basically this is like an RGB control on steroids, and enables you to tune your screen to your own liking and calibrate it as you wish. Please note that not all scenarios in the profiles have chroma saturation effects, the Movie profile for example has no effect applied to the UI so chromatic control has no effect on it.

      I also want to state that the above are my deductions and theories on the descriptions of these controls, I'm not familiar enough on colour theory to be able to confidently say that these descriptions are correct, and the controls are a work-in-progress for now. Experts are welcome to contribute here.
    • Front buffer early suspend delay option for those who have issues with the CRT animation.
    • Did some refactoring on the Mali drivers and fixed a bug which may have caused less capable undervolting than the stock implementation.

    Perseus alpha31 (09/01):
    • Removed my own security fixes and replaced them with the official Samsung one. I guess it can now be disclosed: exynos-mem was only one of multiple entry-points for the memory exploit. We discovered the s5p-smem exploit ourselves back in December but kept it quiet, I fixed that one back in version 29.2 without mentioning. Nobody was secure from a smart exploiter up until then, SuperCurios or Chainfire's software fixes are also just patching a single hole in what is a Swiss cheese. Kernels >v31 and beyond stock LLA are now the only truly protected ones.
    • Samsung's fix for the sudden death syndrome (SDS) included. It is caused by eMMC failure on phones with VTU00M internal memory chips with revision 0xF1. You can check your phone with the "eMMC Brickbug Check" in the Play Store (Ignore the message if it says you're not affected, the type and revision is what matters). The patch is a firmware soft-patch that is applied on every boot and MMC resume, it is not a permanent fix. You will need to stay forever on kernels which include the patch, this also includes updated recoveries and their embedded kernels.
    • Some other minor MMC changes extracted from Update 7 sources.
    • Harmonized some mif/int max voltages with the Note 2 limits.

    Perseus alpha30 (06/01):
    • Internal and memory voltage control. This is the first and only working implementation out there. Memory interface voltage is exactly what it the name implies, the voltage on the chip-to-chip interface from the SoC to the memory chip. Internal voltage is the whole SoC voltage excluding CPU, GPU, and the MIF. This includes all auxiliary function blocks such as the ISP/Image signal processor, camera interfaces, I/O interfaces, display controller and the MFC/Multi function codec hardware video de-/en-coder.
      • Internal voltage respectively memory voltage table is found in /sys/devices/cpu/busfreq/ as int_volt_table or mif_volt_table
      • The frequencies are defined as OPP's (Operating performance points), internal frequency and memory frequency (And voltages) together as a pair form an OPP. If you want to change the voltages through the sysfs files, keep in mind how you change them. MIF voltages are stored independently with each OPP step. INT voltages are stored in respect of their frequency key.
      • Default OPP steps are: 400200, 267200, 267160, 160160, 133133, 100100. The first three numbers represent the memory frequency, the other three the internal base frequency. For example 267200 means the memory interface is at 267MHz (533MHz DDR) and the internal frequency is 200MHz.
      • The voltages in STweaks are sorted out through some magic and are frequency unique, I recommend using that for controlling them.
    • Busfreq logic control added into STweaks, this includes all the already available configurables in the stock kernel with added explanations and I supplemented it with a sampling rate parameter.
    • Some minor source updates from Samsung regarding some new sensor drivers.
    • Replaced pegasusq's runqueue detection logic with a new more superiror and precise in-scheduler collection logic, I found that the real runqueues are much less than what was previously reported. This should help a lot with hotplugging.
    • Enabled AFTR by default since we are now running very often in single-core mode. Keep in mind this mode is WFI Idle + LPA + AFTR.
    • Fixed a kernel bug which was eating up randomness entropy. This is related to that whole seeder business - please don't use any of those fixes. I also disabled virtual addresss randomization and at the same time disabled entropy generation from the block layer, which should avoid I/O overheads.

    Perseus alpha29.2 (24/12):
    • Another minor (major) release due to security. Please update.
    • I screwed up something touchscreen related in v29 that disabled Flexrate requests, fixed now.
    • Changed Flexrate requests so that they don't scale down in their sub-samples anymore. This should improve fluidity.

    Perseus alpha29 (18/12):
    • I'm doing a quick release because of the security fix, not very feature rich.
    • Fixes the exynos-mem security hole. This is my own fix and will not break camera. Read about it here. You don't need to use Chainfire's or Supercurio's fixes, in fact, you shouldn't use them because of the camera.
    • Updated Wifi drivers.
    • Added GPU utilization control to sysfs and STweaks.
    • Changed default GPU thresholds to more relaxed values (75/17)
    • Added block device read-ahead control to STweaks. Additionally set the default read-ahead for internal memory to 256kB and 1mB for SD cards.

      29.1: - Reverted the Wifi drivers back and did some CMA adjustments to see if that fixes some random reboots of people.

    Perseus alpha28 (13/12):
    • 28.1: I reverted the striked out changes due to exFat. I changed my mind due to demand. I apologize for the chaos.
    • On your SD card showing up as damaged: it is not.
      I made a decision in terms of exFat compatibility; either I advance the kernel with newer upstream Linux versions or stay back and keep compatibility with the exFat modules. While I have nothing against proprietary modules or such, not being able to adapt them to the kernel is not optimal. You can format your cards to FAT32 or ext4 without much issue. Please back up your data and format your card accordingly before flashing v28.
      [*]Updated the block system to Linux kernel 3.3.
    • Introduced FIOPSv2, ROWv4, ZEN, BFQv5 as new I/O schedulers;

      FIOPS is the new default scheduler, it's a CFQ like fairness scheduler optimized for solid state storage. ROW should be the actual better performer here as it has superior logic, but I didn't set it as default because of some lags when installing applications. ZEN is just a mix of SIO and Deadline and nothing special. BFQ seems to underperform. I recommend the first two over everything else, and added the latter two just for comparison's sake.
    • Added dynamic Fsync control (Faux123). It disables Fsync only when the screen is on. Enabled by default (Fsync off).
    • Changed some logic on when the adaptive scaling voltages are applied in the kernel init sequence. This fixes GPU voltages not being applied at boot and also fixes the wrong default voltages being displayed in STweaks.
    • STweaks tab for I/O with scheduler selection for each device block and also dynamic Fsync.
    • New script side feature in the uci.sh framework: When inserting an override.profile file into the profile folder (/data/.perseus), the entries in the override profile will supersede the ones in your default profile. You can use to make CWM zips to turn off set at boot flags or to share targeted settings with others. The override is applied once at boot after which the profile deletes itself.

    Perseus alpha27 (02/12):
    • Sources updated with various updates from N8000u1 base. Included are following important changes;
    • CMA memory allocation has been altered and page handling in the kernel in regard to CMA affected pages has been dramatically improved, this should fix the high load of the "migration" process users have had since initial Jellybean kernels.
    • Updated wireless drivers.
    • Adds a delay to SD Card host controller power-down, which I assume is to prevent some corruption. There is a specific change to Toshiba 19nm manufactured SD Cards, these are mostly the latest SanDisk 64GB cards. Together this may fix issues users have had.
    • Updates the camera interface, Video4Linux and Jpeg2x drivers and this fixes compatibility with 4.1.2 ROMs. Backwards compatibility is retained.
    • Other updates which are more transparent to the end-user.
    • New PegasusQ logic:

      - We now have additional conditionals on the hotplug logic which checks the total load across all cores and is able to bias towards a specified core count if the load is low. This is useful because previously we could have had frequency spikes and lots of low-load threads triggering a hotplug-up while in reality it wasn't needed. The core count is more biased on keeping 2 cores online in most cases now unless really needed.

      - The way freq_step is handled has changed. We now take the remainder of load space above the up threshold and dissect it into three slices each having different frequency increase step sizes. The first two slices are each of up threshold differential size, lop-sided towards the lower end of the load scale. We specify the slice size and freq_step delta in regard to the original freq_step.

      - A new fast-down scaling logic; if frequency is beyond a certain threshold, we take a heightened up_threshold value solely on the down scaling logic to scale down more aggressively from the higher frequencies.
    • STweaks. This is my custom implementation of the kernel side, based on Gokhan Moral's initial implementation.

      - CPU overclocking and voltages interface.
      - Configurables for all CPU governor settings.
      - GPU overclocking and voltage interface.
      - Interface for audio enhancements.

    Perseus alpha26 (14/11):
    • Updated MTP drivers back to the newest version. Fixes some inconsistencies which some people had.
    • Further increased MMC command timeout from Linux default 300ms to 3s in trying to finally squash errors and "unexpectedly removed SD card" after resume.
    • Ported Gokhan Moral's mDNIe interface and also added colour tone modes on top of the scenarios. System interfaces are found in /sys/class/misc/mdnie . Input syntax is the same as the output syntax, or, single register-value pairs as a single line in the output format, except 0xFF which is a terminator value.
    • Increased default sampling rate down to 30ms from 50ms for a bit more fluidity.
    • LTE devices only: Updated some power management functions on the MDM modem from latest sources; this will drastically decrease the amount of wakelocks on mobile data and improve battery life.

      26.1
    • Disabled net_os_rxfilter_add_remove userspace/ROM filter management in the Wifi driver to prevent the operating system of enabling unwanted pass-through multicast and broadcast filters while in standby.
    106
    Knowledge base

    I'm going over time to update this post with some informations. It may be unsorted, unfinished or un-editorialized for the time being.

    2) Hardware

    The Galaxy Note 2 will be coming out with a new 4412 versioned Rev 2.0, where as the one currently in the S3 is versioned Rev 1.1. The new chip will be launched at 1.6GHz default clock. What is interesting is that they have increased the base clock from 800MHz to 880MHz, most of the SoC internals feed off this clock, meaning that we're going to have 10% clock boost in the internal bus and memory speeds.

    Now as a side note: One thing that I haven't understood from the press releases back in May, is that there were this "internal 128bit bus" mentioned, with some idiotic websites taking that tidbit and claiming the chip was a 128bit architecture. Whatever. Anyway, the reason for this is that the way the Samsung SoCs internally function: they are separated in a "left bus" and a "right bus". The left bus is connected to the memory controllers and is also just called the MIF/Memory Interface. The right bus is called the "internal bus" and is connected to the ARM cores and everything else. The biggest difference here between the 4412 and the previous Samsung iterations was that both these were running at the same clock. In the 4412 the internal bus is running at half the memory interface bus, this corresponds to the increase to 128bit in the internal bus.

    Now I got curious due to all this talk about the A6 and this tidbit:
    ZPm8C.png


    "K3PE7E700F-XGC2" the last two characters refer to the clock speed. The iPhone 4S was [under]clocked at 800 Mhz. "K3PE4E400B-XGC1" was the A5's part number. E4 refers to 2 Gb LPDDR2 die and because A5 features a dual-channel LPDDR2 memory with two 32-bit die. 2 GB x 2 = 512 mb of RAM. C1 was the clock speed which was 2.5ns which indicates a 400MHz clock frequency. Two channels result in the A5 clock speed of 800MHz. So the A6 has C2 which is 1.9ns which indicates a 533 MHz clock frequency. 533 x 2 is ~1066 GHz.
    Both the A6 and 4412 use the same memory, only difference being what seems to be a revision serial character. I was talking a few months ago how the 4412 showed a good 30% bandwidth improvement over the 4210, and credited this to it running 1066mbps memory instead of 800mbps; but in reality that is not the case.

    I went over the source code of the busfrequency driver in the S3, and found that actually there is an entry for the internal frequency to run at 266MHz (128bit), but that entry is disabled in the driver; because the memory interfaces don't exceed 400MHz. The bus speed is defined in (MIF/INT) pairs and top speed available is 400200 (400MHz memory, 200 internal). Well this is interesting we can overclock our device's memory then if there's headroom! Well that idea quickly faded as I found that the C2C (Chip-to-chip) interface to the memory isn't capable of being clocked to 533MHz because simply the C2C clock divider register simply doesn't allow a divider value needed for that frequency, only being able to run 400MHz(and lower) and 800MHz. Basically we can't use the fast memory because it seems the clock dividers don't allow it. Anyway, coincidentally the i9305 sources were released two days ago and it included all the Note 2 sources and so on, so what Samsung did was simply increase the MPLL base clock from 800 to 880MHz, actually increasing the frequency of a load of things like the camera interface and who knows what at the same time.

    What this also means is that Samsung increased effective bandwidth by 30% without increasing the memory speed. This indicates much improved memory controllers, and also why it easily beats the Tegra 3 and others in memory benchmarks.

    Another new addition to the REV 2.0 chip is that we'll be running 533MHz for the Mali clock by default. We were already experimenting with this on the S3 and pretty much made the GPU run up to 700MHz, of course, it gets quite warm and battery hungry, but it's neat nonetheless.

    3) Reserved memory spaces

    There is the current reserved memory space breakdown, with red as Perseus changes over stock:

    #Secure spaces on fixed memory addresses

    Front-camera firmware & heap: fimc0: fmic1 =
    0x65800000 - 0x66700000 => 15360K (0xF00000) => 14336K

    Multi function codec B memory space: mfc-normal =
    0x64000000 - 0x64400000 => 4096K

    ION device memory allocator reserved space: ion =
    0x5F200000 - 0x63800000 => 71680K (0x4600000) => 48128K

    Multi function codec device reserved space: device_mfc =
    0x5C800000 - 0x5CA80000 => 2560K (0x280000)

    Multi function codec A memory space (Virtually contiguous to MFC, practically has a physical memory hole): mfc-secure =
    0x5C100000 - 0x5C800000 => 7168K (0x700000)
    0x5F000000 - 0x5F200000 => 2048K (0x200000)

    Bootloader: sectbl =
    0x5C000000 - 0x5C100000 => 1024K (0x100000)

    # non secure

    Camera imaging subsystem: fimc_is => 12080K (0xBCC000) => 10240K
    Display interface and frame buffer: fimd => 8192K (0x800000)
    Main-camera firmware & heap: fimc0 => 62464K (0x3D00000)
    Audio buffer: srp => 1024K (0x100000)
    103
    Got the time to look into Update 7 already? Hope is the last thing you lose so many ppl still wondering if LLA kernel (aka Update 7 content I guess) includes some fix related to SDS appart from the exynos exploit fix itself :p
    Way to spoil my surprise. ;)

    Anyway I'm already almost finished.

    I'm confirming that the sudden death syndrome is caused by MMC failure and the fix is kernel integrated, the new bootloader is unrelated to any of the security issues or hardware fixes.

    Expect an urgency kernel update within the hour. I also advise other developers who already are using other source bases not to use update 7, it is outdated and older than other sources. I extracted the fixes and will be in my Github within the same hour.