On Tue, 2009-09-15 at 14:24 +0800, Rafał Miłecki wrote: > Hi, > > There are some unfunny cases, when ACPI can not be used for > controlling backlight level. > > Example can be my Sony VAIO > (http://bugzilla.kernel.org/show_bug.cgi?id=11682) where bl control > doesn't work with sony-laptop. This notebook has ATI GPU that is > responsible for backlight level. > > So we have to implement that in radeon module, which has access to > card and can just use register/AtomBIOS to manage backlight. Of course > KMS is perfect place for that. > > However we don't want to play with controlling backlight when there is > specific vendor driver for that. Many notebooks are well supported by > sony-laptop (and other modules) and in these cases we don't want to > change that. > > Is there some way of detecting if there is vendor-specific driver that > cares backlight? Or can we register bl device with some low priority, > so when acpi module registers with higher, it will be used? well, a similar issue happens on Intel graphics, http://bugs.freedesktop.org/show_bug.cgi?id=20963 and we have a similar proposal but in fact it doesn't work. you can get detailed information in the below link: http://marc.info/?l=linux-acpi&m=124650087015684&w=2 Now the solution is: 1. register another backlight sysfs device in KMS driver, which is different from ACPI. 2. xrandr supports changing the backlight in multiple way, via different backlight sysfs devices. And I think it may work for you as well, i.e. two backlight sysfs I/F may co-exist, it's the user space to decide which I/F to use. thanks, rui -- 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
