[hlte][2014/DEC/07][CM11/12] Yank555.lu kernel v1.1c-beta6

[ryanrazer]

Right. I tested, works as you said. Thanks for reply and you work!

Cheers

[ryanrazer]

I can't say it works perfectly. Sometimes it has problems adjusting screen brightness. Sliding the bar in notification drawer does nothing, so doesn't adaptive brightness(i think kernel has to do with this) and screen wake doesn't work properly(sometimes)... I press home or power button and nothing happens, then i press again and screen turns on and off right away. Sometimes just soft buttons light up...

I behaves weird. Most of the settings i left on default with your setup, except max cpu freq i lowered a little and screen color tone...

[Xavihernandez]

Well good experience with v1.1b, cannot really gauge battery life but it seemed to be really good. Had a ssp wakelock today, a reboot fixed it. Also LED notifications seem to be broken. Gonna flash v1.1c and try intellimm.

[yank555]

I can't say it works perfectly. Sometimes it has problems adjusting screen brightness. Sliding the bar in notification drawer does nothing, so doesn't adaptive brightness(i think kernel has to do with this) and screen wake doesn't work properly(sometimes)... I press home or power button and nothing happens, then i press again and screen turns on and off right away. Sometimes just soft buttons light up...

I behaves weird. Most of the settings i left on default with your setup, except max cpu freq i lowered a little and screen color tone...

Brightness isn't really handled in the kernel (ROM set a value, kernel changes backlight, but ROM has the 'intelligence'). Though the adaptive brightness may be 'strange', when acrive it will just shift the brightness (little less or little more), but once you are at min or max, given the ambient light, it can't go past min/max, so it's normal that it doesn't seem to work then.

As for your wake issues, as posted already, if you want faster wakeup, set screen off max to 2.3GHz and you'll have stock behaviour. Using a limited screen off max has a price, that is the price

Well good experience with v1.1b, cannot really gauge battery life but it seemed to be really good. Had a ssp wakelock today, a reboot fixed it. Also LED notifications seem to be broken. Gonna flash v1.1c and try intellimm.

Interesting, there are no LED related changes between CM11 and 12, neither in the kernel nor the ROM from what I know ... but I can't really comment othe than seeing the led blink on mine, haven't paid special attention to that.

What exactly is broken about them ?

If there is an issue there, 1.1c will not solve anything, though, intellimm is certainly worth the update

JP.

Sent from my Nexus 5 running SlimLP 5.0-alpha5 on Yank555.lu SlimLP v1.2-alpha1 kernel.

[Xavihernandez]

Yep I am testing intellimm at the moment.

Well LED does not blink when I have a new notification.
It works when charging my device though.
May be related to application I use. For SMS/MMS I use Smitten because CM Messenger lacks some feature for now. I use WhatsApp+ which notifies messages too. These are the two applications that notify me.

When I go to settings > sound and notifications and I test LED blinking it does blink (white color).

Another question : I have always disabled "Adaptive brightness" so I don't really know how it works. Does it lower the minimum brightness when there is no light, and increase minimum brightness when there are too much light? On a side it is a great feature which can lower the brightness, but on another side it sucks that it increase brightness when it (the adaptive brightness control) thinks that it is not high enough.

[yank555]

Yep I am testing intellimm at the moment.

Well LED does not blink when I have a new notification.
It works when charging my device though.
May be related to application I use. For SMS/MMS I use Smitten because CM Messenger lacks some feature for now. I use WhatsApp+ which notifies messages too. These are the two applications that notify me.

When I go to settings > sound and notifications and I test LED blinking it does blink (white color).

Does it behave differently on stock/default kernel ? As I don't quite see what the kernel could do, it doesn't know who requests LEDs, ROM manages that. On a kernel level, it should either be, no LEDs, or LEDs

Another question : I have always disabled "Adaptive brightness" so I don't really know how it works. Does it lower the minimum brightness when there is no light, and increase minimum brightness when there are too much light? On a side it is a great feature which can lower the brightness, but on another side it sucks that it increase brightness when it (the adaptive brightness control) thinks that it is not high enough.

Look at it like this :

Min backlight value = 0
Max backlight value = 255

Given the input from light sensor, the ROM will ask the kernel to set the backlight to anything from min to max.

With adaptive mode on or off, you can never go neither below 0 nor above 255, since those are physical min and max.

What you will do moving the brightness scale is just change how the calculation is done between measured lux from the light sensor to convert it to the actual backlight.

So if you find default (central position) to be generally too bright, lower it and the result in same ambient light will be lower.

Now if you find default to be generally too dim, raise it, and the result in the same ambient lght will be higher.

BUT !

If you are in a very light or very dark environment, you will hit min / max with whatever position you set it to, so it looks like it's not working.

Mathematically put it's more or less like this :

X = requested backlight (say 0-255)
Y = measured ambient light (say 0-255)
Z = your setting for adaptive (say -50 to +50)

X = Y + Z

But if Y = 0 (dark), X can not be -50 and will be 0 in any case.

If Y = 255 (bright sunlight), X can not be 305 and will be 255 in any case.

They could have made it more complex to make it look like the scale works in any light conditions.

In essence, test that thing only in "medium" ambien light, neither in the dark, nor in the bright sun.

JP.

PS: This also nicely explains what sub-zero'ing is in Lux (app), it will use a semi-transparent overlay, to darken the colors, so it looks as if the screen was being dimmed "below 0", when in fact the backlight is at 0 and the screen content is darkened by a "gray or brown" semitransparent overlay.

[Xavihernandez]

Yep I am testing intellimm at the moment.

Well LED does not blink when I have a new notification.
It works when charging my device though.
May be related to application I use. For SMS/MMS I use Smitten because CM Messenger lacks some feature for now. I use WhatsApp+ which notifies messages too. These are the two applications that notify me.

When I go to settings > sound and notifications and I test LED blinking it does blink (white color).

Does it behave differently on stock/default kernel ? As I don't quite see what the kernel could do, it doesn't know who requests LEDs, ROM manages that. On a kernel level, it should either be, no LEDs, or LEDs

Another question : I have always disabled "Adaptive brightness" so I don't really know how it works. Does it lower the minimum brightness when there is no light, and increase minimum brightness when there are too much light? On a side it is a great feature which can lower the brightness, but on another side it sucks that it increase brightness when it (the adaptive brightness control) thinks that it is not high enough.

Look at it like this :

Min backlight value = 0
Max backlight value = 255

Given the input from light sensor, the ROM will ask the kernel to set the backlight to anything from min to max.

With adaptive mode on or off, you can never go neither below 0 nor above 255, since those are physical min and max.

What you will do moving the brightness scale is just change how the calculation is done between measured lux from the light sensor to convert it to the actual backlight.

So if you find default (central position) to be generally too bright, lower it and the result in same ambient light will be lower.

Now if you find default to be generally too dim, raise it, and the result in the same ambient lght will be higher.

BUT !

If you are in a very light or very dark environment, you will hit min / max with whatever position you set it to, so it looks like it's not working.

Mathematically put it's more or less like this :

X = requested backlight (say 0-255)
Y = measured ambient light (say 0-255)
Z = your setting for adaptive (say -50 to +50)

X = Y + Z

But if Y = 0 (dark), X can not be -50 and will be 0 in any case.

If Y = 255 (bright sunlight), X can not be 305 and will be 255 in any case.

They could have made it more complex to make it look like the scale works in any light conditions.

In essence, test that thing only in "medium" ambien light, neither in the dark, nor in the bright sun.

JP.

PS: This also nicely explains what sub-zero'ing is in Lux (app), it will use a semi-transparent overlay, to darken the colors, so it looks as if the screen was being dimmed "below 0", when in fact the backlight is at 0 and the screen content is darkened by a "gray or brown" semitransparent overlay.

Ok, thanks for you attention and your answer.

Well about LED blinking, I ask you that because this forum is less polluted than on xda... Ad yes I think it is ROM-side or something like that because it didn't work neither with temasek kernel.

About "adaptive brightness" thanks for clarification, I got it! Well for my use better to leave it disabled .

About Lux app I was wrong some months ago, because thought that this application was able to go to subzero brightness. But made my knowledge again about screen technology, and learnt that it was just a filter. Battery friendly for AMOLED screen though.

[yank555]

Well about LED blinking, I ask you that because this forum is less polluted than on xda... Ad yes I think it is ROM-side or something like that because it didn't work neither with temasek kernel.

I suppose it could be part of code for notification LED override (SlimLP has that already), allows you to override what the apps asks, like force G+ to always blink slow in green, even if the app doesn't ask for that... but that's just me wild guessing here, Temasek would certainly know more on that end

About "adaptive brightness" thanks for clarification, I got it! Well for my use better to leave it disabled .

I don't use it, I use Lux, as I've always been using, and Lux switches that off anyway

About Lux app I was wrong some months ago, because thought that this application was able to go to subzero brightness. But made my knowledge again about screen technology, and learnt that it was just a filter. Battery friendly for AMOLED screen though.

Yep, on Amoled it's indeed juice-saving, not on the Nexus 5, though, there we have LCD pannels and lowest is just lowest. But still, lowest is just too bright for me in pitch dark, and that's how I mostly use my device actively, in the evening when on the couch watching TV

JP.

[Xavihernandez]

I suppose it could be part of code for notification LED override (SlimLP has that already), allows you to override what the apps asks, like force G+ to always blink slow in green, even if the app doesn't ask for that... but that's just me wild guessing here, Temasek would certainly know more on that end

Oh okok I'll read on forum, and wait anyways.

I don't use it, I use Lux, as I've always been using, and Lux switches that off anyway

I did use it before. Waht are your "update" setting? First I tried "dynamically" but it seems to suck some juice... So I switched it to manual and used "+" and "-" button in status bar. And then i uninstalled it and just used Screen filter with static value and on/off widget.

Yep, on Amoled it's indeed juice-saving, not on the Nexus 5, though, there we have LCD pannels and lowest is just lowest. But still, lowest is just too bright for me in pitch dark, and that's how I mostly use my device actively, in the evening when on the couch watching TV

JP.

Yep even if it is not a battery saver for LCD it can be an eye saver for the owner

[yank555]

I did use it before. Waht are your "update" setting? First I tried "dynamically" but it seems to suck some juice... So I switched it to manual and used "+" and "-" button in status bar. And then i uninstalled it and just used Screen filter with static value and on/off widget.

Well I have it set to dynamic, indeed, using "Medium" as poll rate, on the Nexus that is, I think on the Note I used to have the pollrate set to "Slow". Can't say I notice any huge battery issue with it, as I get a 3-5h SOT on the Nexus at 2.5GHz, which pretty decent for the tiny battery given it's the same SOC as the Note 3

Yep even if it is not a battery saver for LCD it can be an eye saver for the owner

Oh yes it is

JP.