Hi Michał! On Friday 13 November 2015 11:17:16 Michał Kępień wrote: > 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]. >From that bug I understood that solution is to use native backlight control (via acpi_backlight=native). This is something which can be forced or changed by default per DMI type (for buggy machines like this). Right? > 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 Hm... I'm not sure if I understood this problem correctly, but those keycodes are reported on i8042 bus by atk keyboard? Or are reported by ACPI video.ko module? And problem is only with brightness keys? What happen if you boot 4.2+ kernel with acpi_backlight=native? > 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 > -- Pali Rohár pali.rohar@xxxxxxxxx -- 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
