[DEV/help] changer de mode batterie/performance sous X10mini, X10miniPRO et X8

[matmutant]

voici un projet de support de mon script pour les X10miniPro et X8,

sujet original

le but du script est de changer les fréquences min et max du processeur ainsi que sa politique d'utilisation et d'activer ou désactiver l'undervolt, le tout en un clic

pour l'instant son utilisation sur mini PRO nécéssite d'editer le script et changer x10miniuv par x10miniprouv et x8uv

le but est maintenant de rendre le script capable de le faire seul, via le build.prop

mon problème est que je ne sais pas récupérer de valeur de manière automatique à l'aide du script, d'où ma demande d'aide :)

des idées de méthode?

Modifié 10 janvier 2012 par matmutant

[matmutant]

grand merci à nAa pour son aide :

la réponse était simple : grep ro.product.name /system/build.prop

donc :

PRODUCT=`grep ro.product.name /system/build.prop`
# finding product name
if [ "$PRODUCT" == "ro.product.name=E10i" ]
then
MODULE="x10miniuv"
elif [ "$PRODUCT" == "ro.product.name=E15i" ]
then
MODULE="x8uv"
elif [ "$PRODUCT" == "ro.product.name=U20i" ]
then
MODULE="x10miniprouv"
else
echo -e "\033[1;31m unsupported device"
sleep 1
#script will exit
exit
fi
# displaying device and UVmodule name
echo "your device is a : $PRODUCT"
echo "UV module name : $MODULE"

y a t'il un pocesseur de X10minipro ou X8 qui voudrait bien tester le script?

à télécharger ici, et suivre la procédure du sujet original pour le tester

à tester :

si le module UV est bien activé/désactivé

si le nom du modèle est bien le bon

si le nom du module est bien le bon

voilà

merci d'avance

Modifié 10 janvier 2012 par matmutant

[FrenchKoR]

Salut,

Je viens de le tester, l'écran m'affiche le logo (M@) en rouge, suivi du message "unsupported device".

Du coup, après vérifications, aucun changement à noter au niveau des paramètres CPU.

J'ai pourtant bel et bien la ligne "ro.product.name=U20i" dans le build.prop, et après un echo la valeur de $PRODUCT me le renvoie sans faute.

Il y a sans doute une erreur à la ligne suivante :

elif [ "$PRODUCT" == "ro.product.name=U20i" ]

Mais je ne vois pas laquelle. J'ai essayé de retirer les guillemets autour de la variable (habitude du php), mais que nini.

Edit : j'utilise CoolFlame, une ROM que j'ai directement basée sur celle de nAa, donc à priori aucun soucis venant de là. Au passage, les modules changent selon la ROM et dans la plupart des ROMS 2.3 le module uv se nomme directement "x8uv.ko".

Modifié 11 janvier 2012 par RoK

[matmutant]

étrange, je pense pas que ça soit une erreur de syntaxe...

tu peux editer le script et tenter sans la clause "if" de recherche du modèle?, et en remplaçant la variable module par le vrai nom du module? juste pour au moins tester le reste du script

place des des # devant toute la partie de code postée plus haut :)

nAa a testé sur x8, ça fonctionne

je vais lui demander son aide pour trouver le probleme :) (encore et toujours :P)

je savais pas pour la rom, dans un premier temps ça sera donc uniquement compatible avec les rom basées sur miniCM7 ...

edit : d'ailleurs, un build.prop de X10minipro et X8 me serait utile :)

edit2 : la nouvelle version sera théoriquemment compatible avec outes les roms, quelque soit le nom du module !

version test bientot prete :)

Modifié 11 janvier 2012 par matmutant

[matmutant]

voila

MODULE=`basename /system/lib/modules/*uv.ko | sed 's/\.ko//'`

grosse opti du script (réduction de 105 à 75 lignes)

fonctionne sous e10i, et e15i (miniCM7)

doit pouvoir foncionner sous n'importe qu'elle custom rom (le nom du module n'a plus d'importance s'il fini par "uv.ko") et n'importe lequel des modèles suivants : e10i, e10a, e15i, e15a, u20i, et u20a

donc à tester : possesseurs x10minipro et x8, avec ou sans miniCM7 (seulement si OC inclus dans le kernel)

il n'y a donc plus qu"un seul script pour tout les modèles cités; reste ensuite à voir les fréquences et governor que vous voulez.

merci RoK pour ta précision sur le nom du module: c'est de là qu'est partie l'idée d'universaliser la commande;)

d'après nAa, i n'y avait aucune raison qu'il t'apparaisse "unsupported device" d'après le contenu de mon script, le mystère reste entier :P

lien de test ICI

[FrenchKoR]

Alors je passe bien du mode Scary à Interactivex, ça fonctionne nickel, en revanche je ne note pas de changement sur l'undervolt (jute sur la méthode de CPU et les fréquences).

J'ai également ce bug :

you're running from 122880 to 691200 Hz

current governor is interactiveX

setting cpuclock from 320 to 748MHz

disabling UnderVolt

rmmod: ./proc/1447/task/1779/fdinfo/226: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/230: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/243: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/247: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/248: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/249: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/251: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/255: No such file or directory

rmmod: ./proc/1447/task/1779/fdinfo/257: No such file or directory

rmmod: ./proc/4046: No such file or directory

setting governor to Scary

running module(s) :

tiwlan_drv 508828 0 - Live 0xbf00a000

sdio 19028 1 tiwlan_drv, Live 0xbf000000

you're now running from 320000 to 748800 Hz

current governor is Scary

you can close that window now :)

support available @ XDA-developpers[/code]

Edit : Ok c'est parti, je continue les tests. ;)

Modifié 11 janvier 2012 par RoK

[matmutant]

j'ai également ces warning..

d'apès nAa on ne peut rien y faire :c'est le kernel qui s'amuse, il faudrait relire toute sa source pour trouver d'où ça vient et il n'a pas le temps; de toute manière ça n'a aucune conséquence sur le déroulement de l'opération de rmmod du module :)

je vois que tu était en wifi :P et que pour toi aussi le rmmod fonctionne; donc pas de probleme :)

Modifié 11 janvier 2012 par matmutant

[FrenchKoR]

Ah ! Là, mon téléphone a été correctement reconnu, une bonne chose de réglée. J'ai l'impression que c'était le if / elsif qui merdait.

Command:

'/mnt/sdcard/switch_clock-12-01-11-122-691ix-320-748sALL.sh'

-------------

Out:

you're running from 122880 to 691200 Hz

current governor is ondemand

setting cpuclock from 320 to 748MHz

disabling UnderVolt

rmmod: ./proc/4363: No such file or directory

rmmod: ./proc/4982: No such file or directory

rmmod: ./proc/5051: No such file or directory

rmmod: remove 'x10miniprouv': No such file or directory

setting governor to Scary

running module(s) :

tiwlan_drv 508828 0 - Live 0xbf00a000

sdio 19028 1 tiwlan_drv, Live 0xbf000000

you're now running from 320000 to 748800 Hz

current governor is Scary

you can close that window now :)

support available @ XDA-developpers

Command:

'/mnt/sdcard/switch_clock-12-01-11-122-691ix-320-748sALL.sh'

-------------

Out:

CPU minMAX frequency & governor swithcher by m@

version 12.01.11 DEV!!!! --> all devices support

you're running from 320000 to 748800 Hz

current governor is Scary

setting cpuclock from 122 to 691MHz now

enabling UnderVolt

setting governor to interavtiveX

running module(s) :

x10miniprouv 1180 0 - Live 0xbf007000

tiwlan_drv 508828 0 - Live 0xbf00a000

sdio 19028 1 tiwlan_drv, Live 0xbf000000

you're now running from 122880 to 691200 Hz

current governor is interactiveX

you can close that window now :)

support available @ XDA-developpers

Toujours des petites erreurs venant, j'imagine, du Kernel comme tu l'as stipulé plus haut. En revanche, le "enabling UnderVolt" ne fonctionne pas puisqu'après vérification l'UnderVolt est toujours désactivé.

Pour le reste, nickel !

[matmutant]

setting cpuclock from 122 to 691MHz now

enabling UnderVolt

setting governor to interavtiveX

running module(s) :

x10miniprouv 1180 0 - Live 0xbf007000

tiwlan_drv 508828 0 - Live 0xbf00a000

sdio 19028 1 tiwlan_drv, Live 0xbf000000

??

ça a l'air de marcher pourtant d'après l'output .. nan?

Modifié 11 janvier 2012 par matmutant

[FrenchKoR]

Oui le log semble indiquer que l'uv est activé, mais dans les paramètres de performances la case n'est pas cochée (alors que pour les autres valeurs, chaque paramètre se trouve effectivement changé).

Modifié 11 janvier 2012 par RoK

[matmutant]

oui c'est normal :)

il n'est pas possible de "cocher" la case :P

donc pour savoir s'il est ou non activé :

tape

lsmod

je vais donc libérer cette version sur XDA ;) et ensuite, bonne nuit :)

[FrenchKoR]

Effectivement, après un adb shell lsmod je vois bien le module présent / non présent selon la configuration du script, je n'ai donc rien dit. ;) Il fonctionne parfaitement !

Après ça aurait été mieux que cela influe sur les paramètres également (par soucis de propreté on va dire, vu que du coup je suis "obligé" de désactiver l'undervolt via ton script ou l'activer / redésactiver par les paramètres au cas où). Mais c'est plus qu'un détail.

Beau travail. ;)

[matmutant]

je ne peux pas cocher cette case dsl (ça m'embète aussi^^)

en fait je pense que lorsque nAa à créé cette option, il a pensé "clic sur case > dé/coche + action" mais pas sa réciproque, en effet l'action n'induit pas le cochage de la case; mais je ne crois pas qu'il le changera un jour (beaucoup de travail pour pas grand chose :P)

ce "détail" risque de s'éterniser ^^)

merci pour ton aide :)

[matmutant]

CPU minMAX switcher script 12.01.12 is out!

the aim of this work is to easily switch between two overclocking frequencies and governor' date=' the first for every day use and battery saving (with UV enabled), the second for performance (with UV disabled)

it should support e10i, e10a, e15i, e15a, u20i, and u20a, regardless of the rom (custom rom+kernel)

requirements :

- OC in kernel, (custom kernel only, it has been made for nAa's, so i don't know behavior on other kernels)

- one of the previously written devices,

- undervolt module installed

--> if you are running on any miniCM7 based rom, it should work perfectly :)

direct link to script: here here

link to original thread: here

changelog:

• now supports e10i, e10a, e15i, e15a, u20i, and u20a, regardless of the rom (custom rom+kernel)
  
• doesn't care about UVmodule's name (thx FrenchKoR for idea and nAa for huge help in succeeding to make it work)
  
• script size quitely resized
  

i need your suggestions to make three scripts, with three different max freq (optimized for e10, e15 or u20) and favorite governor for battery life and performance

the actual one is optimized for my e10 and its own characteristics in term of OC stability

[FrenchKoR]

Wow, j'ai même le droit à un remerciement. xD

Beau travail matmutant, j'espère que c'est le début d'une longue série de scripts. L'idéal serait de le rendre autonome, sans passer par un apk externe. On parlait avec Syntax Error² d'intégrer un système de smart actions dans la ROM (l'idée serait, à titre d'exemple, un script constamment activé qui détecterait le branchement des écouteurs et lancerait automatiquement le lecteur de musique). Ce genre de trucs se retrouvent sur la nouvelle gamme de Motorola, et franchement ça peut apporter un plus non négligeable. Je ne sais pas si c'est facile à faire, mais ça peut te donner une piste sur laquelle travailler.

Bref, si tu as besoin de quelqu'un pour les tests je suis toujours opérationnel !

[matmutant]

en tant que mon unique testeur et donneur d'idées c'est normal ;)

pas idiot comme idée les "smart actions" :)

j'ai dans l'espoir de faire une apk ou un widget pour remplacer le script... mais bon, je ne suis pas capable de coder en java pour l'instant, donc j'ai abandonné cette idée.

sache que les écouteurs sont déja détectés instantanément (tu vois l'icone qui s'affiche quand on les branche) il y a donc une action qui est déjà associée au branchement, donc... pk pas deux?

je vais en parler à nAa, il aura surement une idée pour la réalisation ;)

d'autres projets comme smart actions?

m@

PS: un script qui tourne en permanence est un tueur de batterie :P

[FrenchKoR]

Effectivement je me suis mal exprimé, c'est plutôt mauvais un script qui ne s'arrête pas. Mais bon tu m'as compris. :P

Non en dehors de ça, je n'ai pas d'idées particulières. Mais c'est vrai que l'exemple des écouteurs pourrait en faire une bonne base, puisqu'il suffirait de compléter le code qui y est associé en rajoutant une commande d'ouverture du lecteur de musique. A partir de ça, on pourra compléter en automatisant davantage d'actions (en collectant différentes idées).