Lenovo has finally made a smaller version of its X1 Carbon, something I've been looking forward to for years.
Another year, another ThinkPad X1 Carbon, this time with a Dolby Atmos sound system and a smaller battery.
ThinkPads have sort of a cult following among OpenBSD developers and users because the hardware is basic and well supported, and the keyboards are great to type on. While no stranger to ThinkPads myself, most of my OpenBSD laptops in recent years have been from various vendors with brand new hardware components that OpenBSD does not yet support. As satisfying as it is to write new kernel drivers or extend existing ones to make that hardware work, it usually leaves me with a laptop that doesn't work very well for a period of months.
After exhausting efforts trying to debug the I2C touchpad interrupts on the Huawei MateBook X (and other 100-Series Intel chipset laptops), I decided to take a break and use something with better OpenBSD support out of the box: the fifth generation Lenovo ThinkPad X1 Carbon.
I started working on an ACPI driver this evening to make my ThinkPad X61 work
better under OpenBSD.
I just finished it and so far it matches on the
IBM0068 ACPI HID device,
checks it for the appropriate version, enables the Bluetooth device (which is
required before the hardware toggle switch can power it on and let the
device show up), and sets up a callback to run whenever a special button (e.g.,
Fn+F[1-9], brightness, ThinkLight, etc.) is pressed.
I'm pretty sure it will work on most other ThinkPads but I haven't tried it on
my X40 yet.
I mapped out all of the events that get generated, which on my X61 Tablet include the screen rotating around, the lid opening and closing, and even the pen being ejected from its little slot. When the brightness buttons (Fn+Home and Fn+End) are pressed, it sends a CMOS command through ACPI to actually adjust the screen brightness accordingly, so now it's working just like my X40 did on its own. Being able to turn the brightness down when on battery is the main reason I wrote this.
I have my
port ready but since i made the
/dev/nvram device owned by group
440, tpb has to run setgid
kmem which might not fly so well.
I looked at the code and I don't see any easy way to drop privileges since it
has to open
/dev/nvram, read it, and close it every time it polls.
I'll post it to
ports@ and see what people have to say.
tpb makes no mention of how the permissions should be handled and Linux's NVRAM
640, owned by
Maybe tpb needs privsep.
Since I've gotten my X40, I've been conversing with
about OpenBSD support since he also owns one.
a driver for the TCPA/TPM security chip and one thing I always wanted to do was
hook into the blue "Access IBM" button to run
xautolock -locknow for one-touch locking.
program can hook into this button on Linux, but all of the work is handled by an
NVRAM driver in the Linux kernel.
Apparently the X40's BIOS toggles various bits in the CMOS RAM (NVRAM)
when certain buttons are pushed, like the volume buttons, ThinkLight, and of
course, the blue "Access IBM" button.
Last night I started looking into making an NVRAM driver for OpenBSD, which
turned out to be relatively easy, since the i386's clock code already has
functions for reading and writing to the NVRAM.
I put together a simple driver to provide user-land read-only access to the
NVRAM through a