Linux on the T470s

April 14, 2017

Trying to find a modern laptop that works well with Linux is quite difficult. I seemed like for a long time as long as you avoided the baddies like Broadcom networking controllers you were able to find a decent machine to hack on. Then awful technology like optimus appeared and, made life a lot more difficult for the Linux adventurer. Things got even worse when optimus moved from a hwmux (bios toggle) to direct frame-buffer access, then manufactures started arbitrarily putting some video connectors on the dGPU and some on the iGPU.

We’ve had very limited luck on the Dell “for developers”, or formerly known as “project sputnik”. Dell would love you to believe that they are treating Linux as a first class citizen, however they’ve marginalized Linux deployment by hacking together localized fixes for their hardware rather than working with upstream projects. Dell also notably has an infatuation with chasing performance for their users by forcing optimus on them via dGPU if you want anything above their most antique of display resolutions.

We buy a pretty large chunk of laptops, almost annually, to be used by people who strongly desire having a good experience with Linux on the desktop. When we reached out to Dell product management, and Barton George directly, we we’re dismissed for having a set of “unpopular” requirements:

• 13/14/15" display that is 1080P or 1440P: greater than 1440P becomes insanely difficult to deal with unless you use factor scaling, which then becomes a problem when using large external monitors.
• Weight at or below 4 pounds: we fly pretty often, and we move around the laboratory a lot.
• 24GiB or greater of memory: formerly for doing virtual machines until we moved over to using containers heavily, now days it’s because everyting seems to be built on top of the memory hungry electron.
• Integrated Graphics: because optimus is literally the evil, and if we want to do heavy 3D we can use desktops with real dGPU in them.
• 1TiB fast storage: most of our work is interacting with data, we bounce between projects and data sets, I/O becomes one of your largest bounding items when doing eda.
• LTE connectivity: cables are icky, you’re more likely to get our the laptop for a quick commit or ticket-touch in a coffee shop or airport if you’re not fighting to pigtail or hotspot.

Maybe we’re silly, but this is basically what all of our developers want now days. The few who are holdouts for the bullshit idea of “desktop replacement” change after having to haul the thing on planes for a year.

Thinkpad/Dell & Intel #

We’d dabbled with Thinkpad starting when they brought out the x220, flirting back and forth between Thinkpad and Dell based on whoever had achieved to pack the most of our requirements in that year. The longest running machines we ever stuck on were the T450s, which was because Intel notoriously mucked up their Skylake implementation which forced us to run on Broadwell for a long time (almost three years). When we tried to move off the T450s we trusted Dell for hopefully the last time, and jumped in on their first generation of heavy USB-C adoption laptops (Latitude 7370). The USB-C peripherals were an absolute nightmare, and Skylake was lurking under the hood to literally and figuratively burn us at every turn. So we started piling up our new Dell Skylake machines and moving back to our trusty Thinkpad Broadwell machines in hopes that Intel would tic, or toc, or whatever their Skylake Architecture and USB-C into a useful existence.

It should be said that we’ve chosen Intel for so many years because of their aggressive approach to contributing to the Linux Kernel. Recently, with things like AMT and the announcement that binaries may be forced into the Kernel for their iGPU implementation, people are getting kinda sick of Intel’s shit. It should also be menitioned that Intel has a pretty strong track record of being significantly anti-competitive , to the sum of over a billion dollars in payouts from litigation. We know that we’ll be looking at Intel laptops for the forseeable future, but we’ve got our eyes on alternatives like RISC-V and ARM64 in hopes that integrators will start targeting the laptop market.

The T450s has been my favorite laptop I’ve ever used. We have high hopes for a modern revision of, hopefully, the same design principles.

Thinkpad T470s + ArchLinux #

distilled useful information can be found on the Archwiki

Rather than a meta rant which this turned into, I was planning to write up what tricks I needed to do to get the T470s to work well in Linux. So far it hasn’t been too many, but I’ve only had it for a day at the time of posting this. I’ll update this post as I continue to learn more from using the machine.

Our T470s are maxed out in every capacity, aside from two things:

• we opted for LTE connectivity over optane storage because optane isn’t at market yet, but when it arrives we can purchase it directly. Purchasing the Sierra wireless cards is a bit more of a pain in comparison.
• we opted for no touch screen technology because it uses more power than a standard display.

We were specifically interested in the T470s because it added a USB-C connector but retained two critical features: the thinkpad docking interface, and an on-board Ethernet controller. We’ve got several eGPU devices and we’ve been really interested in the idea that we could use something like KVM and IOMMU device passthrough with a eGPU to have graphics intensive virtual machines. The T470s has an intriguing feature set with the conventional docking station and USB-C based docking capabilities.

I won’t get into the choice of ArchLinux, however there are some sub-choices that immediately impact whether you’re environment is similar to mine. I have been a hold out for gnome-shell. Primarily because the combination of gnome-shell, gnome-display-manager and NetworkManager actually make for a pretty intuitive desktop experience that I can deploy for friends and family, as well as myself. Some others are using sexy tiling window managers, but I’ll take the personal victory of having my parents, grandparents, siblings, and wife use ArchLinux with a noob desktop environment, over chasing them away by making them all feel like they need to be in the matrix.

Like a good Thinkpad user I do my best to track when firmware updates hit, notably there were two bios revisions since the manufacture of my motherboard. We’ve also seen firmware updates for the docking stations. From our experience with Intel/Dell’s USB-C debacles, we do our best to track to the most recent available firmware set.

When this device first arrived you needed to run linux-mainline to have access to nvme power patches that landed in 4.11rc1. Once Arch moved to 4.11 on stable I dropped back to running the core kernel. With 4.13 there was some goofyness with intel_iommu that made things relatively frustrating for suspend resume. This seems to have ironed out in 4.13.5 with the arrival of systemd 235. The main thing to be aware of if you follow my other guide is that you need to keep your EFI target updated. So make sure you run bootctl update when a new systemd update hits.

Because of the 2560x1440 display I experience some scaling issues right out of the box. Gnome-shell detects HiDPI and immediately applies a scaling factor of 2. I’m in favor of having everything be a bit smaller so I’ve chosen to execute the optional force scaling to 1:

gsettings set org.gnome.desktop.interface scaling-factor 1

This is especially useful because I extensively use external monitors that are 25 to 30 inches in size and are 1440P resolution. The scale factor, even if you use wayland, just doesn’t feel right. In the future wayland has planned support for floating point scaling rather than the integer scaling.

I started on wayland and felt it was mature enough to stick on. However some of the applications I use have problems inside it (e.g. pass) so I dropped back to xorg and things are pretty good. In Wayland the graphics adapter is enumerated in gnome-shell as “unknown”… which is a bit wonky.

To get hardware video acceleration working well I’ve installed two packages:

pacman -S vulkan-intel libva-intel-driver

I use mpv and can see that the va-api is forcing the load into the hardware acceleration instead of software. Although vlc has hit the anticipated 3.0 release and has some really awesome hardware acceleration capabilities now.

With powertop installed you can profile the device and selectively apply tunables. I see something just under 5w while idle with the screen relatively bright. I’m currently expecting greater than 5 hours of use without fear of charge anxiety.

I’m not a user of evolution so I like to mask some of the daemons it tries to spin up:

systemctl --user mask evolution-calendar-factory.service evolution-source-registry.service evolution-addressbook-factory.service

Same goes for the tracker-miner:

systemctl --user mask tracker-store.service tracker-miner-fs.service