View Single Post
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#793
Originally Posted by joerg_rw View Post
Don't mess with the *current files! The 50 there are a sane value, and you may KILL YOUR LEDS by setting it to unrasonable values.
I said nothing about changing "led_current" beyond the fact that I thought he might be thinking of that (because at the time I had only seen the led_current thing have any effect). I keep my keyboard led_current values at the stock 50, and am just fine with it, nor have I advised anyone to change it. My boot-shell /sbin/preinit script touches only the brightness value, not the led_current value.

P.S. I appreciate the informativeness, but many people don't read things fully or properly, and I'm sure there's readers who would've combined a skimming of my post and a skimming of your post to suppose I was doing something damaging with my press-any-key-for-shell at boot script.

(Do you know if NITDroid is using higher led_current values? Or does NITDroid actually do it by brightness? Because there are posts on this forum suggesting using led_current to force keyboard to be as bright as it is when NITDroid is booted. I haven't heard anyone yet say their leds are malfunctioning, but like overclocking, it's probably one of those matter-of-time things. Honestly, this is what happens when software/hardware makers don't give users proper control over aspects of hardware - since during normal after-MCE-kicks-in operation led_current is the only way to make the brightness higher for a minimally command-line capable person, that's what people will naturally turn to.)

Originally Posted by joerg_rw View Post
dbrightness is an absolute nonsense only existing in powerkernel and to all my knowledge causing more problems than good.
Hmm. So that's where that came from. Near as I can tell it just always makes the brightness value equal to itself, unless set to -1, which it always is by default on my device. Do you know what Titan's reasoning was for including/implementing it?

Originally Posted by joerg_rw View Post
it's the brightness files that control kbd backlight, and yes they are overridden by mce which controls them every few seconds and every keypress and touchscreen event usually.
So in practice, we're at what I said earlier "brightness files control kbd backlight in early boot, and something else takes over later". (But now I know it's mce that does the controlling from there, and that the brightness files really do still control the keyboard, they're just zealously overriden; so thank you. MCE is closed source, right?)

Originally Posted by joerg_rw View Post
pro-tip: add a "sleep 5" to the "for x in 1 2 3 4 5 6...." cmd's head, when entering it via device kbd. Or simply use remote ssh to enter the comd. You'll see it works - for a while (max 30s iirc), until mce resets it anyway
Indeed it does. Very informative bit of advice (since the same logic probably helps figure out issues in plenty of other scenarios.
 

The Following User Says Thank You to Mentalist Traceur For This Useful Post: