http://bugzilla.kernel.org/show_bug.cgi?id=9995
------- Comment #39 from [EMAIL PROTECTED] 2008-03-19 06:08 ------- Better take off the kid gloves. 1. NVidia-GPU-based thinkpads are NOT Intel-GPU-based thinkpads. DO NOT CONFUSE WHAT IS SAID ABOUT ONE WITH THE OTHER. EVER. 2. *IF* you have an Intel GPU (*****NOT***** AN NVIDIA OR ATI GPU), FIX X.org. It must either be completely out of the way, or working. And right now X.org is only completely out of the way if it is NOT running. 3. *IF* AND ONLY *IF* thinkpad-acpi brightness_mode=1 *can* control your backlight, you can bypass X.org, ACPI and the BIOS completely and talk semi-directly to the backlight hardware. In that case, you might be able to work around issues in ACPI video and X.org using thinkpad-acpi. I DOUBT THIS HOLDS TRUE FOR ANY *61 THINKPAD. (if it is not clear yet: thinkpad-acpi calls the same crap ACPI video ultimately uses in a ThinkPad, unless it is in brightness_mode=1. It can be used to check if something hosed ACPI video (e.g. X.org), because if neither thinkpad-acpi nor ACPI video can change brightness, SOMETHING blocked the ThinkPad BIOS itself). Now, about how to fix it. Can we, for once, stop destroying any possibility of fixing backlight support and actually start fixing the underlying BUGS instead of band-aiding over it please? Forget the "last minute" *anythings*. Fix the real bugs and address the design issues, because the haphazard way this was done till in kernel, distros and X.org created a LOT of design incompatibilities between them. ACPI Video and X.org HAVE to talk to each other. X.org must be able to tell ACPI Video driver to go into an "I'm not here" mode, where it just acts as an ACPI notify->ACPI event repeater. And X.org is NOT to do *anything* to backlight hardware registers UNLESS it disabled ACPI video first (if it is loaded). X.org hardware drivers needs to be fixed, if they are not controlling backlight properly. Until X.org is fixed, the user gets broken backlight. Don't work around it breaking things further in the kernel side, especially while X.org still doesn't know how to tell the kernel to butt off, nor the kernel knows how to be told to go away. Fix the bug WHERE IT REALLY IS. ACPI video, if it is indeed not working, needs to be fixed. BUT YOU WILL NEVER KNOW whether it is working right or not WHILE YOU HAVE X.org RUNNING. After the above is done, we have a chance of actually doing the right thing in every X.org driver (enable or disable kernel support, use or don't use the kernel backlight interface). Then, we will have ACPI video being called to *change* brightness when it is right to do so, and with exclusive access to the backlight control. Or we will have X.org changing the brightness directly in hardware, and ACPI video will know it must *block* (even for reading!) any attempts to access the ACPI AML backlight methods. And *PLEASE* remove ANY AND ALL backlight key control crap on distros that fucks up thinkpads. NOTHING in userspace that could be shipped in a distro has ANY business listening to thinkpad-acpi backlight events *and* *acting* on them to *CHANGE* any brightness hardware. EVER. You will either get events you can use like that through ACPI video, or the thinkpad already did it in firmware. If you got to know of any backlight key presses through thinkpad-acpi, it can be used for on-screen-display ONLY. Anything else is a distro bug from hell. And mapping thinkpad-acpi brightness events to KEY_BRIGHTNESS_* or the HAL equivalent *WILL* *BREAK* *THINGS* because userspace as a rule does NOT know you really mean that as an on-screen-display event instead of "this is an order for you to change the brightness". Also, if X.org is acting on the brightness keys by itself (ask X.org upstream about it, I don't know for sure), DON'T act on them in distro scripts either. You will break things just as much, if not MORE than what was done to thinkpad-acpi. Does *this* makes things a little more clear? Hmm? PS: by distros I don't necessarily mean SuSE. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
