Minimum brightness level is too low and totally turns off backlight

2

On my Dell Latitude E6400, the minimum brightness level seems to be set to an incorrect and way too low level; the lowest brightness setting (both via the Fn+Up/Down keys and the control panel/mobility center) totally turns off the backlight, where I would expect it to still have a slight backlight.

The problem is that this messes up the adaptive brightness service; when the light sensor doesn't detect any light it sets the backlight to the lowest level, except the lowest level is a total absence of backlight and that makes the adaptive brightness totally unusable.

Edit: the adaptive brightness problem is (hopefully) solved with this ALR curve, but the question still stands - it shouldn't be possible (nor useful) to lock yourself out of the machine by not being able to read anything on the screen (the Fn keys aren't reliable enough and sometimes don't work after standby, thus you need to blindly open up the mobility center and set the brightness back up a bit).

I have the latest BIOS (version A34 if I remember correctly), and I installed the latest Intel display drivers, nothing changed. I'm looking for a registry hack or something that can change the lowest brightness level to something higher, where the backlight will still be active.

user256743

Posted 2014-09-14T16:48:34.330

Reputation:

The default expectation for keyboard backlight brightness is for the lowest setting to turn off the keyboard backlight. That's true in a majority of systems. It differs from screen brightness, in this way, because screen brightness often will not shut off the display at the lowest setting. Is there an option in the adaptive brightness service to raise the minimum level? – James Brewer – 2014-09-15T20:26:10.897

@JamesBrewer thanks to Microsoft it's hardcoded in the default Adaptive Brightness service. I am able to change the ALR curve (the function that maps sensor brightness to screen brightness) but 0 sensor brightness is always 0 screen brightness no matter what. – None – 2014-09-15T20:28:28.173

The ALR table should allow you to set a minimum offset percentage based on illuminance level (measured in lux). Because it's a percentage, as long as you don't set it to 0%, it should still light up (ex: 0 lux, 1% offset vs 3000 lux, 200% offset). Bear in mind that the offset must increase as illuminance increases (curve must be a positive, upward trend) – James Brewer – 2014-09-15T20:56:36.807

@JamesBrewer I've tried it as described in this answer of mine, however I still couldn't get it working right and finally gave up on it. Do you have a working ALR curve with such offset by any chance ? (or a verified working example, because my attempts didn't work quite well and I always ended up with a black screen)

– None – 2014-09-15T21:00:41.163

You've definitely done plenty of research on the subject. I perused the ALR points you posted onto pastebin, and noticed that the lowest value is set for 0% baseline brightness (or 100% reduction/black screen). The question I have is whether the hex offsets in that registry value are read from left to right or right to left. In the case of the former, you're looking at a black screen in any lighting lower than 268,435,456 lux, or 2100 times the solar illuminance constant of unfiltered light from Sol. Either way, I would bump that offset up to 0A (10%)

– James Brewer – 2014-09-15T21:26:50.863

@JamesBrewer first off we're not talking about lux, on my system it's just an arbitrary value from 0 (darkness) to 255 (flashlight says hello to light sensor), and the lowest value is 00,00,00,10 (the first 00 is some sort of padding and should be ignored). I'm gonna do some more testing. – None – 2014-09-15T21:35:39.967

Then, you're saying the value can only be 00:00:00:00 through 00:00:00:FF? Also, if the first octet (00) should be ignored, then the last three octets in the sequence also don't line up, and there's a mismatch in the pairs. See here my association of the 4-octet strings to pairs

– James Brewer – 2014-09-15T22:00:08.850

@JamesBrewer no, but in my case there is no need to go over FF since that's the max value returned by the sensor and I don't need to go over 255% of the normal brightness. Actually I just tried the ALR curve I came up with in my linked answer and it seems to work nicely. – None – 2014-09-15T22:11:37.510

1

@JamesBrewer thanks for trying to help, here's the slightly modified ALR curve that currently works, let's hope it stays that way. This question still stands since it's pretty annoying to be able to turn the brightness too low and lock yourself out of the machine (the Fn keys sometimes stop working after standby/sleep).

– None – 2014-09-15T22:24:57.700

Answers

0

In case there's someone still interested in this, there is a solution. This solution might be shooting a bird with a cannon, but it should work.

First off, with NirCmd, create a batch file that increases the brightness by a certain amount. Then, go into the event viewer, and under Applications and Services>Microsoft>Windows>Diagnostics-Performance click on the "operational" log. In there you should find an event where it says "Windows has resumed from standby" (on Windows 7 the event code is 300, and my guess is that it would be the same on newer versions of Windows). Attach a task to one of those events, and then set that task to be the batch file you created earlier. Then, whenever you resume your system, the brightness will be increased by the amount specified so that you don't have to hunt around in the dark.

trainman261

Posted 2014-09-14T16:48:34.330

Reputation: 311