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
