You are not alone. This problem walks the line between hardware and software. Yes, "this is a software or hardware problem" in many models. I believe LeNOvo produces electronicrap compujunk.
Until ten years ago, one of the engineering decisions which made ThinkPad, ThinkPad, was hardware functions controlled by Embedded Controller (EC). And, BIOS/firmware which was generally superior. Screen brightness and audio amplifier controls (wheel, slider, keyboard, or dedicated volume button) were seemingly 'hard controls'. By 'hard controls' I mean, they worked such that they were indistinguishable from hardware control.
Let me go into more detail about audio volume control in 'ThinkPad 2000'. Volume buttons in
lovely X22 and X30 were not actually literal hard-implemented hardware controls, but 'digital buttons'. To be true pureblood hard-control, would require being wired to DAC. They were wired to
Embedded Controller, same as keyboard matrix. The EC is a computer embedded inside of the larger 'IBM ThinkPad Personal Computer'. So even if: video games made Intel processor overheat and freeze, malware made Windows crash, hardware fault or scratched CD leads to half-second of audio stuck in a loop; volume buttons still work, allow user to change volume. It is of course possible for EC software to crash, but I never read any report of such occurrence. In 'ThinkPad 2000',
mute means mute. And brightness keys control brightness.
Off topic: Apple laptops are opposite. Since first PowerBook, brightness and other hardware functionality is controlled by OS/software. IIRC, I think I read something like: brightness buttons produce an interrupt, so that during low battery condition, despite user's desire, System Software knows better and limits brightness to low. (Something like that. Not a quote. Do not believe me.)
It would seem, ThinkPad 2000 contains Renesas H8S/216x Embedded Controller, and ThinkPad 2006 contains Renesas H8S/2116V. In T61 and X61 models ('ThinkPad 2007'),
mute does not mean mute. Those three volume buttons, ThinkVantage button, and keyboard matrix, all go to EC, like ever. EC takes key presses and outputs PC AT keyboard events ('PS/2 bus'), like ever. But unlike ThinkPad 2000, EC does not send message to DAC when volume buttons pressed; EC treats volume buttons same as keyboard keys. Now, it is up to Operating System or user software to do something. ThinkPad volume buttons are no different than external HID (human interface device).
- Sometimes, volume mixer code will be swapped/paged-out, so there is a few-second delay before mute means mute.
- Sometimes, user thinks "huh, nothing happened, I'll press it again", so by the time software reacts, mute means 'mute and immediately un-mute'.
- Sometimes, an application will request HID volume events and OS hands them over, so when Internet streaming audio (in background) plays loud targeted advertisements, mute means 'only foreground application might do anything, but certainly not the loud background application, and OS will not mute mixer master because OS is sending all HID volume events to foreground application'.
- Some user software (DOS, perhaps) does not know and does not care about HID volume events.
- Now low-level software (BIOS setup program, POST errors) cannot be shut-up.
Back on-topic: brightness keys no longer control brightness. If the firmware stack behaves, then it sends ACPI notice/notification/event/signal/message to OS, and OS sends 'do something' back to firmware. (I do not know what I am talking about, I do not know what words to use. Please do correct me.) This is a lousy solution to the 'how to control hardware features' problem. LeNOvo replaced what worked perfectly, with a new problem: control of hardware features is on again and off again.
When I had this problem with X201s, using a four years-old HDD clone, I realised I should try a newer Linux distro release. No improvement. Then I suspected a firmware bug. I flashed latest BIOS/EC update, and no, it did not improve brightness control. "Well, Lenovo does not give a dime about Linux, so I will try Microsoft Windows 6.1, the OS which they intended this machine to run." Windows had no more control over brightness than Linux. "Well, maybe instead of the WHQL driver from Windows Update catalog, I should be using driver package from Intel's or Lenovo's faeces-filled Web site." No, their drivers provided no better behaviour. Linux kernels old or current, three Windows driver packs, cannot compensate for faulty lenova hardware/firmware. In my use of X201s, ACPI brightness control was on again and off again, no matter whether system at power-on was: coming out of suspend to RAM /sleep/standby/snooze, resume from hibernate, warm restart, power-on from off.
cfds wrote:I start to believe that it is a result of the way I setup my battery/power manager?
No, it is not a result of your chosen settings. I believe it is faulty firmware, buggy bios, just plain lousy product from Lenovo. Intel can be at fault, too. Their documentation is worse than ever. Every (thing containing microchips) is worse than ever. I see less sanity in I.T./computer/electronics industries today, than during Dot-Com Boom.
You are not alone, bothered by screen brightness. You have my empathy.
2015-06-04 edit add quotation:
2015-06-03 : X250 as a replacement for X200s/X201s? : Puppy wrote:This is caused by Lenovo (and possible other vendor's as well) bug in BIOS that always sets maximum brightness level during boot stage, the desired level is adujsted when Windows are loaded. I have already reported it many times but got answer "no way to get it fixed". Older IBM ThinkPads were able to remember the brightness level even in BIOS.