Re: Dell Vostro V131 hotkeys revisited

["Pali Rohár" <pali.rohar@gmail.com>]

On Wednesday 16 December 2015 10:05:31 Michał Kępień wrote:
> > > 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.
> 

CCing Hans de Goede

Hans, you tried to fix problems with acpi backlight... do you have idea
how to fix above problem with those two brightness keys?

In my opinion we should drop keypress events in acpi-video module. And
use event from dell-wmi if SMM was enabled.

-- 
Pali Rohár
pali.rohar@gmail.com