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.li...@paritcher.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
>>
