> > 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? Setting acpi_backlight=native only solves the flickering problem. So if you don't want to enable WMI (i.e. use the Dell Instant Launch hotkey), that's it, you're good. But once you add the WMI-enabling SMI into the mix, things go awry again. In other words, I see no way of making all features of this laptop work correctly at the same time without resorting to DSDT patching (or properly fixing the firmware). Hopefully, someone will. See below for a detailed explanation. > > 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? Okay, so here is the full story. First, assume you're booting an unpatched kernel with default command line arguments. When you press the "brightness up" or "brightness down" key, its scancode is reported by the i8042 driver. That's perfect, but the CESM method still does two things: it sends a request to the i915 driver using the ASLE OpRegion _and_ notifies the ACPI video driver about brightness change. Note that it probably does both of these things due to a broken conditional expression in the AML code. With acpi_backlight=native, the ASLE request is ignored by the i915 driver (which alleviates the flickering problem), but the Notify() calls inside the CESM method still cause another (identical) scancode to be emitted by acpi-video (to be precise, by acpi_video_device_notify()). dell-wmi is not involved, because no WMI events are generated. In total, you get two identical scancodes for a single key press. It's suboptimal, but at least not completely broken. Now, assume you perform the WMI-enabling SMI call. It causes the brightness keys to no longer be reported by i8042, but rather using WMI events. Unless acpi_backlight=native, dell-wmi will remain idle, but the ACPI video driver will still emit scancodes. In other words, you will get a single scancode for each key press. Sounds good, but not really because the generated scancodes are shifted (see the table from my previous message in this thread) and you are still left with the flickering issue. If you use acpi_backlight=native, the flickering will be gone, but then dell-wmi will start reacting to key presses as well and in the extreme case you might get two different scancodes (KEY_BRIGHTNESSUP and KEY_BRIGHTNESSDOWN) for a single key press - one (the correct one) will be generated by dell-wmi and the other (the shifted one) by acpi-video. The most straightforward hack seems to be to just kill CESM with fire and then with acpi_backlight=native you will get a single, correct scancode for each key press. Though that solution is still not ideal because it makes it impossible to change brightness without using some userspace helper. Answering your question, AFAICT brightness keys are the only ones affected by the WMI-enabling SMI call, but that's bad enough. Without DSDT patching you have to choose between hotkey support and sane brightness control. Unless you can prove me wrong, which I am hoping for. -- 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
