Re: WMI and Kernel:User interface

[Andy Lutomirski]

On Tue, Jun 13, 2017 at 9:38 PM, Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> On Tue, Jun 13, 2017 at 10:07:19AM -0700, Darren Hart wrote:
>> On Tue, Jun 13, 2017 at 06:52:47PM +0200, Greg Kroah-Hartman wrote:
>> > > As a concrete example, Dell has specifically made the request that we
>> > > work on a solution that doesn't require them to come back to the kernel
>> > > community each time they add a WMI GUID to their BIOS. They would like
>> > > to see those GUIDs automatically exposed.
>> >
>> > What do you mean exactly by "exposed"?  What do they do with these?  Why
>>
>> By exposed I meant: the chardev for the WMI GUID is created
>>
>> The idea being the kernel maps WMI GUIDs to chardevs and shepherds the
>> userspace calls through to the ACPI method evaluation and back. But the
>> kernel wmi driver doesn't, in general, have specific knowledge of the
>> methods or input and output formats.
>
> Hah, and those people who insist on "secure boot" are going to allow
> userspace access to ACPI methods like this?  Well, I guess as Windows
> does it, it must be ok...
>
> I'll shut up now and just wait for patches :)
>

Darren, Pali, etc, I wanted to throw out another idea for handling some of this
stuff without risking blobification: make WMI button work declaratively.  Here's
what I mean:

Currently, we have a whole bunch of WMI drivers that have a bunch of code
to do more or less the same thing.  They bind to a WMI event device,
parse events,
turn them into scancodes, and feed them to sparse_keymap_report_event.

What if we created a single driver that did this generically?  The core would
filter a WMI event device and look up each event by trying to match
it to a pattern.  A pattern is literally a bunch of bytes, where 1-4
of those bytes
are all NULL in the pattern but are marked as containing a scancode.  If there's
a match, the result is fed to sparse_keymap_report_event().  A pattern
would look
like (totally made up):

05 74 AB [0] [1] FF [2] [3]

[0] means that this byte is the low byte of the scancode.  [1] means
second byte of the scancode.  05 is a literal.

The scancode would also be programmable.

Then we let WMI drivers bind the device and feed the core a sparse
keymap and a pattern or list of patterns.  We'd also let the keymap
and the patterns be queried and edited from userspace.  Then, if a new
laptop comes out, some hwdb could feed the pattern to the kernel, and
the kernel would log the pattern that was fed in.  Then, later on, we
could update the kernel driver, or we could just leave the whole
pattern list in userspace.

Hmm?