On Tuesday 07 July 2015 13:36:07 Mario Limonciello wrote: > > > On 07/03/2015 02:48 AM, Pali Rohár wrote: > > On Friday 03 July 2015 08:52:44 Michał Kępień wrote: > >>> Can you write which WMI call needs to be called? > >> Technically, one needs to call method DoBFn (method ID = 1) using GUID > >> A80593CE-A997-11DA-B012-B622A1EF5492. Though if you look at the ACPI > >> method this GUID maps to (WMBA), you'll notice that the first two > >> arguments passed to it (instance number and method ID) are simply > >> ignored and the only one that matters is the buffer passed (third > >> argument). > >> > >>> Last time when I looked into dell-led.c code it called some WMI > >>> functions which are just re-implementation of SMI based SMBIOS > >>> functions. From information which I have that is just WMI interface for > >>> dell SMBIOS one. > >>> > >>> I already asked Alex and other people for official ACPI/WMI Dell > >>> documentation, so we would be able to solve these hotkey problems once > >>> and for all, but I did not get anything yet. > >>> > >>> What I found on internet is just this one out-of-dated documentation: > >>> http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf > >>> > >>> I would suggest you to read it (it is not long) to see Dell WMI methods > >>> are just ACPI "wrapper" around Dell SMBIOS (dcdbas.ko driver) used by > >>> dell-laptop.ko. > >> Great, thanks. I'll look into it. > >> > >>>> 2) Pressing hotkey #3 on a Dell Vostro V131 generates WMI event > >>>> 0xe025, but no keycode. Apparently, Dell XPS L502X generates the > >>>> same WMI event for a hotkey which also generates a keycode [1]. > >>>> What's the best way to solve this conflict? > >>>> > >>>> [1] commit f1566f0: "dell-wmi: Add keys for Dell XPS L502X" > >>> Look at dell-wmi.c source code. Which event format is that? New one > >>> (partially described in above PDF document) when dell_new_hk_type is > >>> true? Or old one? > >> Vostro V131 is using the legacy keymap. > >> > >>> Can you please enable pr_debug() in dell-wmi.c and send dmesg output > >>> from dell-wmi.ko (specially dell_wmi_notify)? > >> Here's what appears in dmesg after pressing hotkey #3: > >> > >> ------------------------------------------------------------------------ > >> dell_wmi: Received WMI event (02 00 00 00 25 e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00) > >> dell_wmi: Key e025 pressed > >> wmi: DEBUG Event GUID: 9DBB5994-A997-11DA-B012-B622A1EF5492 > >> ------------------------------------------------------------------------ > >> > > It looks like above buffer has format of *new* event (0002 - length of > > event, 0000 - type of event, e025 - data). But when using legacy keymap > > then dell-wmi.c parse events with old format (which means type=0000 is > > dropped and data=e025 is translated to some key). > > > > This is even harder as I thought. Looks like big mess and now I would > > say, without documentation for Dell WMI events we are not able to fix > > this correctly without breaking other laptops... > > > > ======================================================================== > > > > CCing kernel Dell developers, can you provide Dell WMI documentation for > > events and hotkeys? We have problems with enabling events for additional > > buttons/keys on Dell laptops and also parsing WMI events which BIOS/ACPI > > generates and send to kernel. Please, I really do not know how to how we > > can fix these "hotkey/events" problems. > > > > Something like this document, but updated for new laptops: > > http://vpsservice1.sampo.com.tw/sampo_update/document/jimmy/ACPI-WMI%20.pdf > > > > Thanks! > > > I'm unsure how that document ended up on the web, it shouldn't have been > released in verbose form like that, but aside from that the BIOS > ACPI-WMI interface has not changed since that document was created. > There are some other BIOS specs that do refer to a few other things I > should mention though. > Hi Mario! I'm happy that you provided some response to us! I just used search tools and I tried to find some information about DELL, ACPI and WMI. And I come across that PDF document on internet which provided me some information useful how events can be received. > You added a patch to look at multiple events in one buffer in November. > I didn't see anything checking for the type In my patch from Nov 2014 (83fc44c32) there are checks for types. You can look into dell-wmi.c at line "switch (buffer_entry[1])". > so here's the detail you missed: > Word 0 is the length (as you mentioned) > Word 1 is the type. It can be either : > * 0x0000 meaning one hot key is pressed or an event occured. > * 0x000F meaning a sequence of hotkeys are pressed. > And what are types 0x0010 and 0x0011? As you can see in source code and sent logs to LKML key presses and events are sent also with these two types. Is there somewhere list of all events and key presses which can BIOS/WMI send to running system? And in that PDF document is specified to query for BIOS WMI Descriptor at first (UUID 8D9DDCBC-A997-11DA-B012-B622A1EF5492). And it returns also "WMI Interface Version". From ACPI DSDT dumps we already see that version is either 0 or 1. Is there some difference between these two versions (0 and 1)? Was something changed for receiving events or something else? And should Linux dell-wmi.c driver check that "BIOS WMI Descriptor" before doing something? > e025 is supposed to be translated into "Dell Instant Launch". This key > is a bit special because the EC can be configured to send programmed > scan codes. Some other documentation that isn't part of the WMI > documentation does describe more clearly how you can query what is > supported. > Query key press simulation capability: > class 4, selector 11. > Arg1=0x40. > Res1 value of 0, means success > Res1 value of -1, error > Res1 value of -2, not supported > Res2 bit0 if set means that the EC can send scan codes when Instant > Launch is pressed. > Hmm... class=4 and selector=11? Is not this id for keyboard illuminations settings? It is used in smbios-keyboard-ctl tool on: http://linux.dell.com/cgi-bin/cgit.cgi/libsmbios.git/tree/src/bin/smbios-keyboard-ctl#n667 I tried to send smbios request with: class=4 selector=11 arg1=64 (0x40 hex = 64 dec) And it disabled keyboard backlight on my E6440 machine, then it set keyboard backlight inactivity timeout to 5 seconds and call returned: Res1=-2 So this smbios query is not safe :-( as it set some keyboard backlight default values and return "error not supported". So are you sure that 4, 11, 64 is call correct? Or is above side-effect of setting keyboard backlight values expected? > What's probably happening is that the earlier system doesn't yet > support key press simulation. You can add a check for it with the above. > > Now as for actually simulating a keypress, it can be programmed using > the following calling interface (on receiving the e025 WMI notification). > To actually simulate the keypress: > Arg1=0x41 > Arg2 Byte [1:0]: Scan code to simulate > Byte [3:2] > * Bit0 - L Alt > * Bit1 - R Alt > * Bit2 - L Ctrl > * Bit3 - R Ctrl > * Bit4 - L Shift > * Bit5 - R shift > * Bit6 - L Win > * Bit7 - R Win > * Bit8 - Fn key > > Hm... what does it means if some bit in Byte [3:2] is set together with some scan code in Byte [1:0]? Anyway Michał Kępień already decoded from ACPI DSDT code that SBIOS WMI call 17, 3 needs to be send to enable receiving events for e025 key. See email: http://www.spinics.net/lists/platform-driver-x86/msg07195.htmls After that on libsmbios-devel@xxxxxxxxxxxxxxxxx ML we got answer from Srinivas_G_Gowda what SMBIOS call 17, 3 is doing, see email: http://lists.us.dell.com/pipermail/libsmbios-devel/2015-July/000612.html So I believe code like this: get_buffer(); buffer->input[0] = 0x10000; buffer->input[1] = 0x51534554; buffer->input[3] = 0x1; dell_send_request(buffer, 17, 3); ret = buffer->output[0]; release_buffer(); Could be OK for enabling e025 event. Or not? And if yes, how to detect if we need to call this SMBIOS 17, 3 function? -- 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
