[ROM] CyanogenMOD 7 para Galaxy S i9000 :: 7.2.0 Estable :: Nightlies :: Guia de referencia

[the_mente]

A mi me mosquea el consumo, con la Rom antigua gastaba eso 2-3% por la noche y ahora pareces que se ha disparado. También es verdad que estoy trasteando un güevo con el flasheo y tal, pero en fin...
Esta noche voy a controlarlo a conciencia.
Lo del modo avión es por no tenerlo pegao las 24 horas con cobertura, pa desintoxicarme un poco de radiaciones


Enviado desde mi Galaxy usando Tacatrá

[Gosnel]

yo siempre en modo avion por la noche y me gasta lo que hablais, no me mola eso de tener el movil cerca con cobertura mientras duermo...manías.

Incluso a veces sube un 1% jajaja, se autorecarga .

[edfar]

 Cita: Originalmente Escrito por SGS8.black

yo siempre en modo avion por la noche y me gasta lo que hablais, no me mola eso de tener el movil cerca con cobertura mientras duermo...manías.

Incluso a veces sube un 1% jajaja, se autorecarga .

a mi tambien me sube muchas veces hehehe, sobretodo despues de usarlo con un juego que pida bastante, luego sube, a lo consumo del coche

[Metzen83]

yo el wifi en casa no le apago ni de noche y me suele bajar un 5 %

[necrost]

en modo avion el wifi funciona.

[lmemperador]

quiero instalarme las google apps y no va la pagina q pone en el post 1
alguien sabe donde puedo conseguirlas?

hay algun problema conocido en bajar la cpu de velocidad maxima en el gobernador "on demand"? es que quisiera hacerlo, para ver si la batteria me dura mas

gracias

[rastafary]

 Cita: Originalmente Escrito por lmemperador

quiero instalarme las google apps y no va la pagina q pone en el post 1
alguien sabe donde puedo conseguirlas?

hay algun problema conocido en bajar la cpu de velocidad maxima en el gobernador "on demand"? es que quisiera hacerlo, para ver si la batteria me dura mas

gracias

funciona perfectamente el link que está puesto de las gapps

[kiku811]

Alguien sabe como poner en go launcher notification para que me diga el gmail que tengo correos sin leer, antes me lo decía pero desde que actualice a una version mas reciente no me lo.marca el gmail

Enviado desde mi GT-I9000 usando Tapatalk

[ryuko2002]

Yo con 3G y datos encendido en la rom stock me bajaba un 8-9%, cyanogen me baja más de un 15%. Si pongo 2G y quito los datos la stock me baja un 2-3% y cyanogen un 4-5%.
Después de una semana usando cyanogen el gasto de bateria es algo mayor que con rom stock pero mas o menos llego al final del día, además ahora tengo puesto solo 2G y cuando voy a navegar lo paso a 3G, con el acceso desde la pestaña de notificaciones es muy cómodo.

[lKBZl]

 Cita: Originalmente Escrito por ryuko2002

Yo con 3G y datos encendido en la rom stock me bajaba un 8-9%, cyanogen me baja más de un 15%. Si pongo 2G y quito los datos la stock me baja un 2-3% y cyanogen un 4-5%.
Después de una semana usando cyanogen el gasto de bateria es algo mayor que con rom stock pero mas o menos llego al final del día, además ahora tengo puesto solo 2G y cuando voy a navegar lo paso a 3G, con el acceso desde la pestaña de notificaciones es muy cómodo.

Es cierto que al usar los datos (3g etc) cm7 gasta más, pero si no los usas es bastante conservativa, y más si ala tienes bien xonfigurada.

Saludos.

Enviado desde mi GT-I9000 usando Tapatalk

[renedca]

Buenas a todos.
Me gustaria conocer , cual podría ser el Kernel que mejor le puede ir a esta Rom.
Ya que tengo 2.6.35.12-gdf10700pawitp con una XXjVK, se que se ha hablado mucho de esto , en este foro y en otros, pero si fuera el caso de cambiarlo, ¿como tendría que hacerlo? he estado viendo foros , pero no me aclaro muy bien, disculpar.
El problema que tengo es de batería, lo demas va fantástico... en 4 horas he pasado del 100% al 85%...
Un cordial Saludo a todos
renedca

[Metzen83]

quiero que leais todos un articulo de XDA que creo que todos deberiais leer, yo me lo he guardado hasta en favoritos para enseñarselo a todo el mundo repetidas veces si es necesario

http://forum.xda-developers.com/show....php?t=1297535

 Cita:

I recently had a discussion with someone regarding the benefits of screen-off profiles/daemons that put a limit on the CPU frequency while the screen is switched off for the sake of reducing the power consumption and thus prolonging the battery runtime. My argument was that putting a hard limit on the CPU frequency would rather have a detrimental effect of the battery runtime since this would hinder the CPU from racing-to-idle. I also argued that due to this race-to-idle effect, in general restricting the CPU frequency is not beneficial to the battery runtime and in contrast to intuition overclocking should reduce the average battery drain (as long as no disproportionate increase in voltage is necessary).

Since this is just theory and Morfic noted that his experience seems to indicate otherwise and that limiting the CPU frequency does actually decrease the battery drain, I put this theory to the test and logged the battery charge over 10h of FLAC playback in Airplane mode with the screen switched off.

As one can see, limiting the frequency to a maximum of 880MHz does indeed reduce the power consumption.

Thus it seems that race-to-idle does not properly work on this device. But why? The answer is that, while the technical manual showed that the hardware supports six different power states: NORMAL, IDLE, DEEP-IDLE, STOP, DEEP-STOP and SLEEP, a quick look into the source code revealed that (besides SLEEP) only the most rudimentary power saving state IDLE is actually implemented in the kernel. And for this IDLE state no parts of the hardware are powered down; the only thing that essentially happens is that the CPU clock is set to zero.

For the real power savings to kick in, one would have to power down parts of the hardware (at least the CPU) and that is exactly what the DEEP-IDLE state is supposed to do. Unfortunately this was not implemented. So, following the technical manual I tried to implement this DEEP-IDLE state on my own... and failed miserably. Well, not that miserably... at least I had an idea where the problem was. However I had no idea how to fix it since I did not know enough about the hardware details, had no experience working that close to the CPU and also the manual was far from instructive.

So I googled to maybe find someone smarter than me who had figured out a solution and found out that "some guys" already tried to implement this DEEP-IDLE state for the Galaxy S, however that did not work for some reason. I located the source code in some older version of sixstringsg's Glitch kernel, made some modification, put it into my reference kernel and everything is running fine for more than two days now.

I have repeated the above test runs on a kernel including the deep-idle state.

The battery drain is reduced to 17-18% compared to the 41%/46% (880MHz/1320MHz) obtained without deep-idle support. Thus the battery consumption is reduced by more than 55%. Also we see that with the kernel including deep-idle both 880MHz and 1320MHz yield almost the same average battery drain, showing that race-to-idle actually does work as long as the power saving features are properly supported. So, once these modifications are implemented in your favorite kernel, there should be no need for limiting the frequency anymore and you should be able to blast away without wasting a thought about the battery drain. Also, there is no reason anymore not to overclock your device, except of course the thermal limit of the device auto-incinerating in your hand.


Changes to the source code: http://www.pastie.org/2679956


BUGFIX:

1. While the screen is on, only the normal IDLE state is used.
2. Removed DEEP IDLE state with TOP=ON.
3. For the DEEP IDLE state with TOP=OFF, all external interrupt
wakeup sources except XEINT[30] (key input) are disabled and
all internal wakeup sources are disabled.

Bugfix: http://www.pastie.org/2686141


BUGFIX #2:

1. The reserved values of S5P_WAKEUP_MASK are not touched.
2. Only XEINT[22] = GPH2[6] = GPIO_nPOWER = GPIO_N_POWER and
and XEINT[29] = GPH3[5] = GPIO_OK_KEY are enabled as external
wakeup sources.
3. Only RTC TICK and I2S are enabled as wakeup sources.

Bugfix: http://www.pastie.org/2692199


BUGFIX #3:

For DEEP IDLE the same wakeup interrupt sources are used as for the
sleep state plus at least XEINT[22] = GPH2[6] = GPIO_nPOWER =
GPIO_N_POWER, XEINT[29] = GPH3[5] = GPIO_OK_KEY, RTC TICK and I2S.

Bugfix: http://www.pastie.org/2697909


BUGFIX #4:

Implemented a sysfs interface (/sys/class/misc/deepidle) for enabling/disabling the use of the DEEP IDLE state.

Bugfix: http://www.pastie.org/2709212


BUGFIX #5:

Fixed the BT problem and made sure the DEEP IDLE state is not used when the device is going to/waking from suspend (SLEEP).

Bugfix: http://www.pastie.org/2723702


BUGFIX #6:

1. Mimicking the procedure for the SLEEP state, when entering/returning
from the DEEP IDLE state, a notification is send to kernel modules
using 'pm_notifier_call_chain'. This will cause CPUfreq to statically
set the frequency to SLEEP_FREQ and prevent further frequency changes
until the system returns from DEEP IDLE.
2. The APLL lock is not modified.

Bugfix: http://www.pastie.org/2744527


BUGFIX #7:

Fixed GPS problems.

Bugfix: http://www.pastie.org/2775884


BUGFIX #8:

The DEEP IDLE with TOP=ON is used while GPS or BT are running.

Bugfix: http://www.pastie.org/2778855


BUGFIX #9:
Notifications using 'pm_notifier_call_chain' when entering/leaving DEEP IDLE have been removed.

Bugfix: http://www.pastie.org/2796786

Test kernel: http://www.multiupload.com/K8ZXS5HTLS
For each of the different idle states, the number of idle calls and the total amount of time spend in each state are saved. These stats can be shown using 'idle_stats' in the sysfs interface and resetted with 'reset_stats'.

Bugfix: http://www.pastie.org/2779930


BUGFIX #10:

1. Changed stats variables to 'unsigned long long' to defer overflow and keep the idle times in us for increased accuracy.
2. In case of an overflow of one of the stats variables, all stats are resetted.
3. Put in a mutex to prevent simultanous access to the stats variables.

Bugfix: http://www.pastie.org/2788087


BUGFIX #11:

Notifications using 'pm_notifier_call_chain' when entering/leaving DEEP IDLE have been removed.

Bugfix: http://www.pastie.org/2796786


BUGFIX #12:

Removed RTC TICK as wakeup source and added RTC ALARM.

Bugfix: http://www.pastie.org/2805119


BUGFIX #13:

Added ST as wakeup source.

Bugfix: http://www.pastie.org/2815223


BUGFIX #14:

Added KEY as wakeup source.

Bugfix: http://www.pastie.org/2815884


No further patches will be published here. I have set up a git repo for all my tweaks. Each mod has its own branch to keep the tweaks cleanly separated and one can simply pull the latest patches from the corresponding branch.

https://github.com/Ezekeel/GLaDOS-nexus-s/tree/deepidle


As I said above, this code is almost entirely written by "some other guys". I just made some improvements and extensions to it. Unfortunately I have no idea who these great people are, so I cannot give any credit (yet). However I asked sixstringsg and he told me he would ask around.


CAM bug

There is a bug in the Google Talk app with video-chat which causes the CAM submodule to be activated on boot. As a consequence the DEEP IDLE state will not be used. Opening the camera app once and then closing it, shuts down the CAM module so after that the DEEP IDLE state will be used properly. The Talk version without video-chat does not have this issue. Unfortunately both version are shown as Version 1.3 in the application info, however the app size differs (740KB with video-chat, 500KB without video-chat) as well as the permissions (with video-chat additionally has the permission 'Hardware controls').

without video-chat:



with video-chat:



A big thank you to FloHimself for tracking down the problem!

[edfar]

muy interesante, yo nunca limito los maximos mhz ya que no me hace falta, pues durante la noche me gasta muy poco. En todo caso solo lo oceo un poco para algun juego concreto.
Pero está bien saber esto ya que como se ve, cuando esta en profunda inactividad consume menos a 1300 que a 880.

PD: por otra parte, es de un kernel del nexus S, no se hasta que punto es comparable con el nuestro

[lmemperador]

lo del kernel suena bien, supongo q no tenemos ningun kernel asi para cm7 verdad?

[Metzen83]

el nexus s es practicamente igual al sgs
y de todos modos eso vale como referencia para cualquier movil

[sir asistant]

que parado está el changelog D:

[Ne0x]

Alguien puede pasarme la web con las versiones kang que se van compilando? Se me han borrado los favoritos :S

[the_mente]

 Cita: Originalmente Escrito por Ne0x

Alguien puede pasarme la web con las versiones kang que se van compilando? Se me han borrado los favoritos :S

http://nethq.org/cmsgs

[Metzen83]

que raro...antes me aparecian todas mis aplicacioens instaladas en el market en aplicaciones, y ahora no... al navegar por el market me las encuentro como instaladas, pero no estan en la lista...
ya hice lo de reparar enlaces con el titanium, y sigue igual

se os ocurre que peude ser? porque vi en el changelog una modificacion que decia:
Fix Galaxy S 1 & 2 devices market filtering (android_vendor_cyanogen)

y lo mismo eso me jorobo el market..

[the_mente]

Has probado lo más básico?
Ajustes/aplicaciones /administrar aplicaciones/todo/market y borrar datos.
A veces nos vamos a lo más complicado y es una tontería.
A mi eso nunca me ha fallado cuando cambio de Rom, después de borrar datos al entrar en el market aceptas la licencia cómo la primera vez y te vuelcan todas tus aplicaciones


Enviado desdel infinito y más allá