Il Forum è consultabile solo in modalità lettura. Per domande o consigli iscriviti al nostro GRUPPO FACEBOOK / COMMUNITY cliccando qui

[ROM] JellySnap | Android 4.2.2 - CM10.1 | [... is coming ...]

Discussione in 'Rom per Xperia Arc S' iniziata da MatteoV, 31 Mag 2013.

Status Discussione:
Chiusa ad ulteriori risposte.
  1. fearless

    fearless Silver Droid

    Iscritto:
    13 Feb 2013
    Messaggi:
    2.646
    "Mi Piace":
    1.732
    Faccio subito.
    per il font sopra è indifferente.

    ps : build.prop da sd non si riesce a settare con i giusti permessi.
    l'ho spostato su system>vendor ,dato i giusti permessi e messo in system.

    gli altri 2 spostati con i seguenti permessi : rwxr - xr - x
     
    Ultima modifica: 6 Ott 2013
  2. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    Ottimo ;) poi con calma se puoi dimmi se noti miglioramenti, peggioramenti ecc...
    gracias
     
  3. fearless

    fearless Silver Droid

    Iscritto:
    13 Feb 2013
    Messaggi:
    2.646
    "Mi Piace":
    1.732
    Ok...
    Al momento posso segnalare che c'è un leggero ritardo nell'accensione del display quando si preme il tasto centrale hardware.
    Non so se il "problema" possa avere una relazione con la modifica.

    Inviato con Topatalk 2
     
  4. carlj

    carlj Worker Droid

    Iscritto:
    27 Apr 2013
    Messaggi:
    55
    "Mi Piace":
    15
    Voto anche io x il secondo font!!!
     
    Ultima modifica: 6 Ott 2013
    A MatteoV piace questo elemento.
  5. ikee

    ikee Worker Droid

    Iscritto:
    28 Ago 2013
    Messaggi:
    265
    "Mi Piace":
    123
    Il secondo mi pare sia caruccio :D

    ---------- Post aggiornato alle 22:38 ----------

    mattevivi: fammi capire un po' meglio come funziona quello che tu chiami il "gran pastrocchio" di screenstate? Io prima avevo impostato SmartassV2/Cio governor/sio... posso lasciare così ed adesso dovrebbe scegliere a seconda delle situazioni giusto? O devo rimettere governor/sio iniziali (che manco mi ricordo quali erano..)
     
  6. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    yann!!! Che piacere vederti! Grazie del consiglio ;) spero che le tue mod procedano bene...ti scrivo poi via mail per un consiglio estetico sulla rom.
    A presto

    Esatto, ci sta che ci sia questo lag alla riaccensione...devo sistemare un po' meglio lo script ma sono convinto che sia un grande vantaggio in termini di durata batteria.

    In pratica fà così perchè non appena lo schermo si spegne, la frequenza minima e massima vanno a 245 MHz, poi all'accensione la max viene sparata a 1,4GHz con Gov Ondemand (cioè il gov che scala verso l'alto più velocemente). In pratica però potrei fare in modo che lo scaling avvenga in due passaggi con un intermedio a circa 700-800 MHz in modo da rendere il processo più veloce ed evitare il lag di accensione.

    comunque è già una cosa buona che tutto funzioni per come ho deciso...:)
     
    Ultima modifica: 7 Ott 2013
  7. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    dunque, le impostazioni che hai attualmente non sono importanti...lo script le sovrascrive non appena si verifica un "on/off" dello scermo.
    Il sio non viene toccato, quindi puoi scegliere come preferisci.

    Se sei curioso di avere altre info sullo script sarò lieto di fornirtele :) dimmi tu.
     
  8. ikee

    ikee Worker Droid

    Iscritto:
    28 Ago 2013
    Messaggi:
    265
    "Mi Piace":
    123
    Risposte tecniche no (non sono un tecnico) ma sulla logica del funzionamento dello script si (ad alcune domande hai già risposto). Ti confesso che sto notando un forte miglioramento delle performances ma per contro un decadimento più rapido della batteria (sotto sotto non mi dispiace in quanto non ho mai visto il mio ArcS così reattivo :D :D ).
    La cosa che mi infastidisce di più è che dei tre script non riesco a valutare quale dei tre influenza cosa e non riesco a fare una valutazione obiettiva.
     
  9. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    :gulp: dammi un secondo e scrivo una riga di spiegazione per ogni script :)
     
  10. ikee

    ikee Worker Droid

    Iscritto:
    28 Ago 2013
    Messaggi:
    265
    "Mi Piace":
    123
    Anche due ;)
    stavo leggendone i contenuti (praticamente sono files di testo con comandini, sullo stile del vecchio e caro batch ;D ;D) e mi stavo chiedendo ad esempio cosa e come cambierebbero le cose se scegliessi un governor differente al wake (per lo script screenstate). Projectbutter e build.prop faccio ancora un po' di fatica ad interpretarli.
     
  11. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    scusami...mi sto perdendo dietro al CM installer! Ora però la smetto visto che tanto non funge...ehehe
     
  12. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    Dunque:

    Il file screen_state serve proprio per determinare alcune impostazioni della cpu nelle situazioni schermo acceso/schermo spento. L'obiettivo è ridurre al minimo i consumi con telefono inattivo e avere il cell scattante a telefono attivo.

    Nel file ogni riga preceduta da un "#" è una riga di commento.

    Nella prima parte puoi leggere una breve descrizione dei governor disponibili.
    Da riga 100 inizia il vero e proprio script che è di tipo loop, cioè arrivato in fondo ricomincia.

    In generale puoi vedere diverse sezioni:
    step1: scelta del governor per lo stato AWAKE (schermo acceso).
    step2:scelta governor per lo stato SLEEP (schermo spento).

    In questi due step vengono semplicemente dichiarate le due variabili: SLEEP_GOVERNOR e AWAKE_GOVERNOR.

    Siamo a riga 158. Qui inizia il loop per lo schermo acceso, testualmente il file compie le seguienti azioni:
    Riga 170: dichiarazione di AWAKE --> cat (sta per vai a leggere cosa contiene) il file che si trova in sys/power/wait_for_fb_wake. Ok, Dice quindi che la variabile AWAKE è = al contenuto di quel file.

    Riga 171 dice: se la variabile AWAKE è = "awake" (cioè, se nel file wait_for_fb_wale è scritto wake) allora
    Riga 172:c'è il comando vero e proprio --> assegna al file /sys/device....blablabla/scaling_governor la variabile AWAKE GOVERNOR

    In altre parole qui viene solo detto al sistema di controllare il suo stato attuale ed, in caso di stato "awake" applicare il governor dichiarato all'inizio per lo stato "schermo acceso".

    Da riga 175 a riga 279 vengono svolte le seguenti operazioni:
    Controlla quale governor è attivo ed assegna determinati valori ai parametri tipici di quel governor. I parametri sono diversi da governor a governor. Per ondemnad ad esempio si possono modificare: Up_threshold, io_is_busy, sampling_down, sampling rate.

    Arriviamo alla riga 282
    Qui si possono modificare ulteriori parametri per quando lo schermo è acceso:
    freq max e freq min; alcuni parametri del gov conservative; dirty_ratio e cache_pressure (controllano la ram); renice di alcuni processi all'accensione.

    Da riga 335 troviamo tutte le identiche impostazioni precedenti ma per quando lo schermo è spento.

    Infine da riga 559 troviamo solo righe di test per vedere se lo script funziona (e funziona, ho già provato diverse cose).

    Questo è quanto , per ciò che riguarda screen_state.
    Scrivo in altro post buil prop e project butter



    Ovviamente per customizzare lo script ti basta agire sull' # all'inizio della riga facendo attenzione a non mandarlo in clonflitto (per esempio impostando due gov per lo stato awake:dent:)
    Bisogna anche tenere conto del fatto che il nostro kernel non dispone di tutti i governor indicati nello script perciò selezionando ad esempio..Conservative lo script non funzionerà. Per di più per gli script loop se ci sono errori il risultato è che si interrompe il ciclo per ciò perde completamente utilità
     
    Ultima modifica: 7 Ott 2013
    A ikee piace questo elemento.
  13. yann73

    yann73 Golden Droid

    Iscritto:
    5 Feb 2010
    Messaggi:
    7.157
    "Mi Piace":
    1.176

    Tranquillo!!! fa piacere a me seguire dal esterno queste tue fantastiche creazioni ;-)

    Sono due settimane che non accendo il pc!!! Ogni tanto ci vuole un Po di disintossicazione per riprendere poi il via :alol: Anzi scusami tanto che non ho ancora risposto alla tua ultima missiva xD :efumo:


    Inviato dal mio Nexus 4 con Tapatalk 4
     
    A MatteoV piace questo elemento.
  14. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    Passiamo a Project_butter.
    Questo script si basa sul processo di RE-NICE...
    Cioè uno script che riassegna ad alcuni processi il loro nicelevel.
    Il nicelevel è una scala di priorità che va dalla maggiore -20 al minore +19. (esatto, va al contrario :) )
    Il nicelevel di un processo è la caratteristica che fa si che la cpu intervenga prima su quel processo piuttosto che su altri --> in altre parole se un processo ha un nicelevel negativo ed inferiore a -10, verrà preso in carico immediatamente. Al contrario processi con nice level + 10 verranno tralasciati dalla CPU.
    Teniamo conto del fatto che stiamo parlando di centesimi di secondo :).

    In questo script si possono semplicemente specificare ben 24 processi a cui assegnare un nicelevel che viene ricaricato ogni 5 secondi.

    Passiamo alla sintassi:
    la parte che ci interessa è da riga 53 a riga 75 in cui possiamo editare lo script per specificare i processi da "processare" (scusate il gioco di parole). Ci sono 3 gruppi di processi divisi per importanza: resident_system_app;other system app;other app...


    Altra parte da editare è riga 13 in cui viene specificato il numero di processi a cui applicare il renice.
     
  15. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    OOOk, ho modificato in modo definitivo il file screen_state.

    Dunque, ora funziona così:

    Governor con schermo acceso: ONDEMAND
    freq max: 1,5 GHz
    freq min: 122MHz

    Governor con schermo spento: SmartassH3
    freq max: 768MHz
    freq min: 122MHz

    Si possono selezionare tutti i governor disponibili nel kernel :) Come fare?

    Andare in system/etc/init.d ed aprire con text editor il file S98screen_state.
    Le prime righe sono queste:
    [​IMG] [​IMG]

    per selezionare il gov desiderato basta aggiungere un "#" prima del gov di default (ondemand per schermo acceso, smatassh3 per schermo spento) e togliere l' "#" prima del gov desiderato.


    Edit: ah..il file, lo carico
    https://docs.google.com/file/d/0B-HBYOt7xhPiZ2xfbUlRa093Yk0/edit?usp=sharing
     
    Ultima modifica: 7 Ott 2013
  16. ikee

    ikee Worker Droid

    Iscritto:
    28 Ago 2013
    Messaggi:
    265
    "Mi Piace":
    123
    hai solo decommentato
    SLEEP_GOVERNOR="ondemand";
    e scritto
    SLEEP_GOVERNOR="SmartassH3";
    o hai aggiunto altri tweaks a fine script?
    Ah mo ho visto.. hai anche tradotto!! :cool:
    Peccato non riesca a scaricare il file (problemi di permessi su google docs) :(
    ------
    edit
    Appena scaricato :D
     
    Ultima modifica: 7 Ott 2013
  17. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    ehm..ops..sistemato il link.
    Ho aggiunto i governor del nostro kernel così si possono selezionare governor reali e non solo virtuali.
    Tradotto due cavolate giusto per semplificare le cose e "commentato" tutti valori di modifica per ondemand :)
     
  18. ikee

    ikee Worker Droid

    Iscritto:
    28 Ago 2013
    Messaggi:
    265
    "Mi Piace":
    123
    Non te ne avvedere Matteo ma ho rimosso lo script screen_state. Purtroppo i consumi cominciavano ad essere ingestibili (8-10% orari).
    Ho preferito ritornare alla vecchia impostazione governor/scheduler. Ho notato inoltre dei picchi verticali dei consumi in corrispondenza dell'attivazione dello schermo (perdonami ma non sono riuscito a fare lo screenshot delle statistiche di utilizzo della batteria) il che mi ha fatto pensare che lo script, sebbene funzionante, non raggiunga lo scopo prefisso (riduzione consumi).
    Proprio per monitorare i consumi cerco in questi giorni di fare un uso abbastanza omogeneo del cellulare. Sebbene abbia molte sincro attive ed il voip in entrata attivo (che so essere devastante per la batteria) le telefonate erano sempre abbastanza brevi e l'utilizzo si limitava alla lettura delle mail e twitter.
    Obiettivo: arrivare a fine giornata ;)
     
  19. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    sono daccordo al 100% con te!
    Inoltre aggiungo che ho fatto una discreta confusione con questi script...preso dall'entusiasmo del loro funzionamento mi sono lanciato in test scellerati.
    Il risultato è che i feedback sono stati un misto di tutto...senza capirci un nulla. Il problema è nato dal fatto che io erroneamente ho considerato le varie modifiche indipendenti...invece non lo sono.
    Dunnque...meglio procedere con ordine...altrimenti non se ne esce più???

    Quindi..tra poco farò un post riassuntivo e indicherò le modalità per procedere (per chi lo volesse) ad un test che sia significativo.
     
  20. MatteoV

    MatteoV Moderator Membro dello Staff

    Iscritto:
    28 Feb 2013
    Messaggi:
    967
    "Mi Piace":
    837
    Eccomi, dunque...nella cartella che trovate al seguente link
    My Files

    (se non funziona il link apri lo spoiler)


    sono contenuti due file: S00loopyst e S98screenstate_scaling

    i due script con diversi obiettivi:
    S00loopyst ha l'obiettivo velocità e reattività
    S98screenstate mira alla maggiore durata della batteria

    Per effettuare un test sensato è necessario non eseguirli contemporaneamente evitando così che i risultati siano inficiati vicendevolmente dai due script.
    Quel che bisogna valutare per il test è: reattività generale, reattività ad app pesanti, durata batteria, note eventuali.

    Un test è affidabile se le condizioni di utilizzo sono le stesse...ad esempio una giornata intera di utilizzo normale partendo da una condizione di carica batteria del 100%.

    Modalità di installazione:
    copiare il file da testare nella cartella system/etc/init.d con permessi rwx r-x r-x

    grazie a tutti coloro che vorranno fare i test :)
     
    Ultima modifica: 9 Ott 2013
    A screech e fearless piace questo messaggio.
Status Discussione:
Chiusa ad ulteriori risposte.