For those of you playing along at home, I have some news (mostly bad, I'm afraid). TL;DR: I don't believe there is any way of getting Vostro V131 fully supported by the kernel without breaking stuff that already works, so I suggest a slightly different approach (see the last paragraph). I have recently noticed that backlight control on a Vostro V131 running Linux has some glitches as well. Before WMI gets enabled, pressing either the "brightness down" (Fn+F4) or the "brightness up" (Fn+F5) key causes two "presses" of the respective keycode (KEY_BRIGHTNESSUP or KEY_BRIGHTNESSDOWN) to be reported. This itself seems buggy to me, but whatever. The worse part is that there is an irritating flickering effect as well [1]. But if that wasn't enough, it gets even worse after issuing the WMI-enabling SMI call, because the keycode simulated by ACPI gets "shifted" by one event while the WMI events are reported correctly. Consider the following sequence of key presses: Key pressed Keycode reported WMI event reported ----------- ---------------- ------------------ Fn+F4 (none) 0xe005 Fn+F4 KEY_BRIGHTNESSDOWN 0xe005 Fn+F5 KEY_BRIGHTNESSDOWN 0xe006 Fn+F5 KEY_BRIGHTNESSUP 0xe006 Fn+Mute KEY_BRIGHTNESSUP 0x0000 Fn+Mute (none) 0x0000 I determined that both brightness flickering and incorrect keycode reporting are caused (the latter indirectly) by ACPI method CESM (and later I found out that [1] agrees in regard to flickering). While I haven't found the source of the "shifting" bug (and I am not willing to, thanks, I'd rather cut myself with a butter knife), the basic tests I've performed indicate that simply overriding that CESM method with a no-op does the job, if combined with correct kernel parameters. However, all this nonsense makes me come to the conclusion that any attempts to fix it by only changing existing kernel code are futile [2]. Thus, to avoid breaking other Dell devices which already work fine with Linux, I devised a "solution" using libsmbios (which in turn uses dcdbas) and ACPI method overriding which seems to work fine. It still needs a kernel patch which enables reporting the 0xe025 event as a keypress (this event is currently associated with a KE_IGNORE sparse keymap entry). I prepared a patch which adds a module parameter to dell-wmi that enables event 0xe025 to be either ignored or not, depending on the user's choice. Does that sound sane or is there a better way to do it? I'll be happy to post the patch once I'm done polishing it, given that this route sounds reasonable to the maintainers. If we enable the kernel to react to WMI event 0xe025, Vostro V131 users (at least those using kernels compiled with CONFIG_ACPI_CUSTOM_METHOD) will actually be able to use all standard features of their laptops on Linux without recompiling the kernel, which I would consider a win (a Pyrrhic one, but still). [1] https://bugzilla.kernel.org/show_bug.cgi?id=100441 [2] without Dell's assistance -- 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
