On Mon, Mar 12, 2012 at 09:57:01AM -0500, Seth Forshee wrote: > On Mon, Mar 12, 2012 at 02:21:26PM +0000, Matthew Garrett wrote: > > apple_bl probably needs some matching work to disable itself if there's > > a gmux present? Otherwise, this looks good. > > How do you suggest doing this? The tricky point is that the gmux object > can be present in ACPI when the gmux hardware isn't really present > (which is what the version check really does, verifies the hardware is > actually there). So apple_bl can't just look for the ACPI object; it > needs to either communicate with apple-gmux or duplicate some of its > logic. The alternative is for apple_bl to export its unregister function and have gmux call that - downside is obviously that that results in gmux depending on apple_bl. Maybe some sort of notification list in the backlight core? > We also have the problem of gmux_backlight versus acpi_video. On most > machines with a gmux the acpi_video backlight interface is present but > just doesn't work. This problem isn't just limited to Apples. I'm of the > opinion that we need a more generalized solution for arbitrating between > the backlight interfaces present on a given machine, but I haven't had a > chance to really think about what that would look like. The ACPI code appears to be trapping into system management mode, so figuring out what it's meant to do is going to be awkward. I think having a hook in the ACPI video driver to deregister it in cases where we know it doesn't work is legitimate, but since it presumably works under Windows it'd be nice to figure out what's broken about it. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
