Anton Ekblad

Computer Scientist • Software Developer

Debian on the Kaby Lake R Dell XPS 13

I recently bought a Dell XPS 13 to replace my old ThinkPad X260. While the XPS 13 is a nice machine and an extremely shiny toy, and all of its hardware works perfectly fine in Linux (in my case, Debian), setting it up is not entirely straightforward.

Before installing

The first thing you'll want to do when installing Linux on an XPS 13 is to disable secure boot in the firmware settings, or you won't get anywhere at all. There are distributions that do support secure boot, but it's just too much of a hassle IMO.

While in the firmware settings, you'll also need to set the SATA operation of the SSD to AHCI. Any other setting for SATA operation will render Linux unable to detect the SSD. This should be enough to let you install your distro of choice as usual.

The Killer WiFi card

EDIT, 2017-11-30:

I retract anything positive I've ever said about this NIC. Since I started using this laptop extensively, a whole bunch of problems have materialized:

  • Intermittent Bluetooth firmware crashes, necessitating a reboot to fix. Simply reloading the driver doesn't seem to fix the problem.
  • Sporadic WiFi disconnects and latency spikes in the six second range.
  • Generally poor performance (and guaranteed firmware crashes) when WiFi and Bluetooth are in use at the same time.
  • Adding insult to injury, once the card starts acting up, it also tends to trigger an interrupt storm, eating a whole CPU core indefinitely and tanking your battery life unless you disable the offending interrupt entirely.

I've ordered a replacement Intel 8265, which seems to be the WiFi module recommended by other XPS owners. This is also the card that Dell's support seem to be willing to hand out for free.


After installing the 8265, all problems described above went away completely.

If you're replacing the NIC with an Intel one, remember that the black antenna cable goes to the black antenna socket on the WiFi card, and the white cable goes to the white socket. This means you'll need to cross the cables, as the position of the antenna cable sockets are swapped compared to the Killer NIC.

Also note that you'll need the firmware-iwlwifi package rather than the Atheros one when installing firmware for the card.


The WiFi module in the XPS 13, Killer 1535 seems to be generally reviled by everyone. I've seen claims of everything from poor performance to bringing down the whole WiFi network by triggering bugs in some manufacturers' routers. So far, the card is working more or less fine for me, with similar performance and power consumption as the Intel WiFi module in my old ThinkPad.

I did, however, experience a firmware crash when attempting to connect to one coffee shop's wireless network. The driver re-initialized the firmware immediately and I could connect to and use the network without after that, and I haven't experiencd any other stability issues, but it seems that the firmware may not be entirely reliable.

If this becomes an issue, Dell may apparently be willing to send you a replacement WiFi module from Intel free of charge, or you could just buy one for around €20 and avoid having to convince the support rep that you didn't just fail at driver installation.

Installing the appropriate firmware

If WiFi or Bluetooth aren't working, chances are you haven't installed the appropriate firmware. The blobs for WiFi and Bluetooth live in the firmware-atheros package. The exact name may differ by distribution, but it will always include atheros.

If your distribution doesn't include non-free firmware in its installer (hello, Debian), you will need to ensure that the firmware is available during installation if you want Internet connectivity (for instance, if you're using a minimal installer that fetches most components from the Internet).

On Debian, this entails:

  • Download the firmware-atheros package onto a USB stick and plug it in alongside your installation media.
  • When starting the installer, choose the expert installer instead of the normal one.
  • Before the detect network hardware step, launch a shell from the installer.
  • Mount the USB stick: mkdir usb && mount /dev/sdb usb.
  • Install the package: dpkg -i usb/atheros-firmware-$VERSION.
  • Exit the shell and proceed with the installation as normal.

Display brightness controls

EDIT, 2018-01-29:

It seems that the backlight issues are fixed in newer kernels. xbacklight works just fine as of 4.14, so you shouldn't need to mess around with the low-level brightness controls anymore unless you've verified that the standard solutions are broken on your particular setup.


Once you get the system up and running, you'll probably notice that the display brightness controls are broken. For some annoying reason, the standard methods (such as xbacklight or your DE's built-in hotkeys) just won't work here. Fortunately, you can still control the backlight by writing to the /sys/class/backlight/intel_backlight/brightness file, where the current screen brightness is expressed as a number between 0 and 7500. To set the brightness to 50%, you would write 7500/2 to the file:

# echo 3750 > /sys/class/backlight/intel_backlight/brightness

Not only is this unwieldy, but it also needs to be done as root. To make the situation less annoying, I wrote a small program to work as a more or less drop-in replacement for xbacklight, which I then mapped to the brightness up/down hotkeys. Note that this program needs to be SUID root in order to work. To build and install the program, make sure that you have the Haskell Platform installed, then:

$ ghc --make backlight.hs
$ sudo chown root:root backlight
$ sudo chmod u+s backlight
$ sudo mv backlight /usr/local/sbin/

Depending on your distribution, you may also need to add /usr/local/sbin to your $PATH.

Power savings and performance issues when on battery

EDIT, 2018-01-22

After some additional testing, I'd now recommend tweaking the pstate driver rather than switching it for CPUFreq. This section has been updated accordingly.


If you're going to run Linux on your laptop, you really want to use TLP to automatically manage your power settings. This will extend your battery life significantly, and only requires you to "install and forget":

# apt-get install tlp

Unfortunately, CPU power management on the XPS 13 suffers from an annoying bug, which causes the CPU to be stuck at a very low clock frequency (<1 GHz) when using Intel's power savings frequency scaling algorithm and giving the "wrong" performance hints to the firmware.

The simplest workaround for this is to change the CPU performance hints to the firmware to more performance-oriented settings.

To do this, open up /etc/default/tlp, find the line that reads CPU_HWP_ON_BAT=powersave and change it to CPU_HWP_ON_BAT=balance_performance. Restart TLP by running sudo systemctl restart tlp, and you're done. This will allow the CPU to use all available clock frequencies, but still try to the power consumption down as much as possible.

Note that you could also use balance_power instead of balance_performance, to allow the CPU to use all non-turbo clock frequencies. There doesn't seem to be any real reason to do this, however, so I'd recommend sticking to balance_performance.

CPU coil whine

EDIT, 2018-01-22

It turns out that I was a bit mistaken. What I'm experiencing isn't coil whine, but electrical interference on the sound chip. If you don't care about onboard sound (for instance, if you're using Bluetooth audio exclusively), you can try disabling the sound chip in the BIOS if you have a similar problem. If you're indeed experiencing the same kind of interference, this will remove the noise completely.


My unit has an annoying tendency to produce coil whine (or rather, coil "whirring", since the sound isn't very high-pitched at all) when stressing the GPU or CPU in certain ways. Video playback, audio streaming and gaming triggers the issue, while long-running compilation processes don't.

It's approximately as loud as the fan which kicks in after stressing the CPU/GPU for a while -- that is, loud enough to be heard in a quiet office, but low enough to be drowned out in a coffee shop or by a normal conversation -- but more annoying since the sound is less uniform.

Fortunately, there's an easy "workaround": reboot the machine.

For some reason, which definitely has to do with CPU/GPU power states, the coil whine only appears after resuming from sleep. The problem is most likely fixable in a more permanent way, but fixing it will probably involve messing with power state transitions, causing a significant drop in battery life.

Trackpad speed, tapping and two-finger scrolling

Out of the box, the touchpad was a bit slow for my liking. Unfortunately, changing this seems to be more work than it should. Even in GNOME, using the input settings dialog didn't seem to work, and since I normally don't even use GNOME that wouldn't have worked anyway.

Additionally, the default settings for scrolling and clicking need some tweaking if you prefer a MacBook-like behavior for the touchpad.

Fortunately, this can be configured relatively easily on the X level, by creating a file /etc/X11/xorg.conf.d/99touchpad.conf with the following contents:

Section  "InputClass"
    Identifier  "touchpad overrides"
    MatchDriver  "libinput"
    MatchIsTouchpad "on"

    Option "Tapping"  "true"
    Option "NaturalScrolling"  "true"
    Option "ScrollMethod" "twofinger"
    Option "DisableWhileTyping" "true"

    Option "TransformationMatrix" "1 0 0 0 1 0 0 0 0.8"

Note that you may need to create the /etc/X11/xorg.conf.d directory if it doesn't exist.

This config is mostly straightforward. The "Tapping" line enables left-clicking by just tapping the touchpad. "NaturalScrolling" inverts the direction of scrolling, so that it behaves like dragging a piece of paper with your finger, rather than dragging a viewport displaying a piece of paper. The "ScrollMethod" line enables two-finger scrolling instead of the default edge scrolling, and "DisableWhileTyping" does exactly what you'd expect it to.

The only confusing thing here is the "TransformationMatrix" on the second to last line. There's no way to directly set the "speed" of the touchpad, but we can change the way its events are interpreted.

To increase the sensitivity of the touchpad, set the final digit of the transformation matrix to a number between 0 and 1. The pointer speed of the touchpad is divided by this number, so a value of 0.5 will make the pointer move twice as fast. For me, 0.8 seemed to be a good number, which translates into a 25% increase in pointer speed.