HP OmniBook 7 AI 14-fr0220nw
| Hardware | PCI/USB ID | Working? |
|---|---|---|
| Touchpad | Yes | |
| Keyboard | Yes | |
| GPU | 8086:7d41 |
Yes |
| Webcam | 04f2:b7fe |
Yes |
| Bluetooth | 8087:0033 |
Yes |
| Audio | 8086:7728 |
Yes |
| Wi-Fi | 8086:7740 |
Yes |
| NPU | 8086:7d1d |
Untested |
Installation
Secure Boot was not tested.
sof-firmware must be installed to get audio, and linux-firmware-intel to get Bluetooth, Wi-Fi, and extra GPU functionality like hardware video decoding.
The UEFI implementation deletes any other boot loaders if it detects that EFI\Microsoft\Boot\bootmgfw.efi exists on the EFI system partition. efibootmgr will successfully add a new entry to the boot table, but it is going to be gone by the time the laptop reboots. This means that dual-booting with Windows is only possible by copying the real Windows Boot Manager to a separate file (say, real_bootmgfw.efi), overwriting bootmgfw.efi with your desired boot loader, and chainloading the real Windows Boot Manager from it. Keep in mind that the file will get occasionally overwritten by Windows updates.
The Customized Boot option mentioned in Laptop/HP#Troubleshooting is not available in this laptop.
Audio
Speaker/mic mute LEDs (located on the F6 and F9 keys) do not work by default as the audio chip uses the same IDs as another hardware configuration (mailing list thread here).
This can be fixed by passing a hda_model=103c:876e parameter to the snd-sof-intel-hda-generic module, for example by creating a file with the following content and saving it as /etc/modprobe.d/intel-sof-hp-leds.conf :
options snd-sof-intel-hda-generic hda_model=103c:876e
or any of the other methods listed in Setting module options.
Power management
Suspending works okay, and causes a flurry of (harmless) key presses to be reported :
atkbd serio0: Unknown key pressed (translated set 2, code 0xab on isa0060/serio0). atkbd serio0: Use 'setkeycodes e02b <keycode>' to make it known.
Hibernation works okay too, also without the kernel's resume parameter which means the UEFI implementation does not seem to destroy the HibernateLocation variable. No extra key presses are reported when entering hibernation.
Keyboard backlight
Seems to be managed entirely by firmware as there are no entries in /sys/class/leds to manipulate it. However, pressing the backlight key does raise an event - see table below.
Function keys
| Key | Visible?1 | Marked?2 | Effect |
|---|---|---|---|
Fn+F1 |
Yes | Yes |
Super_L+p
|
Fn+F2 |
Yes | Yes |
Super_L+Control_L+Alt_L+Shift_R+ISO_Next_Group
|
Fn+F3 |
Yes | Yes |
XF86MonBrightnessDown
|
Fn+F4 |
Yes | Yes |
XF86MonBrightnessUp
|
Fn+F5 |
No | Yes | See #Keyboard backlight control below |
Fn+F6 |
Yes | Yes |
XF86AudioMute
|
Fn+F7 |
Yes | Yes |
XF86AudioLowerVolume
|
Fn+F8 |
Yes | Yes |
XF86AudioRaiseVolume
|
Fn+F9 |
Yes | Yes |
XF86AudioMicMute
|
Fn+F10 |
Yes | Yes |
XF86AudioPlay
|
Fn+F11 |
Yes | Yes |
XF86Launch2
|
Fn+F12 |
Yes | Yes |
Super_L+Shift_R+S
|
Fn+Del |
Yes | Yes |
Insert
|
Fn+Shift_L |
No | Yes | See #FnLock control below |
Fn+Shift_R |
Yes | Yes |
Print
|
Copilot |
Yes | Yes |
Super_L+Shift_L+XF86Assistant
|
Fn+Left |
Yes | Yes |
Home
|
Fn+Up |
Yes | Yes |
Prior
|
Fn+Down |
Yes | Yes |
Next
|
Fn+Right |
Yes | Yes |
End
|
- The key is visible to
xevand similar tools - The physical key has a symbol on it, which describes its function
Keyboard backlight control
Pressing the key is reported by the kernel's hp_wmi module as an "Unknown key code" :
hp_wmi: Unknown key code - 0x30021aa hp_wmi: Unknown key code - 0x33221aa hp_wmi: Unknown key code - 0x36421aa
0x33221aa is reported when turning the backlight on to "level 1" from completely off, 0x36421aa when going from "level 1" to "level 2", and 0x30021aa when going from "level 2" to completely off.
FnLock control
Similarly to backlight control, this is recognised by the kernel's hp_wmi module as an "Unknown key code" :
hp_wmi: Unknown key code - 0x21ab hp_wmi: Unknown key code - 0x121ab
0x21ab is reported when turning FnLock on, and 0x121ab when turning it off.