Re: Dell Vostro V131 hotkeys revisited

From: "Michał Kępień" <kernel@kempniu.pl>
To: Darren Hart <dvhart@infradead.org>
Cc: "Mario Limonciello" <mario_limonciello@dell.com>,
	"Pali Rohár" <pali.rohar@gmail.com>,
	"Gowda, Srinivas G" <Srinivas_G_Gowda@dell.com>,
	"Brown, Michael E" <Michael_E_Brown@dell.com>,
	"Warzecha, Douglas" <Douglas_Warzecha@dell.com>,
	"Matthew Garrett" <mjg@redhat.com>,
	"Kabir, Rezwanul" <Rezwanul_Kabir@dell.com>,
	"Alex Hung" <alex.hung@canonical.com>,
	"platform-driver-x86@vger.kernel.org"
	<platform-driver-x86@vger.kernel.org>
Subject: Re: Dell Vostro V131 hotkeys revisited
Date: Fri, 13 Nov 2015 11:17:16 +0100	[thread overview]
Message-ID: <20151113101716.GA5458@eudyptula.hq.kempniu.pl> (raw)
In-Reply-To: <20150910043812.GB108260@vmdeb7>

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ń