I wanted to add an internal USB port to my ThinkPad X1 Nano which should have been a fairly easy thing to do, but it wasn't.
Of course, if I were still using my Framework Laptop it would be as easy as plugging in a custom module but I've been using my X1 Nano as my primary laptop for quite some time now.
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 ubt0
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.
Finally
committed
my nvram driver.
I have my
tpb
port ready but since i made the /dev/nvram device owned by group kmem and
mode 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
driver is 640, owned by root.root.
Maybe tpb needs privsep.
Ugh.
Since I've gotten my X40, I've been conversing with
markus@
about OpenBSD support since he also owns one.
I've since
ported
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.
The
tpb
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 /dev/nvram device: