[KERNEL] Perseus

frrndr75 · 2 Mar 2013

Ciao, allora vediamo un po' questo kernel, questo kernel posso dire che tra i migliori che ho provato come stabilita ect...grazie anche alla app STweaks che ci permette modificare tutto il kernel.
Premetto che anche con questo kernel per quanto e stabile consiglio di non OC al massimo la cpu e neanche di UV troppo bassi si rischia di brikare il telefono.
Non provato su android 4.1.1
Consiglio ancora di lasciare cosi come sono i valori faro in futuro una guida specifica per usare al meglio questa app STweaks.
Almeno una volta il telefono dovrÃ essere collegato con kies per installare i driver.

Materiale necessario:

Essere ROOT guardate qua (root+recovery). oppure usare auto-root (non verrÃ installata la recovery), per la recovery usare questa.
questi file vanno installati sempre con odin (stessa procedura che viene indicata sotto) mi raccomando alle spunte solo auto reboot/f.reset time

Riassumiamo:

Root

Installare recovery

Installare kernel

Odin

Scaricate il file, create una cartella sul desktop ed estraete tutti. Il programma va aperto con diritti di admin.

Kernel

Avrete due possibilitÃ un file TAR e uno CWM, quindi due possibilitÃ quella che si deve usare con ODIN e quella TAR

File CMW, questo file e da flashare dalla recovery NON CON ODIN.

Chiudete da task manager tutto quello che riguarda kies.
E come dice il buon SimoScorpion meglio usare un portatile con batteria carica oppure un gruppo di continuitÃ .
il telefono almeno 30% di batteria(questo e mio:eheh

Avviate ODIN, dovete lasciare tutte le spunte come sono in figura:

adesso selezionate PDA e selezionate il file Perseus con estensione TAR.

Bene, adesso lasciamo cosi odin, spegniamo il telefono e avviamo in download mode (vol.- / tasto home / power) vi appare una schermata con due opzioni vol+ oppure vol- a noi interessa vol+, cliccate vol+ adesso.
Adesso collegate il telefono al pc con usb, noterete che con odin si accende una casella ID COM, bene a questo punto cliccate start e lasciate fare tutto il processo saranno pochi secondi circa 7 ma non scollegate mai il telefono dal pc fin che non avrÃ finito tutto intendo fino al riavvio del telefono.
Adesso nel telefono avrete quella famosa app STweaks, come vi ho detto prima non cambiate nulla se non conoscete le varie caratteristiche, se propio non c'Ã¨ la fate a stare fermo ricordatevi di non mettere la spunta set a boot questo vi da la possibilitÃ che in caso si blocca il telefono al riavvio torna alle impostazioni default.

Ciao!

Features / changelist:
Clicca per allargare...

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.

Clicca per allargare...

Download Kernel

frrndr75 · 2 Mar 2013

Nuovi aggiornamenti:

Perseus alpha33.2 (27/02):

Master profile is correctly calibrated.

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:

(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.

Clicca per allargare...

frrndr75 · 29 Mar 2013

Aggiornamento:

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

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.

frrndr75 · 24 Apr 2013

Aggiornamento:

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 lower 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 higher 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).

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.

Clicca per allargare...

io per adesso lo sto usando cosi come, e va una meraviglia, vi farÃ² sapere per UV/OC tra qualche giorno. per adesso con la versione 35 ho fatto 7 ore di schermo acceso, UV-75.

[KERNEL] Perseus

frrndr75 Silver Droid

frrndr75 Silver Droid

frrndr75 Silver Droid

frrndr75 Silver Droid

Ricerche Utili

[KERNEL] Perseus

frrndr75 Silver Droid

frrndr75 Silver Droid

frrndr75 Silver Droid

frrndr75 Silver Droid