I recently (May 2022) bought an used HP EliteBook 820 G1 (Core i5-4310U, 16GiB RAM), a quite decent ultraportable laptop from circa 2013-2014. In retrospect, I should've gone for the 840 series, for keyboard size reasons, but .. oh well. This document lists the quirks etc. I've encountered with it and Linux, more specifically Debian Testing/Bookworm.
As an alternative for some of the solutions listed here you can use acpid scripts, see Debian Wiki's EliteBook 820 G1 page.
Update 31.5.2022: I have noticed that the display at least on this specimen suffers from "inversion/pixel walk" problems, mainly noticeable with dark/light gradients. The Lagom inversion test patterns 7a and/or b seem to be the ones triggering it.
Some of the special keys/buttons like the keyboard backlight (Fn + F11) seem to be handled by the EC/firmware, but some are passed on to the operating system. There are also some features that do not work quite right.
Wireless on/off button works, assuming you have all the wireless prerequisites and rfkill installed (see also the drivers section below). However, the kernel driver does not change the LED status, it just stays "on". Even manual poking of /sys/class/leds/phy0-led/brightness does nothing. I tried to briefly debug this in the kernel driver (drivers/net/wireless/intel/iwlwifi/mvm/led.c) but without gaining any interesting results. The driver seems to be attempting direct register writes on this machine though there is also code for talking to the firmware. I do not know if this is correct, there's some confusion about which chipsets and versions need to do talking through firmware and which do not.
Audio mute button and the Fn + F6/F7 volume button presses are delivered to the OS, so you need to bind them yourself via some method. Personally I chose to use xbindkeys (see here for my systemd unit for running xbindkeys) and use it to command 'pactl'. Here's a configuration snippet:
"pactl set-sink-mute @DEFAULT_SINK@ toggle" XF86AudioMute # Mute microphone "pactl set-source-mute @DEFAULT_SOURCE@ toggle" XF86AudioMicMute # Increase volume "pactl set-sink-volume @DEFAULT_SINK@ +1000" XF86AudioRaiseVolume # Decrease volume "pactl set-sink-volume @DEFAULT_SINK@ -1000" XF86AudioLowerVolume
The display brightness up/down keys are a bit .. weird. They work when in UEFI/BIOS and during GRUB screen, and thus seem to be handled by the EC/firmware, but after Linux boots the keypresses are passed on to the OS (XF86MonBrightness{Up,Down} in Xorg). I found this forum post on HP forums that presents an "interesting" scenario and solution, but it did not work for me. I attempted reflashing the UEFI/BIOS, still no worky.
Meanwhile, it is possible to bind those keys (via xbindkeys), and use them to control the brightness via something like xbacklight. A config snippet for xbindkeys:
# Increase backlight brightness "xbacklight -inc 10" XF86MonBrightnessUp # Decrease backlight brightness "xbacklight -dec 10" XF86MonBrightnessDown
The touchpad enable/disable metabutton does nothing on vanilla kernel. There exists an out-of-tree kernel patch with a matching Xorg xf86-input-synaptics patch. I've not tried them myself, however.
Debian stock kernel works well, though I use a self-rolled one with only the necessary drivers etc. Boot is noticeably faster that way.
You need firmware-iwlwifi package for the WiFi firmware binary blob.
The iwlwifi wireless driver also has some power-saving features enabled by default, which at least on this system cause annoyances like weird one-sided latency (e.g. ping/mtr FROM the machine to somewhere is ok, but ping at it will have wildly varying roundtrip times and even packet loss?) This will also cause annoying lag if connecting to the machine via SSH.
To fix this, we need to change the power scheme. Create file /etc/modprobe.d/iwlwifi.conf with contents:
# This option is needed because otherwise the powersaving scheme # causes annoying lag in RX packets .. options iwlmvm power_scheme=1
I suspect that this WONTFIX kernel bugreport may be the same thing as what I am encountering above.
By default, kernel complains that the Synaptics touchpad supports a different bus.
psmouse serio3: synaptics: Your touchpad (PNP: SYN3008 SYN0100 SYN0002 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.
As suggested, fix this by creating file /etc/modprobe.d/psmouse.conf with contents:
options psmouse synaptics_intertouch=1
Systemd-udevd complains some about the following:
systemd-udevd: regulatory.0: Process '/lib/crda/crda' failed with exit code 255.
.. although this is apparently a non-issue, I've not found a way to make it go away. Setting the regulatory domain in /etc/default/crda does not help. This did not happen with my previous laptop, so I think it is triggered by something on this new hardware.
Update 4.7.2022: Since CRDA is no longer required in userspace (as the database is built in kernel, unless it is not), and crda package can be removed, this is no longer an issue.
Some of the hardware is (practically) unsupported: