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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
