The x210 is a x201 thinkpad chassis with modern hardware inside, from a group of
chinese hardware modders that started out doing screen upgrades, originally.
Depending on the production batches they run and probably the chassis they have
available the hardware might differ slightly from machine to machine.
The group's blog has more info on the
batches, different devices, BIOS updates, etc.. A few notes about the hardware
first, before talking about FreeBSD on the one I got:
As said, the hardware depends on the batch, some special runs they sometimes
do, and the chassis used (one can also buy just the board alone). E.g. the
laptop I got does have a Core i5-8250U inside (there are i7 versions, too) and
was in a chassis that came with a default palmrest (no touchpad, but some
others seem to have been shipped with one). It has a WUXGA (1920x1200) display
which is physically actually slightly bigger than the chassi's screen bezel.
Since I did want a touchpad (I guess I could've asked them directly, so my bad)
I bought a used palmrest. There are two types for x201* machines that aren't
compatible with each other, grouped as 25W and 35W models with different
connectors, full list here
(I needed a 35W one and specifically replaced FRU 60Y5414 with FRU 60Y5415). Turns
out that in order to make the touchpad palmrest fit, some clipping was needed
as the mainboard's m.2 port and another part won't fit otherwise. Some plastic
and metal needs to be removed on both sides of the touchpad, so one before and
two after pictures:
Running FreeBSD 12
Graphics and Screen
You'll need FreeBSD 12 for the graphics, I originally tried to make it work on
FreeBSD 11.2, but didn't manage to get it to work.
The processor has an Intel UHD Graphics 620 integrated GPU. You'll
need to install the graphics/drm-kmod port. Make sure to read the post
install message! E.g. you'll need to add all users that need graphics to the
'video' group, and also put the following in /etc/rc.conf (more infos
I had some initial problems with the console, but I don't fully remember what.
Either way, setting the following in /boot/loader.conf helped and also gave me
a hires console:
X11 / xorg.conf
The FreeBSD Graphics wiki
suggests that one "should not have to prepare an xorg.conf configuration
file" and that "Xorg should autodetect the driver and utilize the
modesetting Xorg driver and
However, this did not work for me on this machine. The autodetection
used the intel driver with uxa as acceleration method, which
was slow and buggy. Not having read carefully the wiki that states clearly that
the autodetection "should [...] utilize the modesetting Xorg driver and
glamor driver", I did switch the acceleration from uxa to
sna, first. This improved the situation by a lot, however some
artefacts remained and X11 froze from time to time (which I was able to
unfreeze by switching to the vt console and back).
Anyways, what was really needed (and works really well) was a custom xorg.conf
that sets the modesetting driver with glamor as acceleration method,
explicitly. So I let X -configure create an xorg.conf template for me
and then specified explicitly in Section "Device":
Option "AccelMethod" "glamor"
As mentioned above, the physical screen size is a tiny bit bigger than the
chassi's bezel. I simply reduced the usable screen area a bit via the window
manager. I use x11-wm/spectrwm which has a region feature,
which allowed me to do that easily. In the end I have a usable region of
1912x1194 pixels, losing 8 pixels on the right, 3 on top and 3 on the bottom.
So the needed spectrwm config entry in this specific case would be:
region = screen:1912x1194+0+3
If not having such support from the wm, one could register and use a new
modeline via xrandr. I did that first, and it works, but I didn't figure out
how to specifically tell it where the screen should start, it was always
anchored in the top left corner.
Alternatively, one could also file off some plastic of the bezel, to make use
of the full screen.
The brightness buttons don't work out of the box, and things like kldloading
acpi_ibm(4) won't help - this isn't actually a thinkpad after all. Using
graphics/intel-backlight does not help either, as the GPU doesn't
control the brightness (in contrast to for example the x201), but the embedded
controller does. Poking around the ACPI tables (acpidump -dt) made me quickly
find an already existing method \_SB.PCI0.GFX0.DD1F._BCM that can be
used to set \_SB.PCI0.LPCB.EC0.BKLG, which controls the brightness
levels. So using sysutils/acpi_call we can run (after kldloading
acpi_call -p '\_SB.PCI0.GFX0.DD1F._BCM' -i $VAL
The predefined 16 brightness levels are not ideal, 0 is still way brighter than
what you would get from other laptops. The good news is that those levels can
be adjusted by apparently patching the EC firmware (more info
I haven't done so, myself, though.
I also have not looked into hooking up the brightness buttons out of laziness,
but simply wrapped the acpi_call based control above in a convenience script.
Seems to work fine out of the box using snd_hda(4). However, in order for the
sound to automatically switch over to the headphone jack when something gets
plugged in, I needed the following in /boot/device.hints:
hint.hdaa.0.nid31.config="as=4 seq=0 device=Speaker"
hint.hdaa.0.nid25.config="as=4 seq=15 device=Headphones"
I looked up the nid numbers needed from the output of sysctl dev.hdaa.
The volume buttons I hooked up myself by making use of the XF86 multimedia keys
XF86AudioRaiseVolume and XF86AudioLowerVolume. Since I'm using
x11-wm/spectrwm, as mentioned above, the according spectrwm config
entries would be something along those lines (with some bonus key combinations
to control treble and bass, given we had to bind those buttons manually
program[raise_volume] = mixer vol +2 pcm +2
program[lower_volume] = mixer vol -2 pcm -2
program[raise_treble] = mixer treble +5
program[lower_treble] = mixer treble -5
program[raise_bass] = mixer bass +5
program[lower_bass] = mixer bass -5
bind[raise_volume] = XF86AudioRaiseVolume
bind[lower_volume] = XF86AudioLowerVolume
bind[raise_treble] = Control+XF86AudioRaiseVolume
bind[lower_treble] = Control+XF86AudioLowerVolume
bind[raise_bass] = Shift+XF86AudioRaiseVolume
bind[lower_bass] = Shift+XF86AudioLowerVolume
The downside of making use of XF86 multimedia keycodes is that this now only
works in X, of course.
My machine came with a Broadcom BCM4352 802.11ac Mini PCIe WiFi card, for which
there is no driver support at the time of writing. So I replaced it with
another one. Contrary to stock/regular Thinkpads (and laptops in general), the
BIOS the x210 comes with doesn't do any wifi card whitelisting, so swapping out
the card doesn't require any extra work.
The laptop I got also had a webcam installed (from Chicony Electronics), which
shows up as a USB device and works using multimedia/webcamd. For
example, to test it quickly, make sure cuse is kldloaded, then:
service webcamd onestart $DEV
mplayer tv:// -tv driver=v4l:width=320:height=240:device=/dev/video0 -fps 25
The camera supports in my case the following resolutions: QVGA (320x240), VGA
(640x480), SVGA (800x600), XGA (1024x768), WXGA (1280x800), SXGA (1280x1024)
- I did not test the modem, microphone jack or the external mini display port so
- I did dump the contents of the flash chip using a
worked fine. Eventually I want to try flashing coreboot, but haven't done so,
yet. No flash write protection seems to be active, so internal flashing could
be used, I guess.
- The machine is mostly silent, the fan starts when there is some decent load,
but other than that it doesn't even spin at all and the machine also doesn't
get hot either (around 45°C for idly use).
- Suspend to RAM or disk doesn't seem to work, the graphics driver freezes while
trying to suspend and the machine hangs at that point. Maybe a future update
will fix this.
- Thinklight and numlock work, but those work without OS support, anyways.
- Also, as with the brightness buttons, other Fn-buttons aren't wired up,
- I don't have any data to compare the x210's battery life with, but compared to
my x201i it improved greatly. On a 3 year old, already well degraded 9-cell
battery that didn't run the x201i for more than a good hour, this machine gets
4h out of it. I'm not sure what a new battery would yield, but given what I had
before, I'm super happy.
UPDATE (2019-10-09): A brand new 9-cell battery with 7800mAh seems to
run this machine for nearly 10h (for light use, e.g. reading stuff, writing
mails, etc.). This is way more than what I actually hoped for.