Message-ID: <d48b54ab-09ad-381b-c130-c5f3cdb4da10@paritcher.com>
Date:   Mon, 8 Jun 2020 20:43:45 -0400
From:   Y Paritcher <y.linux@...itcher.com>
To:     Pali Rohár <pali@...nel.org>,
        Randy Dunlap <rdunlap@...radead.org>
Cc:     linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        Matthew Garrett <mjg59@...f.ucam.org>,
        Mario.Limonciello@...l.com
Subject: Re: [PATCH v2 3/3] platform/x86: dell-wmi: add new dmi keys to
 bios_to_linux_keycode

On 6/8/20 7:55 PM, Pali Rohár wrote:
> Hello!
> 
> On Monday 08 June 2020 16:27:10 Randy Dunlap wrote:
>> Hi--
>>
>> On 6/8/20 4:05 PM, Y Paritcher wrote:
>>> Increase length of bios_to_linux_keycode to 2 bytes (the true size of a
>>> keycode) to allow for a new keycode 0xffff, this silences the following
>>> messages being logged at startup on a Dell Inspiron 5593:
>>>
>>>     dell_wmi: firmware scancode 0x48 maps to unrecognized keycode 0xffff
>>>     dell_wmi: firmware scancode 0x50 maps to unrecognized keycode 0xffff
> 
> Which keys generate these two scancodes? Or how have you been able to
> trigger these scancodes (in case they are not generated by key press)?
> 
> It is important to know for which key or event or feature we need to
> include this patch and therefore what feature is currently
> non-functional on that laptop.
> 

As I said before:
The DMI contains a table of firmware scancode to linux keycode mappings.
this is parsed at boot and used together with the bios_to_linux_keycode
entries & dell_wmi_keymap_type_ tables to create a keymap.

If a DMI entry does not have a corresponding entry in bios_to_linux_keycode
we log a message to allow adding the correct linux keycode if known.
This is regardless of if the key actually exists on the device.

To date, I have not been able to generate this keycode on my computer.

>>> as per this code comment:
>>>
>>>    Log if we find an entry in the DMI table that we don't
>>>    understand.  If this happens, we should figure out what
>>>    the entry means and add it to bios_to_linux_keycode.
>>>
>>> These are keycodes included in the 0xB2 DMI table, for which the
>>> corosponding keys are not known.
>>
>>   corresponding
>>
>>>
>>> Now when a user will encounter this key, a proper message wil be printed:
>>>
>>>     dell_wmi: Unknown key with type 0xXXXX and code 0xXXXX pressed
>>>
>>> This will then allow the key to be identified properly.
>>>
>>> Signed-off-by: Y Paritcher <y.linux@...itcher.com>
>>> ---
>>>  drivers/platform/x86/dell-wmi.c | 8 +++-----
>>>  1 file changed, 3 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/platform/x86/dell-wmi.c b/drivers/platform/x86/dell-wmi.c
>>> index 6b510f8431a3..dae1db96b5a0 100644
>>> --- a/drivers/platform/x86/dell-wmi.c
>>> +++ b/drivers/platform/x86/dell-wmi.c
>>> @@ -196,7 +196,7 @@ struct dell_dmi_results {
>>>  };
>>>  
>>>  /* Uninitialized entries here are KEY_RESERVED == 0. */
>>> -static const u16 bios_to_linux_keycode[256] = {
>>> +static const u16 bios_to_linux_keycode[65536] = {
>>
>> It surely seems odd to me to expand an array from 512 bytes to 128 Kbytes
>> just to handle one special case.  Can't it be handled in code as a
>> special case?
> 
> I already wrote that more developers would not be happy about this
> change. I would rather to see e.g. that Randy's suggestion with 0xffff
> check as increasing memory usage.
> 

Will change

>>>  	[0]	= KEY_MEDIA,
>>>  	[1]	= KEY_NEXTSONG,
>>>  	[2]	= KEY_PLAYPAUSE,
>>> @@ -237,6 +237,7 @@ static const u16 bios_to_linux_keycode[256] = {
>>>  	[37]	= KEY_UNKNOWN,
>>>  	[38]	= KEY_MICMUTE,
>>>  	[255]	= KEY_PROG3,
>>> +	[65535]	= KEY_UNKNOWN,
> 
> Looking at the last two lines... and for me it looks like that 0x00FF
> and 0xFFFF are just "placeholders" or special values for unknown /
> custom / unsupported / reserved / special / ... codes.
> 

Probably so, but i have no way of knowing.

I just don't think there is a point spamming a users log with info that
they can't do anything with. If this is turned into a debug print then
i don't care to leave this as is, i had thought this might be helpful
just to know that this keycode mapping appears in the wild.

> It is really suspicious why first 38 values are defined, then there is
> gap, then one value 255 and then huge gap to 65535.
> 
> Mario, this looks like some mapping table between internal Dell BIOS key
> code and standard Linux key code. Are you able to get access to some
> documentation which contains explanation of those Dell key numbers?
> It could really help us to understand these gaps and what is correct
> interpretation of these numbers.
> 
> E.g. I remember that pressing Fn+Q or Fn+W on some Dell Latitude
> generates code 255, which could prove my thesis about "special codes"
> (which are probably not found in e.g. Windows or Linux mapping tables).
> 
>>>  };
>>>  
>>>  /*
>>> @@ -503,10 +504,7 @@ static void handle_dmi_entry(const struct dmi_header *dm, void *opaque)
>>>  					&table->keymap[i];
>>>  
>>>  		/* Uninitialized entries are 0 aka KEY_RESERVED. */
>>> -		u16 keycode = (bios_entry->keycode <
>>> -			       ARRAY_SIZE(bios_to_linux_keycode)) ?
>>> -			bios_to_linux_keycode[bios_entry->keycode] :
>>> -			KEY_RESERVED;
>>> +		u16 keycode = bios_to_linux_keycode[bios_entry->keycode];
>>>  
>>>  		/*
>>>  		 * Log if we find an entry in the DMI table that we don't
>>>
>>
>> Something like:
>>
>> 		u16 keycode;
>>
>> 		keycode = bios_entry->keycode == 0xffff ? KEY_UNKNOWN :
>> 			(bios_entry->keycode <
>> 			       ARRAY_SIZE(bios_to_linux_keycode)) ?
>> 			bios_to_linux_keycode[bios_entry->keycode] :
>> 			KEY_RESERVED;
>>
>>
>>
>> Also please fix this:
>> (no To-header on input) <>
> 
> Hint: specifying git send-email with '--to' argument instead of '--cc'
> should help.
> 

Sorry about that.
>>
>> -- 
>> ~Randy
>>

Powered by blists - more mailing lists