HP OmniBook 7 AI 14-fr0220nw

This article or section does not follow the
Laptop page guidelines
.
Reason:
Missing an Accessibility and Firmware section. (Discuss in
Talk: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
xev
and 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.