[Kernel][Yank555][OMNI 4.4.2 v1.6j][CM11 1.6j,CM10.2,CM10.1]

[yank555]

Kurze Frage an JP:was sind noch mal deine gpu steps? Ein Kumpel hat den boffela am laufen und wollte die gpu Settings anpassen habe aber keine Lust den Kernel extra neu zu flashen.

Huch, kann ich jetzt nicht so nicht sagen, mein S3 ist schon paar Monate nimmer mein daily phone, weiss ich nicht mehr aus dem Stegreif

Kann auch grad nicht schaun, hab's nicht griffbereit.

Schau doch einfach in deine /data/kernel-boot.log oder /sys/etc/init.kernel.sh.

JP.

 

[Gamer-king]

Okay danke dann werde ich da schauen.

 

[yank555]

!! Wünsche allen hier eine guten Rutsch ins neue Jahr !!

 

[Neo3477]

Da schließe ich mich mal an.

Gruß Neo

 

[Mike-El]

Hallo,

ich versuche gerade den Kernel (Yank555.lu-CM10.2-v1.6g.zip) zu installieren.
Als Rom nutze ich die SlimBean (Slim-i9300-4.3.build.2.2-OFFICIAL-1743).

Nachdem ich in Aroma alles eingestellt habe kommt folgende Meldung:

Preparing Installation
- checking if device SGS3 GT-I9300
assert failed: getprop("ro.product.device") == "m0" ||
getprop("ro.build.product") == "m0" ||
getprop("ro.product.device") == "i9300" || getprop ("ro.build.product") == "i9300" ||
getprop("ro.product.device") == "GT-I9300" == || getprop("ro.build.product") == "GT-I9300"

allerdings wird angezeigt das der Kernel geflashed wurde. Wurde er aber nicht...

jemand eine Idee wo das Problem liegt?

lg

 

[yank555]

Hi,

Mit dieser Fehlermeldung wurde mit Sicherheit mal nichts geflasht, weil das Script den Sicherheitscheck, welcher prüft, ob der Kernel auch auf dem richtigen Gerät geflasht wird, nicht besteht.

Hast du ein i9300 ?

Wenn ja, welche Recovery hast du drauf ?

JP.

 

[Mike-El]

Hi,

ja ich habe ein S3 (i9300).
SlimBean ist ja auch drauf und läuft.

Recovery ist PhilZ Touch][i93xx] 6.07.9...

kann es sein das es an der SlimBean liegt? da die ja zb bei ro.build.product m0 statt I9300 eingetragen haben?

ich finde es komisch. das Problem hatte ich noch nie.

danke und lg

 

[yank555]

Nein, das liegt an der neueren Philz ... gab es auch bereits auf dem Note 3 mit seiner Recovery.

Du kannst den Check aus dem Kernel Flasher Script entfernen, oder eine ältere Philz Recovery oder ne richtige CWM flashen.

CWM Touch 6.0.4.4 tut's richtig gut, und flasht alles bis 4.4.2 ROMs.

JP.

 

[Mike-El]

Danke. Jetzt hat alles wunderbar geklappt!

Lg

 

[yank555]

OMNI beta Kernel Update

Beta 2 :

OK, well, since CM decided to make their crappy move, changed haptic feedback settings path in sysfs (vibrator), this stupid little thing has been a nightmare, one ROM following the move, the other sticking with the old location...

I've had enough with that crap, so now the setting is available in both locations at the same time, I'm fed up with moving it around

This fixes haptic feedback settings in SlimKat.

As for cifs, please test it and report back, I've tried, it didn't work for me, though, but the patch is implemented...

Beta 1 :

Since I read a lot of people complaining about colors and about missing color controls on newer kernels (Update 12+).

So I took a few hours today and made a lite mdnie hijack interface (as I did for my Note 3 kernel). The base idea comes from WhatHub, so credits and thanks to him !

Don't ask me if this is the same as "master sequence", or whatever, it certainly should allow to achieve similar results, but I really don't know as I've never looked into the "master sequence" code, and I won't either.

And I called it a way less fancy name, simply "mdnie hijack", as that is exactly what it does, it hijacks mdnie settings, no more, no less.

It includes a global black level control and a sharpness setting.

The default color setting for the hijack profile is Samsung's natural (not standard !), as natural is the one I prefere and use.

What I would ask of you is to play with it, validate it works as expected, and if you come up with interesting settings (init.d scripts), please share them here, so i can include at least a few option in Aroma for the final 1.6j kernel. Thanx !

There is no interface in Aroma, that would be way too big to implement it there, so if you want to play with it, here's the sysfs interface documentation :

 * /sys/class/mdnie/mdnie/hijack : 0 = disbaled / 1 = enabled
 *
 *    Enable / Disable hijacking of mdnie settings (default = disabled)
 *
 * /sys/class/mdnie/mdnie/sharpen : 0 = disbaled / 1 = enabled
 *
 *    Enable / Disable screen sharpness (default = enabled, stock Samsung Update 12+)
 *
 * /sys/class/mdnie/mdnie/black : -128 to +128
 *
 *    Global black level, will shift black RGB setting by this value (default = 0)
 *
 *    NB: Effectively applied values for black will never be below 0 nor above 255 !
 *
 *        So there is no use setting Black RGB to (0,0,0) and this to -10, the result
 *        will still be (0,0,0).
 *
 * /sys/class/mdnie/mdnie/{color}_red   : 0 to 255
 * /sys/class/mdnie/mdnie/{color}_green : 0 to 255
 * /sys/class/mdnie/mdnie/{color}_blue  : 0 to 255
 *
 *    Allows to set the RGB values for the base colors :
 *
 *      - red
 *      - green
 *      - blue
 *      - cyan
 *      - magenta
 *      - yellow
 *      - black
 *      - white
 *
 *    (default = Samsung's natural mode)

Changelog OMNI 4.4.2 v1.6j-beta2 :

• added CM's alternative vibrator config path in sysfs (I've just had enough with that crap, now both paths are available at the same time, Yank555.lu)
• updated fs namespace (so cifs should work again, tomkasick)
• reverted black crush fix (AndiP71)
• reverted sharpness fix (disabled by default, AndiP71)
• added mdnie hijack controls for color calibration, black crush and sharpness (Yank555.lu)
  
  
• This kernel works 100% on OMNI and SlimKat and Temasek (V22 or newer).

• Download Link

 

[KoKo 61]

Danke Yank. Alles funktioniert so wie es soll. Vibrationseinstellung geht auch. Wie immer top Arbeit.

 

[netguru]

Neo
Slimkat eins a mit dem omni kernel!

 

[S13gfried]

Hey Yank,

davon schon Mal etwas gehört?

Prinzipiell ist es bei den Kernel Wakelocks also schwer zu sagen, welcher Wakelock ist die Ursache, und welcher Wakelock ist nur Effekt.

Spoiler

Hier mal ein Beispiel meiner Kernel-Wakelocks der letzten Nacht:
(Man könnte nun denken, daß battery-monitor für 9 Minuten Wach-Zeit verantwortlich ist. Ist es aber nicht...)
================
Kernel Wakelocks
================
"battery-monitor" (): 9 m 16 s (556 s) Cntc/wc/ec)553/0/553 2,1%
"wlan_rx_wake" (): 8 m 37 s (517 s) Cntc/wc/ec)336/0/336 1,9%
"l2_hsic" (): 5 m 45 s (345 s) Cntc/wc/ec)612/158/612 1,3%
"alarm_rtc" (): 5 m 10 s (310 s) Cntc/wc/ec)425/80/219 1,2%
"PowerManagerService" (): 4 m 16 s (256 s) Cntc/wc/ec)730/0/0 1,0%
"alarm" (): 2 m 18 s (138 s) Cntc/wc/ec)740/4/0 0,5%
"wlan_wake" (): 46 s (46 s) Cntc/wc/ec)14606/159/0 0,2%
"umts_rfs0" (): 20 s (20 s) Cntc/wc/ec)7/0/7 0,1%
"rpm_hsic" (): 11 s (11 s) Cntc/wc/ec)55/0/0 0,0%
"AudioOutLock" (): 8 s (8 s) Cntc/wc/ec)3/0/0 0,0%
"umts_ipc0" (): 3 s (3 s) Cntc/wc/ec)23/0/23 0,0%
"efsd-interface" (): 1 s (1 s) Cntc/wc/ec)14/0/0 0,0%
"secril_rfs-interface" (): 1 s (1 s) Cntc/wc/ec)7/0/0 0,0%
"power-supply" (): (0 s) Cntc/wc/ec)603/98/0 0,0%
"tx_hsic" (): (0 s) Cntc/wc/ec)111/0/0 0,0%
"mmc1_detect" (): (0 s) Cntc/wc/ec)708/0/0 0,0%
"sync_system" (): (0 s) Cntc/wc/ec)1/0/0 0,0%
"KeyEvents" (): (0 s) Cntc/wc/ec)889/0/0 0,0%
"mmc0_detect" (): (0 s) Cntc/wc/ec)708/0/0 0,0%
"secril_fmt-interface" (): (0 s) Cntc/wc/ec)78/0/0 0,0%

Dem Problem, daß man nun nicht weiß, welcher Kernel-Wakelock die Ursache ist, hat sich ein findiger Developer bei den XDA-Devs angenommen und einen Kernel-Patch geschrieben, der für jede Sekunde nur den verursachenden Kernel-Wakelock loggt. Die Kernel-Wakelocks, die nur aktiv sind, weil das Handy eh schon wach ist, werden nicht mit einberechnet.
Diesen Patch hat z.B. der Siyah Kernel eingebait und die Funktion kann man mit den S-Tweaks aktivieren.
Das heißt, in diesem Modus werden nur noch die Kernel-Wakelocks angezeigt, die der Grund/die Ursache sind, daß das Handy gerade wach ist.

Spoiler

Hier mal die Kernel-Wakelocks der selben Nacht(!) im diskreten Kernel Wakelock Modus.

===================================
Kernel Wakelocks (!!! discrete !!!)
===================================
"wlan_rx_wake" (): 4 m 47 s (287 s) Cntc/wc/ec)267/0/267 1,1%
"battery-monitor" (): 2 m 25 s (145 s) Cntc/wc/ec)192/0/192 0,5%
"l2_hsic" (): 2 m 23 s (143 s) Cntc/wc/ec)238/157/238 0,5%
"PowerManagerService" (): 1 m 24 s (84 s) Cntc/wc/ec)91/0/0 0,3%
"alarm_rtc" (): 49 s (49 s) Cntc/wc/ec)182/80/87 0,2%
"wlan_wake" (): 28 s (28 s) Cntc/wc/ec)472/159/0 0,1%
"alarm" (): 24 s (24 s) Cntc/wc/ec)202/4/0 0,1%
"umts_rfs0" (): 2 s (2 s) Cntc/wc/ec)1/0/1 0,0%
"umts_ipc0" (): (0 s) Cntc/wc/ec)2/0/2 0,0%
"power-supply" (): (0 s) Cntc/wc/ec)102/98/0 0,0%

Hier sieht man nun schön, wie viele Kernel-Wakelocks nun gar nicht mehr gelistet sind, weil sie nur Nebeneffekt-Wakelocks waren. Nämlich alle die, die jetzt auf einmal fehlen. Jetzt sieht man sehr schön, daß WLAN der Hauperzeuger der Wach-Zeit war und daß Battery-Monitor hauptsächlich ein Nebeneffekt ist, der einsetzt, weil WLAN das Handy augeweckt hat.

 

[yank555]

Nee, eigentlich nicht ... gibt's dazu ein Commit ?

JP.

 

[S13gfried]

Habe auch nur das gelesen beim recherchieren, du bist doch hier das Tier
Ist ja aber schon etwas älter die Sache...

Ich frage mal Rob

 

[Lord Boeffla]

JP, ich habe den commit irgendwo noch. Ihn zwar nie genufzt, aber wenn du ihn brauchst kann ich ihn dir nach meinem Urlaub mal rüber schieben.

Andi

 

[yank555]

JP, ich habe den commit irgendwo noch. Ihn zwar nie genufzt, aber wenn du ihn brauchst kann ich ihn dir nach meinem Urlaub mal rüber schieben.

Andi

Danke, warum nicht, reinshaun kostet ja mal nix

JP.

PS: Geniess dein Urlaub, schau nicht zu oft in Tapatalk

 

[Rob2222]

Huhu,

die Kernel-Wakelocks sind ja mitunter nebenläufig. Das heißt, wenn ProcessA, ProcessB und ProcessC jeweils einen einminütigen Wakelocks schalten, hat danach jeder Prozess 1 Minute Wakelock-Zeit in der Statistik.

Man könnte nun denken, das Handy war deswegen nun zwingend 3 Minuten wach.

Schalten sie die Wakelocks aber (zufällig oder systembedingt) gleichzeitig, war das Handy aber nur eine Minute wach.

Ein schönes Beispiel beim S3 war der Fast-Dormancy Wakelock der in großen Teilen zeitgleich mit dem MultiPDP-Wakelock geschaltet wird. MultiPDP wird wieder durch Datenverkehr ausgelöst.
Datenverkehr löst also beide Wakelocks aus. Da aber das Handy durch MultiPDP sowieso wach ist, ist es recht egal, ob zeitgleich noch ein Fast Dormancy Wakelock geschaltet wird, da das Handy ja eh schon aktiv ist.



Die diskreten Wakelocks sind eine Implementierung von Tungstwenty bei den XDA-Devs. Es ging darum, die Überschneidungen zu eliminieren, und in der Kernel Wakelock-Tabelle nach Möglichkeit immer nur den verursachenden Kernel-Wakelock zu zählen. Also der erste Kernel-Wakelock der geschaltet wird und das Handy aufweckt, der wird gezählt. Wenn dann andere Kernel-Wakelocks dazuschalten, weil das Handy gerade eh schon wach ist, ist das dann egal. Diese "Tocher-Wakelock" werden dann in dem Modus nicht mitgezählt.

Die Implementierung war z.B. im Siyah Kernel mit eingebaut und in dem Siyah-Tool umschaltbar. Ich habe damals mit BBS eine Ref erzeugt, dann in den anderen Modus geschaltet, dann noch eine Ref erzeugt, dann das Handy eine Nacht liegen lassen, dann ein Dump erzeugt, zurückgeschaltet und noch ein Dump erzeugt. Damit hatte ich von derselben Nacht zwei verschiedene BBS Dumps, die ich vergleichen konnte.

Hier fand ich aber teilweise Unstimmigkeiten. Zum Beispiel kann es nach meinem Verständnis nicht sein, daß ein einzelner, normaler Kernel-Wakelock länger ist als alle diskreten Kernel Wakelocks in Addition. Das habe ich aber beobachten können und Tungstwenty hier auch zurückgemeldet.

Seit dem habe ich das Thema nicht mehr wirklich verfolgt, da ich auch nach Analyse vieler BBS Dumps irgenwann ein Gefühl hatte, welche Kernel-Wakelocks Auslöser und welche Kernel-Wakelocks nur "Töchter-Wakelocks" sind, die eigentlich völlig egal sind.

Beim S3 ist das ja recht überschaubar, PowerManagerService sind die App-Wakelocks, battery-monitor wird durch häufiges Aufwecken erzeugt, das das Handy bei jedem Aufwecken schaut, wie es um den Akku steht.

MultiPDP, Secril-FD und L2HSIC entstehen hauptsächlich durch Netzwerkverkehr, wobei Secril-FD (aus dem Bauch geschätzt) etwa 80% Überschneidung mit MultiPDP hat, von daher ist Secril-FD nicht schlimm, weil das Handy durch MultiPDP sowieso schon wach ist. Siehe Testauswertung dazu hier.

Und um MultiPDP zu reduzieren, muß man einfach nur den Hintergrundtraffic minimieren.

Damit hat man zeitlich gesehen die größten Kernel-Wakelocks schon abgedeckt. Der Rest sind dann nur noch zeitlich kleinere Kernel-Wakelocks die in meinen Augen recht unwichtig sind.


Für mehr Infos zu den diskreten Wakelocks einfach bei XDA mal nach "discrete" und Autor Tungstwenty suchen.

Viele Grüße
Rob

 

[S13gfried]

Ich weiß gerade nicht mehr wo ich es gelesen hatte, es ging meiner Meinung nach völlig unter nach der Vorstellung von 4.4., jedenfalls sollen ab KitKat potentielle Wakelocks im "ähnlichen" Zeitraum vom System selbständig zusammengefasst werden, um einen höheren Deepsleep zu garantieren.
D.h. wenn Facebook 14.15Uhr sagt in 30min Serverconnect und WeatherPro 14.20Uhr sagt in 30min Serverconnect, werden beide dennoch zur selben zeit geweckt.


MfG


Danke Rob für deine Ausführung, finde die Funktion dennoch nicht uninteressant, wenn sie korrekt funktioniert

 

[Allstar90210]

wieso lässt sich der yank nicht installieren?

AROMA Installer version 2.70RC2
  (c) 2013 by amarullz xda-developers

ROM Name    : Yank555.lu CM11 Kernel
ROM Version : v1.6i
ROM Author  : Yank555.lu
Device      : i9300 CM11
Start at    : Sat Jan 11 12:08:17 2014


Preparing installation
----------------------
  
  - checking if device is a SGS3 GT-I9300
    script aborted: assert failed: getprop("ro.product.device") == "m0" || getprop("ro.build.product") == "m0" ||
    getprop("ro.product.device") == "i9300" || getprop("ro.build.product") == "i9300" ||
    getprop("ro.product.device") == "GT-I9300" || getprop("ro.build.product") == "GT-I9300"
  assert failed: getprop("ro.product.device") == "m0" || getprop("ro.build.product") == "m0" ||
  getprop("ro.product.device") == "i9300" || getprop("ro.build.product") == "i9300" ||
  getprop("ro.product.device") == "GT-I9300" || getprop("ro.build.product") == "GT-I9300"


Installer Error (Status 7)


End at : Sat Jan 11 12:08:17 2014