Bug#485465: thinkpad-acpi EC/NVRAM brightness sync errors
Well, at least the thinkpad-acpi angle I can help with. I am the kernel
maintainer for thinkpad-acpi.
1. If it is *spamming* your logs with *lots* of EC/NVRAM out of sync
messages, you need a newer thinkpad-acpi. Depending on your kernel version,
a backport will be available at ibm-acpi.sf.net.
2. There are just two ways to make EC/NVRAM get out of sync: BIOS bugs, or
doing something you are never supposed to do. The X.org server does not fit
the profile for "doing something you are never supposed to do" AFAIK.
Anything writing directly to the NVRAM, or accessing either thinkpad-acpi or
ACPI at the time the firmware is doing something to brightness itself, or
misconfiguring thinkpad-acpi, or accessing both thinkpad-acpi and ACPI at
the same time, *will* cause breakage.
Basically, you must NOT react to brightness changes on a thinkpad in
userspace by trying to change brightness again, EXCEPT if you managed to
block the BIOS from doing so, and the only way to do it is through X.org's
trick with the GPU registers, which doesn't work on every thinkpad out
there, either.
So, as a rule, do NOT enable the brightness keys in thinkpad-acpi hotkey
mask on any ThinkPad from IBM. I *MEAN* it. If the thinkpad is changing
the brightness through firmware by itself, which is the norm for IBM
thinkpads, you must never enable the brightness keys in thinkpad-acpi's
hotkey_mask unless you REALLY, REALLY know what you're doing.
thinkpad-acpi defaults are already sane, but it is a common error to
misconfigure it in HAL or manually, and outdated documentation you find
everywhere in the net doesn't help putting this issue to rest.
You only enable thinkpad brightness keys when a) the thinkpad doesn't handle
brightness on its own (thinkpad-acpi already knows when to do this), or b)
you managed to get x.org intel xserver to BLOCK the thinkpad BIOS to change
brightness on its own, and you now have to handle the keys through
xbacklight.
Some Ubuntu changes to HAL, which I belive DID land in Debian from HAL
upstream where they filtered to (argh!) are especially good at completely
fucking all the brightness control on thinkpads. You cannot enable the
brightness keys and have them issue BRIGHTNESS_UP/DOWN events when the
firmware is active, as the brightness changes will already be in-flight and
something else trying to do the same change (usually by abusing
thinkpad-acpi) will cause trouble.
Anything stupid enough to also write to every brightness control it finds in
sysfs in a ~1s window can also cause the same issue, so it doesn't have to
be HAL. It could be a gnome or kde helper too, for example.
So, that's it. You either silence the firmware, or you MUST NOT do any
brightness control based on *the brightness key presses*, EVER. If you do,
you will always hit the window where the firmware is also doing a change,
and bad things happen.
thinkpad-acpi cannot silence the firmware (it tries, but it has no effect),
the ACPI AML does not support it on most thinkpads. If X.org can't do it on
a given thinkpad, nobody can.
If feedback loops caused by bad handling of the brightness keys are taken
out of the mess, there is still one thing you cannot do: You cannot use
both ACPI video brightness control, and thinkpad-acpi brightness control AT
THE SAME TIME. You can use one, and after a while, the other. This is in
the process of being fixed in the kernel, but it will take a while.
ACPI video clashing with thinkpad-acpi shouldn't be a problem on a R50, I
don't believe it has ACPI video brightness control interface. But if it
does, either disable it, or disable thinkpad-acpi's to make sure nothing in
userspace is tempted into breaking things. And send me a note, it is
something I would like to handle automatically in the driver.
Newer enough thinkpad-acpi has an option to disable its brightness control
interface that you can use to check if things get better for your userspace
configuration.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: