[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120312150717.GA13211@srcf.ucam.org>
Date: Mon, 12 Mar 2012 15:07:17 +0000
From: Matthew Garrett <mjg59@...f.ucam.org>
To: platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] platform/x86: Add driver for Apple gmux device
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@...f.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists