Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Hans de Goede]

Hi,

On 9/26/20 1:36 AM, Sid Sun wrote:
> HP OMEN laptops have a key for OMEN Command Center where home key should be, which is not supported by current hp-wmi drivers, this patch addresses this, making use of the key as a dedicated home key
> 
> Without the patch in place, hp_wmi logs the following in dmesg:
> - hp_wmi: Unknown key code - 0x21a5
> 
> Tested and developed on: OMEN by HP Laptop 15-ce0xx
> 
> Signed-off-by: Sidharth Soni (Sid Sun) <sid@sidsun.com>

So after looking at:

http://s3.amazonaws.com/digitaltrends-uploads-prod/2017/09/HP-Omen-15-review-keyboard-2.jpg

I understand what you mean with "where home key should be". So I've been thinking
a bit about what is the best thing to do here. Arguably mapping it to
KEY_CONTROLPANEL would be more accurate. But I can completely understand how
you just want to have a working "home" key; and it indeed is in the place
where on HP laptop keyboards with a num-pad, you would expect the home key.

So lets just map it to KEY_HOME as you suggest:

Reviewed-by: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans


> 
> diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
> index 1762f335b..11cf8d1d6 100644
> --- a/drivers/platform/x86/hp-wmi.c
> +++ b/drivers/platform/x86/hp-wmi.c
> @@ -149,6 +149,7 @@ static const struct key_entry hp_wmi_keymap[] = {
>          { KE_KEY, 0x2169, { KEY_ROTATE_DISPLAY } },
>          { KE_KEY, 0x216a, { KEY_SETUP } },
>          { KE_KEY, 0x231b, { KEY_HELP } },
> +       { KE_KEY, 0x21a5, { KEY_HOME } },
>          { KE_END, 0 }
>   };
> 

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Dana Goyette]

On 9/26/20 3:47 AM, Hans de Goede wrote:>
> So after looking at:
>
 > 
http://s3.amazonaws.com/digitaltrends-uploads-prod/2017/09/HP-Omen-15-review-keyboard-2.jpg 

>
>
> I understand what you mean with "where home key should be". So I've been
> thinking
> a bit about what is the best thing to do here. Arguably mapping it to
> KEY_CONTROLPANEL would be more accurate. But I can completely understand
> how
> you just want to have a working "home" key; and it indeed is in the place
> where on HP laptop keyboards with a num-pad, you would expect the > home key.
>
> So lets just map it to KEY_HOME as you suggest:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> Regards,
>
> Hans
>
>
>

FYI, the HP Omen 15 2020 has a different keyboard, where Home is a 
proper separate key.  The India model has yet another layout, with a 
full numeric keypad that also includes Home.  So unless we want to get 
into DMI matching, it's safest to map the key to something distinct.

Layout on the US model:

[Omen]   [Calc] [PrtScr]
[Insert] [Home] [PgUp]
[Pause]  [End]  [PgDn]

Layout on the India model:
[Omen]    [Calc] [Insert] [PrtScr]
[NumLock] [/]    [*]      [-]
[7/Home]  [8]    [9/PgUp] [+]

(Where's Delete?  Above Backspace.)

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Dana Goyette]

 > On 11/27/20 6:19 PM, Dana Goyette wrote:
> 
> FYI, the HP Omen 15 2020 has a different keyboard, where Home is a 
> proper separate key.  The India model has yet another layout, with a 
> full numeric keypad that also includes Home.  So unless we want to get 
> into DMI matching, it's safest to map the key to something distinct.
> 
> Layout on the US model:
> 
> [Omen]   [Calc] [PrtScr]
> [Insert] [Home] [PgUp]
> [Pause]  [End]  [PgDn]
> 
> Layout on the India model:
> [Omen]    [Calc] [Insert] [PrtScr]
> [NumLock] [/]    [*]      [-]
> [7/Home]  [8]    [9/PgUp] [+]
> 
> (Where's Delete?  Above Backspace.)

Upon looking at the driver's source, the 2020 model won't be 
encountering that path, so "home" may be okay after all.  When I press 
that key, the event is different (it's not HPWMI_BEZEL_BUTTON).

hp_wmi: Unknown event_id - 29 - 0x21a5

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Hans de Goede]

Hi,

On 11/28/20 3:55 AM, Dana Goyette wrote:
> 
> 
>> On 11/27/20 6:19 PM, Dana Goyette wrote:
>>
>> FYI, the HP Omen 15 2020 has a different keyboard, where Home is a proper separate key.  The India model has yet another layout, with a full numeric keypad that also includes Home.  So unless we want to get into DMI matching, it's safest to map the key to something distinct.
>>
>> Layout on the US model:
>>
>> [Omen]   [Calc] [PrtScr]
>> [Insert] [Home] [PgUp]
>> [Pause]  [End]  [PgDn]
>>
>> Layout on the India model:
>> [Omen]    [Calc] [Insert] [PrtScr]
>> [NumLock] [/]    [*]      [-]
>> [7/Home]  [8]    [9/PgUp] [+]
>>
>> (Where's Delete?  Above Backspace.)
> 
> Upon looking at the driver's source, the 2020 model won't be encountering that path, so "home" may be okay after all.  When I press that key, the event is different (it's not HPWMI_BEZEL_BUTTON).
> 
> hp_wmi: Unknown event_id - 29 - 0x21a5

Hmm, but the event_data is the same as before, so maybe event-id 29 is simply
the new HPWMI_BEZEL_BUTTON... I wonder if other keys generate this event-id too,
and if they also use the same event_data values is before.

Or IOW I wonder if we can / want to re-use the hp_wmi_keymap (and the existing
input_dev) for the new event-id 29, or if we want a new input_dev and sparse-keymap
for the new event-id.

My initial feeling is to re-use the existing input_dev and keymap at which point
the event-id being different does not help us. We should probably just assign
KEY_CONFIG to it.  Users who want it to send home can then remap that,
either through hwdb, so that it gets re-mapped to KEY_HOME at the kernel level,
or at some higher level.

Note in my original reply I said to use KEY_CONTROL_PANEL, but that has the
disadvantage that its keycode is above 247 which is not supported under X11.
Looking at this again I wonder why we have KEY_CONTROL_PANEL at all, since
the comments on KEY_CONFIG pretty much over opening the control-panel:

#define KEY_CONFIG              171     /* AL Consumer Control Configuration */

Alternatives which are also under 247 are:

KEY_COMPUTER
KEY_HOMEPAGE
KEY_DASHBOARD
KEY_MEDIA

I see that despite me reviewing this, the patch never landed, so we are free to
do what we want here with having to worry about breaking existing setups.

Regards,

Hans

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Dana Goyette]

On 11/28/20 3:13 AM, Hans de Goede wrote:
> Hi,
> 
> On 11/28/20 3:55 AM, Dana Goyette wrote:
>>
>>
>>> On 11/27/20 6:19 PM, Dana Goyette wrote:
>>>
>>> FYI, the HP Omen 15 2020 has a different keyboard, where Home is a proper separate key.  The India model has yet another layout, with a full numeric keypad that also includes Home.  So unless we want to get into DMI matching, it's safest to map the key to something distinct.
>>>
>>> Layout on the US model:
>>>
>>> [Omen]   [Calc] [PrtScr]
>>> [Insert] [Home] [PgUp]
>>> [Pause]  [End]  [PgDn]
>>>
>>> Layout on the India model:
>>> [Omen]    [Calc] [Insert] [PrtScr]
>>> [NumLock] [/]    [*]      [-]
>>> [7/Home]  [8]    [9/PgUp] [+]
>>>
>>> (Where's Delete?  Above Backspace.)
>>
>> Upon looking at the driver's source, the 2020 model won't be encountering that path, so "home" may be okay after all.  When I press that key, the event is different (it's not HPWMI_BEZEL_BUTTON).
>>
>> hp_wmi: Unknown event_id - 29 - 0x21a5
> 
> Hmm, but the event_data is the same as before, so maybe event-id 29 is simply
> the new HPWMI_BEZEL_BUTTON... I wonder if other keys generate this event-id too,
> and if they also use the same event_data values is before.
> 
> Or IOW I wonder if we can / want to re-use the hp_wmi_keymap (and the existing
> input_dev) for the new event-id 29, or if we want a new input_dev and sparse-keymap
> for the new event-id.
> 
> My initial feeling is to re-use the existing input_dev and keymap at which point
> the event-id being different does not help us. We should probably just assign
> KEY_CONFIG to it.  Users who want it to send home can then remap that,
> either through hwdb, so that it gets re-mapped to KEY_HOME at the kernel level,
> or at some higher level.
> 
> Note in my original reply I said to use KEY_CONTROL_PANEL, but that has the
> disadvantage that its keycode is above 247 which is not supported under X11.
> Looking at this again I wonder why we have KEY_CONTROL_PANEL at all, since
> the comments on KEY_CONFIG pretty much over opening the control-panel:
> 
> #define KEY_CONFIG              171     /* AL Consumer Control Configuration */
> 
> Alternatives which are also under 247 are:
> 
> KEY_COMPUTER
> KEY_HOMEPAGE
> KEY_DASHBOARD
> KEY_MEDIA
> 
> I see that despite me reviewing this, the patch never landed, so we are free to
> do what we want here with having to worry about breaking existing setups.
> 
> Regards,
> 
> Hans
> 

I tried various keys in xdotool, and `xdotool key XF86Tools` opens 
Gnome's Settings application.  From what I can tell, KEY_CONFIG is 
mapped to that: https://bugs.freedesktop.org/show_bug.cgi?id=12228

There's also precedent in the Huawei laptop driver for using KEY_CONFIG:
https://lore.kernel.org/patchwork/patch/1024465/

For completeness, I'm adding further information about the hotkeys on 
the HP Omen 15 2020 (AMD), though the other keys are probably out of the 
scope of this patch.

---


Omen key:
* On Windows, brings up Omen command center
* hp-wmi: Unknown event_id - 29 - 0x21a5
* Since it's an unknown event, it's not sent via the event device.


Fn-Escape (unmarked):
* On Windows, triggers a small HP system info window.
* hp_wmi: Unknown event_id - 29 - 0x21a7
* My last HP (EliteBook 8530w from 2008) had Fn-Escape too, but I don't 
recall what it did in Linux.


Fn-F2 / Fn-F3 (backlight down/up):
* Sends proper events via ACPI Video. but also does something on atkbd:
* atkbd serio0: Unknown key released (translated set 2, code 0xab on 
isa0060/serio0).
* atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.


Fn-F4 (keyboard backlight toggle):
* Toggle seems to happen in firmware
* Nothing on hp-wmi
* Nothing on any event devices


Fn-F11 (touchpad lock):
* Locking works (touchpad is frozen while LED is on)
* From unlocked: hp-wmi: Unknown key code - 0x21a9.  (LED turns on.)
* From locked:   hp-wmi: Unknown key code - 0x121a9  (LED turns off.)
* Sends EV_MSC/MSC_SCAN (value 0x21a9 or 0x121a9) to userspace.
* Sends EV_KEY/KEY_UNKNOWN down and up immediately (no hold or repeat).


Fn-F12 (windows key lock):
* No LED, but the lock works.
* From unlocked: hp-wmi: Unknown key code - 0x21a4  (Now locked.)
* From locked:   hp-wmi: Unknown key code - 0x121a4 (Now unlocked.)
* Sends EV_MSC/MSC_SCAN (value 0x21a4 or 0x121a4) to userspace.
* Sends EV_KEY/KEY_UNKNOWN down and up immediately (no hold or repeat).

Re: [PATCH] platform/x86: hp-wmi: Add support for home in HP OMEN laptops

[Hans de Goede]

Hi,

On 11/29/20 6:38 AM, Dana Goyette wrote:
> On 11/28/20 3:13 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 11/28/20 3:55 AM, Dana Goyette wrote:
>>>
>>>
>>>> On 11/27/20 6:19 PM, Dana Goyette wrote:
>>>>
>>>> FYI, the HP Omen 15 2020 has a different keyboard, where Home is a proper separate key.  The India model has yet another layout, with a full numeric keypad that also includes Home.  So unless we want to get into DMI matching, it's safest to map the key to something distinct.
>>>>
>>>> Layout on the US model:
>>>>
>>>> [Omen]   [Calc] [PrtScr]
>>>> [Insert] [Home] [PgUp]
>>>> [Pause]  [End]  [PgDn]
>>>>
>>>> Layout on the India model:
>>>> [Omen]    [Calc] [Insert] [PrtScr]
>>>> [NumLock] [/]    [*]      [-]
>>>> [7/Home]  [8]    [9/PgUp] [+]
>>>>
>>>> (Where's Delete?  Above Backspace.)
>>>
>>> Upon looking at the driver's source, the 2020 model won't be encountering that path, so "home" may be okay after all.  When I press that key, the event is different (it's not HPWMI_BEZEL_BUTTON).
>>>
>>> hp_wmi: Unknown event_id - 29 - 0x21a5
>>
>> Hmm, but the event_data is the same as before, so maybe event-id 29 is simply
>> the new HPWMI_BEZEL_BUTTON... I wonder if other keys generate this event-id too,
>> and if they also use the same event_data values is before.
>>
>> Or IOW I wonder if we can / want to re-use the hp_wmi_keymap (and the existing
>> input_dev) for the new event-id 29, or if we want a new input_dev and sparse-keymap
>> for the new event-id.
>>
>> My initial feeling is to re-use the existing input_dev and keymap at which point
>> the event-id being different does not help us. We should probably just assign
>> KEY_CONFIG to it.  Users who want it to send home can then remap that,
>> either through hwdb, so that it gets re-mapped to KEY_HOME at the kernel level,
>> or at some higher level.
>>
>> Note in my original reply I said to use KEY_CONTROL_PANEL, but that has the
>> disadvantage that its keycode is above 247 which is not supported under X11.
>> Looking at this again I wonder why we have KEY_CONTROL_PANEL at all, since
>> the comments on KEY_CONFIG pretty much over opening the control-panel:
>>
>> #define KEY_CONFIG              171     /* AL Consumer Control Configuration */
>>
>> Alternatives which are also under 247 are:
>>
>> KEY_COMPUTER
>> KEY_HOMEPAGE
>> KEY_DASHBOARD
>> KEY_MEDIA
>>
>> I see that despite me reviewing this, the patch never landed, so we are free to
>> do what we want here with having to worry about breaking existing setups.
>>
>> Regards,
>>
>> Hans
>>
> 
> I tried various keys in xdotool, and `xdotool key XF86Tools` opens Gnome's Settings application.  From what I can tell, KEY_CONFIG is mapped to that: https://bugs.freedesktop.org/show_bug.cgi?id=12228
> 
> There's also precedent in the Huawei laptop driver for using KEY_CONFIG:
> https://lore.kernel.org/patchwork/patch/1024465/

Ack, so lets just go with KEY_CONFIG here.

> 
> For completeness, I'm adding further information about the hotkeys on the HP Omen 15 2020 (AMD), though the other keys are probably out of the scope of this patch.
> 
> ---
> 
> 
> Omen key:
> * On Windows, brings up Omen command center
> * hp-wmi: Unknown event_id - 29 - 0x21a5
> * Since it's an unknown event, it's not sent via the event device.
> 
> 
> Fn-Escape (unmarked):
> * On Windows, triggers a small HP system info window.
> * hp_wmi: Unknown event_id - 29 - 0x21a7
> * My last HP (EliteBook 8530w from 2008) had Fn-Escape too, but I don't recall what it did in Linux.

Again event_id 29, I really think we need a patch to just treat
event_id 29 the same as HPWMI_BEZEL_BUTTON.

And we could/should map 0x21a7 to KEY_FN_ESC, then userspace could
potentially do something with this if it wants.

> Fn-F2 / Fn-F3 (backlight down/up):
> * Sends proper events via ACPI Video. but also does something on atkbd:

Good.

> * atkbd serio0: Unknown key released (translated set 2, code 0xab on isa0060/serio0).
> * atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.

Ideally we would silence these by adding a hwdb entry mapping them to be
ignored, see:

https://github.com/systemd/systemd/blob/master/hwdb.d/60-keyboard.hwdb#L333

(the Dell Inspiron 1520 and Latitude 2110 entry in case the line numbers
change due to new commits) for an example of this.

Note please group any new 60-keyboard.hwdb entries for this together with
the already existing HP entries.

> Fn-F4 (keyboard backlight toggle):
> * Toggle seems to happen in firmware
> * Nothing on hp-wmi
> * Nothing on any event devices

Likely there is some firmware interface for this, but possibly we first need
to make some call to tell the firmware that we are capable of dealing with
this. Anyways kbd backlight support (including registering a:
/sys/class/leds/hp_foo::kbd_backlight/ LED-class device for this so that
e.g. the GNOME3 integration for this can work is something which is currently
not supported at all. So way more then just detecting the key-press is missing
and this really is a completely separate project.


> Fn-F11 (touchpad lock):
> * Locking works (touchpad is frozen while LED is on)

So this is handled in firmware.

> * From unlocked: hp-wmi: Unknown key code - 0x21a9.  (LED turns on.)
> * From locked:   hp-wmi: Unknown key code - 0x121a9  (LED turns off.)
> * Sends EV_MSC/MSC_SCAN (value 0x21a9 or 0x121a9) to userspace.
> * Sends EV_KEY/KEY_UNKNOWN down and up immediately (no hold or repeat).

Nice, these should be mapped to KEY_F22 for when the touchpad gets
turned on, so use F22 for 0x121a9 I guess) and to KEY_F23 for when
the touchpad gets turned off. This will make at least GNOME3 show
OSD notifications showing that the touchpad is on/off like it does
for volume mute/unmute. I realize that using F22/F23 for this may
look a but weird, but userspace has re-purposed a bunch of the
high F-key numbers to avoid the key-codes higher then 247 not being
supported in X11 problem.

I know about the following re-purposed F2# keys for this:

F20: mic-mute toggle
F21: touchpad on/off toggle (to be handled by software)
F22: touchpad on (notification for this being handled in firmware)
F23: touchpad off (notification for this being handled in firmware)

You can see these being re-defined like this in:

/usr/share/X11/xkb/symbols/inet

(search for FK20)

> Fn-F12 (windows key lock):
> * No LED, but the lock works.
> * From unlocked: hp-wmi: Unknown key code - 0x21a4  (Now locked.)
> * From locked:   hp-wmi: Unknown key code - 0x121a4 (Now unlocked.)
> * Sends EV_MSC/MSC_SCAN (value 0x21a4 or 0x121a4) to userspace.
> * Sends EV_KEY/KEY_UNKNOWN down and up immediately (no hold or repeat).

Hmm, can you explain what this does does it disable the Windows (aka meta/super)
key to avoid accidentally pressing it ?

Regards,

Hans