On Mon, May 9, 2011 at 10:36 PM, Andrew Lutomirski <luto@xxxxxxx> wrote: > On Mon, May 9, 2011 at 9:04 PM, Henrique de Moraes Holschuh > <hmh@xxxxxxxxxx> wrote: >> On Mon, 09 May 2011, Andrew Lutomirski wrote: >>> FWIW, this patch (other than having the wrong default on X220) makes >>> Linux better than Windows :) >> >> Please expand on that, especially the "wrong default on X220"... >> >>> Do you know how to read a field from the EC by name? I think I can >> >> If it is in the DSDT as a field of a "EmbeddedController" area, you just >> evaluate it. There are several examples in the driver (e.g. the TMP* evals >> in the thermal monitor subdriver). > > Indeed :) I'll send an updated patch tomorrow. > >> >>> Also, do you know how to ask the kernel what the most recent acpi >>> interrupt was? I'd like to find a better way to detect the mute >>> button than watching for the keyboard event. >> >> No, and I'd never ACK it if there was one. ACPI serves GPEs (interrupts) >> like crazy for random reasons, Never ever play racy games like that. >> >> Don't we get an HKEY notification for mute presses in the X220? > > I just meant to figure out what's going on. We're not getting an HKEY > event, I think, but something's happening and a bit of acpi debug > fiddling says that _Q43 is getting called. I have no idea what that > means, though. I read some more of the spec. It looks like the EC sends query 43 when the mute status changes. The problem is that _Q43 just calls _UCMS, which issues an SMI but does nothing else. So we don't get notified. And unless we change acpi_ec_sync_query to allow more than one handler for the same query, we can't even get notified without breaking _Q43. So we're screwed. I guess relying on the keyboard event isn't *that* bad. --Andy -- 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
