One of the… things that, around the beginning of the year, I tentatively planned to do more of this year… was to share more of what I do and resurrect this blog. Well, it’s nearing the end of March, so it’s a good thing I didn’t make any formal New Year’s resolutions! In general I’ve been really busy at work with some esoteric big-company stuff, and really busy in my personal life as well with a new car and a bunch of projects around the house (including trying my hand at building a small shelving unit completely by hand, including some simple joinery).
Two weeks ago my company replaced my four-year-old (mid-2015) MacBook Pro 11,4 (original install notes) with a shiny, brand-new MacBook Pro 15,4 A1990. I’d been dual-booting my previous MBP between Linux (for any real work) and MacOS (for Netflix and quick Googles while at home) as I’ve been doing with MacBook Pros for almost a decade now, and loved it. Unfortunately, as is described in detail at Dunedan/mbp-2016-linux Issue #71 as well as numerous other places online, because of the T2 security chip acting as the storage controller for the SSD, it’s currently impossible to install Linux on the built-in SSDs of the latest generation MacBook Pro. So I threw in the towel and requested to be re-platformed to a Dell laptop, and listed my puppet-archlinux-macbookretina module as unsupported and in need of a maintainer.
Last week I picked up my new new work laptop, a Dell Precision 5530. I’d asked about an XPS 15 as those seem to be on par with the MacBook Pro in terms of price and specs, but when you work at a company with 34,000 employees and they tell you “our developer laptop is a Precision 5530” and you’re a developer, that’s the laptop you get. I was pleased to find out, though, that the internal hardware of the Precision 5530 is extremely similar to the XPS 15 9570, including having some of the same issues.
My odyssey of getting Arch Linux - my desktop distribution of choice for the past six years - installed on the new Dell laptop took me thirty hours or so (conservatively) over the course of one work day and four afternoons/evenings. The first day was mostly spent getting up to speed on changes in Arch in the past few years and the current best way to handle LUKS/dm-crypt encryption on an EFI system with NVMe storage. My first install was completely ruined when I got to the (literally) last step and realized that I’d forgotten to create an EFI system partition (ESP), so I started over. Luckily, as usual, I’d documented every step of the install process in excruciating detail.
When I finally got the system installed, I ran up against an interesting problem: when I launched Xorg, the laptop screen was either black (no backlight on at all), backlight black with no image, or flashing on and off. I fought with this for the better part of two days before I decided to try connecting an external display, and sure enough, that worked fine. I spent another two days or so with the laptop hooked up to an external monitor, repeating everything I’d done before, trying every combination I could think of of graphics drivers (nvidia and nouveau, intel i915 and not), graphics-related kernel parameters, Nvidia Optimus / PRIME software, etc. Finally, when I was well past my wits end and turned back to Google, I found a kernel bug for the issue and an eight-character patch that fixed it.
The Solution
It turns out that the non-functional laptop display on these models is caused by this commit to the kernel i915 driver. The commit specifically effects embedded Display Port (eDP) displays, and changes the link configuration algorithm from the older variant that uses more data lanes with a slower link speed (“wide and slow”) to the newer eDP standard’s recommendation of fewer lanes with a higher link speed (“fast and narrow”). Unfortunately, it seems that the hardware in some of these Dell laptops will not function with this new method (even though the specification it was introduced in is six years old and, according to the commit message, they should be reporting that they’re compatible with it).
After another exhaustive Google search lead me to the Dell XPS 15 9570 Arch Wiki page, which contains a troubleshooting section describing exactly this problem (well… it does now…) and pointing to ArchLinux bug 61964. Somehow I found my way to the relevant upstream bug, FreeDesktop.org bug 109959, which contains both multiple reports of the same issue as well as two kernel patches which fix it.
Applying the noted kernel patches - and switching from nvidia to nvidia-dkms to support the custom kernel - fixed the bug completely, and graphics on the laptop now work perfectly.
For anyone else who’s running Arch, until the bug is fixed upstream and Arch picks it up in their official kernel, I have my PKGBUILD file and sources in my arch-pkgbuilds GitHub repo as well as (unsigned, sorry) compiled binary packages in my arch packages repo (index page).
Comments
comments powered by Disqus