On Thursday 10 July 2008 14:24:54 Matthew Garrett wrote: > On Thu, Jul 10, 2008 at 02:19:04PM +0200, Thomas Renninger wrote: > > On Thursday 10 July 2008 13:53:17 Matthew Garrett wrote: > > > If the ACPI video driver has bound, then using the dcdbas mechanism for > > > backlight control is incorrect. I wasn't aware that any Dells actually > > > implemented that. The correct thing is for userspace to stop using > > > dcdbas if a real backlight control is available, not to cripple the > > > ACPI video driver. > > > > Yes, I agree. > > Anyway, given the fact that video.ko was rather broken all the time, a > > reasonable solution for now is to exclude Dells from using it. > > No, the problem was that the backlight was simultaneously being altered > by two pieces of code. kpowersave is doing the backlight control via hal > (I assume), and hal should simply not provide the Dell backlight control > on systems that have ACPI video backlight control. There's no need to > have this policy in the kernel. Do you know Dells working with the video.ko driver? If you tell me video.ko, best with an IGD device and without one is working there, it can be removed. Even then talking with dcdbas developers how to inform their user space app first is a good idea. As Dell is cooking their own soup here and the dcdbas driver was reported to work correctly with ACPI brightness functions in BIOS it is ok to blacklist Dells here until the first test reports are coming in telling us that video.ko is actually working correctly there. Testing will be easy via boot param. I will not risk again that this whole bunch of our patches will be reverted on -rc6 again, because a Dell user is reporting a backlight regression. We then have the same situation we had when the "check for physical device was removed": The implementation is wrong but worked. The implementation is right, but does not work on a specific machine -> regression -> revert. Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html