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.
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.
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:
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.
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:
firmware-atherospackage onto a USB stick and plug it in alongside your installation media.
mkdir usb && mount /dev/sdb usb.
dpkg -i usb/atheros-firmware-$VERSION.
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
To make the situation less annoying, I wrote
a small program to work as a more or less drop-in
xbacklight, which I then mapped to the brightness up/down
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
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
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
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
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.
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
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" EndSection
Note that you may need to create the
/etc/X11/xorg.conf.d directory if it
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.