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

[Dana Goyette <danagoyette@gmail.com>]

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).