> This patch is not enough for enabling 0xe025 key on that Vostro machine. > Some extra SMBIOS call is needed, without them ACPI will not send WMI > keypress event. Indeed. But have you read the last e-mail I wrote before submitting the original patch [1]? Brightness control on the V131 is already broken "out of the box" with newer kernels (flickering upon brightness change), but if we do what you're suggesting and include the SMI call in the kernel, we'll break it even more, to the point where pressing one of the brightness control keys might not result in any brightness change at all. Sure, we can fix that by overriding an arbitrary ACPI method. Oh, wait, did I say "fix"? I posted the patch without the SMI call because that way if you want to use the Dell Instant Launch hotkey, you just fire up a userspace script (which uses libsmbios and takes care of overriding the ACPI method) and chances are you will end up with a fully functional system. Of course you need to understand that using this script is not an elegant solution and that it might break something else, but it's your choice, not the kernel's. And the patch itself does not change kernel's default behavior, so we're not risking breaking any other models out there. > At least I think this one patch should not be included into kernel until > there will be full support for 0xe025 key (adding that SMBIOS call). Again, fully supporting the Dell Instant Launch hotkey makes brightness control even more broken than it has to be. In other words, everything is terrible. The only real solution to all these issues is a BIOS fix and I'm pretty sure it's not happening. [1] http://www.spinics.net/lists/platform-driver-x86/msg07679.html -- Best regards, Michał Kępień -- 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
