From: Y Paritcher <y.linux@paritcher.com>
To: "Pali Rohár" <pali@kernel.org>, "Randy Dunlap" <rdunlap@infradead.org>
Cc: linux-kernel@vger.kernel.org,
platform-driver-x86@vger.kernel.org,
Matthew Garrett <mjg59@srcf.ucam.org>,
Mario.Limonciello@dell.com
Subject: Re: [PATCH v2 3/3] platform/x86: dell-wmi: add new dmi keys to bios_to_linux_keycode
Date: Mon, 8 Jun 2020 20:43:45 -0400 [thread overview]
Message-ID: <d48b54ab-09ad-381b-c130-c5f3cdb4da10@paritcher.com> (raw)
In-Reply-To: <20200608235508.wthtgilgmifwfgz2@pali>
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@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
>>
next prev parent reply other threads:[~2020-06-09 0:44 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-08 4:22 [PATCH 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-08 4:22 ` [PATCH 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-08 8:35 ` Pali Rohár
2020-06-08 15:30 ` Mario.Limonciello
2020-06-08 20:11 ` Y Paritcher
2020-06-08 20:14 ` Mario.Limonciello
2020-06-08 20:36 ` Pali Rohár
2020-06-08 20:38 ` Mario.Limonciello
2020-06-08 4:22 ` [PATCH 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-08 8:50 ` Pali Rohár
2020-06-08 20:12 ` Y Paritcher
2020-06-08 15:40 ` Mario.Limonciello
2020-06-08 20:12 ` Y Paritcher
2020-06-08 20:30 ` Pali Rohár
2020-06-08 20:36 ` Mario.Limonciello
2020-06-08 21:03 ` Y Paritcher
2020-06-08 22:00 ` Mario.Limonciello
2020-06-08 22:53 ` Y Paritcher
2020-06-09 10:44 ` Hans de Goede
2020-06-09 15:36 ` Mario.Limonciello
2020-06-09 16:14 ` Hans de Goede
2020-06-09 19:41 ` Mario.Limonciello
2020-06-09 15:49 ` Pali Rohár
2020-06-09 16:45 ` Sebastian Reichel
2020-06-09 16:59 ` Hans de Goede
2020-06-19 15:31 ` Sebastian Reichel
2020-06-19 17:26 ` Mario.Limonciello
2020-06-09 8:04 ` Pali Rohár
2020-06-08 4:22 ` [PATCH 3/3] platform/x86: dell-wmi: add keys to bios_to_linux_keycode Y Paritcher
2020-06-08 6:36 ` kernel test robot
2020-06-08 7:36 ` kernel test robot
2020-06-08 9:00 ` Pali Rohár
2020-06-08 15:46 ` Mario.Limonciello
2020-06-08 20:12 ` Y Paritcher
2020-06-08 20:48 ` Pali Rohár
2020-06-08 20:58 ` Mario.Limonciello
2020-06-09 8:27 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-08 23:05 ` [PATCH v2 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-08 23:24 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-08 23:33 ` Pali Rohár
2020-06-09 0:26 ` Mario.Limonciello
2020-06-09 0:57 ` Y Paritcher
2020-06-09 8:40 ` Pali Rohár
2020-06-09 8:50 ` Pali Rohár
2020-06-08 23:05 ` [PATCH v2 3/3] platform/x86: dell-wmi: add new dmi keys to bios_to_linux_keycode Y Paritcher
2020-06-08 23:27 ` Randy Dunlap
2020-06-08 23:55 ` Pali Rohár
2020-06-09 0:43 ` Y Paritcher [this message]
2020-06-09 8:35 ` Pali Rohár
2020-06-09 19:49 ` Mario.Limonciello
2020-06-10 9:44 ` Pali Rohár
2020-06-10 12:35 ` Mario.Limonciello
2020-06-12 14:14 ` Pali Rohár
2020-06-12 14:59 ` Mario.Limonciello
2020-06-09 3:52 ` [PATCH v3 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-09 3:52 ` [PATCH v3 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-09 16:02 ` Mario.Limonciello
2020-06-09 3:52 ` [PATCH v3 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-09 3:52 ` [PATCH v3 3/3] platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff Y Paritcher
2020-06-09 9:19 ` Pali Rohár
2020-06-10 17:56 ` [PATCH v4 0/3] platform/x86: dell-wmi: new keys Y Paritcher
2020-06-10 17:56 ` [PATCH v4 1/3] platform/x86: dell-wmi: add new backlight events Y Paritcher
2020-06-10 17:56 ` [PATCH v4 2/3] platform/x86: dell-wmi: add new keymap type 0x0012 Y Paritcher
2020-06-10 17:56 ` [PATCH v4 3/3] platform/x86: dell-wmi: add new dmi mapping for keycode 0xffff Y Paritcher
2020-06-10 19:22 ` [PATCH v4 0/3] platform/x86: dell-wmi: new keys Mario.Limonciello
2020-07-09 19:29 ` Andy Shevchenko
2020-07-13 7:29 ` Pali Rohár
2020-08-14 8:10 ` Pali Rohár
2020-06-12 14:09 ` Pali Rohár
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d48b54ab-09ad-381b-c130-c5f3cdb4da10@paritcher.com \
--to=y.linux@paritcher.com \
--cc=Mario.Limonciello@dell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pali@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rdunlap@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).