I’ve got an XPS15 – Dell’s flagship laptop. This article is my notes on how I set it up to run Linux.
I’ve had considerably harder times than I had with this laptop when I was installing Linux on laptops in the past. Everything “Just Works†once you install the necessary drivers. All in all, very positive for both Linux and this laptop.
Windows
You’ll want rid, but I’d suggest checking your hardware with Windows before you start wiping hard disks and installing Linux. Quick checks:
- Webcam
- SD Card
- Touch screen
- Touch pad
- WiFi
Firmware Upgrade
Then, being that we’ll want a way of doing updates without Windows, we’ll ensure we can by using a FreeDOS USB stick.
- Latest firmware from Dell. A06 at time of writing.
- FreeDOS image. I got the 250MB image. It’s a tiny download when zipped though because it’s all empty space.
The firmware is a DOS executable, and we want it on the FreeDOS image. The image is a disk image though, and not a partition image:
$ fdisk -l freedos.img
Disk freedos.img: 250 MB, 250000384 bytes
101 heads, 32 sectors/track, 151 cylinders, total 488282 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00052fbf
Device Boot Start End Blocks Id System
freedos.img1 * 1 488281 244140+ e W95 FAT16 (LBA)
This tell us that the first partition starts at “sector†1, which is, from this information, 512 bytes in. We can mount this image then with:
$ mount -o loop,offset=512 freedos.img /mnt/
Then you copy the Dell firmware executable to this mounted directory. Then write it to a USB stick with (remembering that this is a disk image, not a partition image so it goes to a disk):
$ dd if=freedos.img of=/dev/sdb bs=4M
Be careful you get the right output device – it would be a disaster to write this to your system hard disk.
Now you can reboot. Push F2 to enter the BIOS setup; then disable Secure Boot, which will in turn enable Legacy Boot; save the new settings; then F12 to choose the USB stick as the boot drive.
C:\> cd XPS15
C:\> 9530a06.exe
And follow instructions. As it happens mine was already loaded with A06, so I didn’t need to do anything. However, this procedure will work for any future updates Dell releases.
Disk partitioning
Initial SSD partitioning (as reported by Windows)
- 500MB EFI System Partition
- 40MB OEM Partition
- 750MB Recovery Partition
- 7.97GB Recovery Partition
- 8GB OEM Partition
- 7.37GB OEM Partition
- 459.58GB Boot, Page File, Crash Dump, Primary Partition
The Debian installer disagrees with what Windows reports:
- 1MB Free space
- 524.3MB (fat32) EFI system partition
- 41.9MB (fat32) Basic data partition
- 134.2MB Microsoft recovery partition
- 786.3MB (ntfs) Basic data partition
- 493.5GB (ntfs) Basic data partition
- 8.6GB (ntfs) Microsoft recovery partition
- 8.6GB Basic data partition (assume this is Rapid Start partition)
- 335.4kB Free space
This, actually, seems wrong. There is certainly a recovery partition from Dell – where’s that gone? Seems like a Debian bug, but I’ve got no way of confirming.
500MB EFI System Partition (fat32)
This partition is what a UEFI bootloader will look for for its managed boot. A quick peak at it in the debian installer’s console shows:
EFI/
Boot/bootx64.efi
Microsoft/Boot/
contains lots of Microsoft “stuffâ€
- en-us/
bootmgr.efi.mui
40MB OEM Partition (fat32)
Empty.
134.2MB Microsoft recovery partition
?
786.3MB (ntfs) Basic data partition
?
493.5GB (ntfs) Basic data partition
Main Windows partition.
8.6GB (ntfs) Microsoft recovery partition
Not sure, but this could be the Intel Rapid Storage partition.
Intel Rapid Storage uses an SSD partition to speed up HDD access, acting as a cache. That’s pretty useless here because there is no HDD.
8.6GB Basic data partition
Presume this to be the Intel Rapid Start partition.
Intel Rapid Start takes a copy of RAM and stores it to the SSD, that’s not going to work very well on a 16GB machine which has only 8GB partitions. This seems like a standard mistake by Dell.
Debian
BIOS
You’ll need to disable Secure Boot, which will auto-enable Legacy Boot; however, it seems the Debian’s installation images are happy with UEFI these days, so you can disable Legacy Boot. This has the advantage that the Debian installer will then install the UEFI version of grub in /boot/efi/EFI/debian/grubx64.efi
. UEFI seems a much less terrifying way of controlling early boot than rewriting MBRs – the EFI partition is a standard fat32
partitions, and so is pretty easy to alter.
Partitioning
The first decision is the new partition table. There are quite a few of the above partitions that we really don’t need. Here’s my suggested new schema:
$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A8F5A3A5-C068-4E51-AD31-51AF34E944F8
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 2669 sectors (1.3 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1026047 500.0 MiB EF00 EFI system partition
2 1026048 1107967 40.0 MiB FFFF Basic data partition
3 1107968 34662399 16.0 GiB 8400 Intel Rapid Start
4 34662400 71419903 17.5 GiB 8200 Linux Swap
5 71419904 1000214527 442.9 GiB 8300 Linux ext4
I’ve left the two fat32
partitions alone, resized the IRST partition to match the memory and added a swap partition for Linux, which should be bigger than main memory for suspend-to-disk purposes (although with IRST, that should never be necessary).
During install, you need only delete all but the first two partitions, then create three appropriately-sized partitions ready for Rapid Start and Linux. It’s important to make sure the Rapid Start partition is 16 GiB exactly (if you’ve got 16 GiB of memory) note that that is gibibytes not gigabytes. If you specify it as 16 GB it will end up too small.
You won’t need much swap, so I abandoned the “twice main memory†rule of thumb and just gave “main memory plus a bitâ€.
Other than the ext4 partition, I suggest leaving all the type code setting and GUID changes for the Rapid Start partition to after you have a working system. When you do, you can use gdisk
to set the partition GUID code (not the “unique GUIDâ€, confusingly) and Code
of the partition.
Partition number (1-5): 3
Partition GUID code: D3BFE2DE-3DAF-11DF-BA40-E3A556D89593 (Intel Rapid Start)
Partition unique GUID: D3BFE2DE-3DAF-11DF-BAFC-F23A556D8959
First sector: 1107968 (at 541.0 MiB)
Last sector: 34662399 (at 16.5 GiB)
Partition size: 33554432 sectors (16.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Intel Rapid Start'
After this, you’ll need a reboot, and a check in the BIOS setup that Intel Rapid Start is enabled. It’s worked without trouble for me with the above in place.
In case you’re unaware, Intel Rapid Start works on a computer in sleep (i.e. suspend to RAM). It waits for a period (default 120 minutes, but I altered mine with the Windows tool before I wiped it to 60 minutes) then does a sort of half-wake, copies the contents of RAM to the Rapid Start partition, which it finds by virtue of the magic GUID, and then does a full power off. On next power up, the BIOS sees that there is data in that partition restores the partition to RAM, then continues as if it were doing a restart from sleep. This means you can always just sleep the laptop, with no worries that the small power drain from keeping the RAM refreshed will drain the battery – it won’t once Rapid Start has kicked in. You can tell it’s working because once it’s in Rapid Start mode you’ll need the power switch (and a slightly longer start time) to get the laptop back on, as opposed to the simple lid opening that wakes a normal suspend-to-RAM. Personally I think this is a really good feature – convenience of a suspend-to-RAM with the safety of a non-volatile suspend-to-disk.
WiFi
There are a few difficulties around the WiFi firmware with Debian. We can work around them though.
There is, supposedly, a Debian netinst image that includes the non-free firmware. Having checked, the non-free firmware blobs are certainly in the image. Unfortunately, they don’t seem to do you much good. They are stored as .deb
s, which don’t help you at all during installation, as there doesn’t seem to be a way of extracting a deb from the command line in the installer, dpkg
isn’t available. All the documentation suggests that it should work. It didn’t for me though.
The alternative is to use the full debian CD1. This is sufficient to install a non-graphical Debian system – just as with a netinst image, only without a network connection needed. Then you are in a position to extract the firmware deb using your fully operational system. Just store, in this case, the firmware-iwlwifi
package on a (separate) USB stick.
Once you’ve got a Debian installation, mount this second stick and run
$ dpkg -i firmware-iwlwifi-WHATEVER.deb
$ modprobe -r iwlwifi
$ modprobe iwlwifi
You should now have a wlan0
when you run ifconfig -a
. Next you’ll need a way of connecting to a wifi network. network-manager
is the easiest way. apt-get install network-manager
and it will pull in all the other necessary packages. Then you can run network-manager
’s new command line UI.
$ nmtui
Now you’ve got a network connection you can install a proper /etc/apt/sources.list
, and start copying your configuration over as you would any other install.
Graphics
The XPS 15 has an integrated Intel graphics card, and a discrete nVidia graphics card. For the most part, the Intel graphics will be fine (and lower power) for us. All we really will want is the nVidia card powered down. The bumblebee
project lets us do that, but it needs a kernel module to help it, so you’ll need the headers for your kernel too.
$ apt-get install linux-headers-3.14-2-amd64 build-essential
$ apt-get install bumblebee
Then a reboot to let the bbswitch
driver and new config kick in.
This seemed to take about 1W off my power usage (measured by powertop
) in command line mode.
X
Installed. Worked instantly with no need to fiddle with any drivers.
The screen DPI, while detected and listed in the xorg log file seemed to be ignored when viewing the output of xdpyinfo | grep -B 2 resolution
. Rather than create a load of xorg.conf
sections (which ruins all the auto-detect work) I just made a little script in /etc/X11/Xsession.d/90-xps-15
:
xrandr --fbm 346x194
This should give KDE enough to work with to make its fonts the right height on screen.
Qt/KDE
With the DPI set correctly as above, you will still probably want to alter your task bar height, window decoration sizes, and icon sizes using KDE’s systemsettings
. For the most part I just doubled everything.
There are still a few areas were the HiDPI causes KDE problems. Particular with Qt-supplied widgets. Qt seems to draw widgets at fixed pixel sizes, hopefully they’ll get around to drawing them at fixed point sizes. Checkboxes and radio buttons are particularly awful.
You can tweak Qt a little with the qt4-qtconfig
package.
Skype, being a Qt and Microsoft app, has some horrible hard-coded size problems, I think we just have to live with them for now.
Firefox
Go to about:config
and change layout.css.devPixelsPerPx
to (I suggest) 2.0.
Gtk
Install the kde-config-gtk-style
package, and use KDE’s systemsettings
to set your Gtk applications to use the same font as your KDE applications.
Touch
Touchpad
After a bit of tweaking, here’s my /etc/X11/xorg.conf.d/10-synaptics.conf
:
Section "InputClass"
MatchDriver "synaptics"
Identifier "BuiltIn ClickPad"
# Overall
Option "ClickPad" "true"
# RBL RBR RBT RBB MBL MBR MBT MBB
Option "SoftButtonAreas" "60% 0 85% 0 41% 59% 85% 0"
# Palm
Option "PalmDetect" "true"
Option "PalmMinWidth" "2"
Option "PalmMinZ" "2"
# Features
Option "VertEdgeScroll" "false"
Option "HorizEdgeScroll" "false"
Option "VertTwoFingerScroll" "true"
# Buttons
Option "TapButton1" "1"
Option "TapButton2" "2"
Option "TapButton3" "3"
Option "ClickButton1" "1"
Option "ClickButton2" "3"
Option "ClickButton3" "2"
EndSection
Palm detection seems broken at present (problem seems to be in the kernel). Until it’s fixed you’ll get annoying jumps while you’re typing. A good workaround is to use syndaemon
to disable the pad whenever the keyboard is in use.
For everything else, set the ‘Features’ and ‘Buttons’ section to suit your own tastes.
Touchscreen
Personally, I’d like to disable this for the vast majority of the time, I’ve got no real use for it on a laptop. I’ve not found a way yet unfortunately. Worse, it seems to use about a Watt of power.
Update: you can disable it with xinput
.
$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎜ ↳ SYNAPTICS Synaptics Large Touch Screen id=10 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Power Button id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ Dell WMI hotkeys id=14 [slave keyboard (3)]
$ xinput disable 10
Re-enable it for those times you want it in the same way, but with xinput enable
.
Power
Install the laptop-mode-tools
package. Install the powertop
package.
The screen seems particularly power hungry. When the screen is off, even with the system busy, power drops to about 8W. With it on and busy, 15W.
With non-intense activity (just typing or browsing, nothing going on in the background), mine is sitting at about 12-15W and lasts a solid 6 to 7 hours.
SD Card
Works without fuss.
USB
The XHCI USB 3.0 host controller driver seems not quite up to scratch yet on Linux. It has occasionally stopped me suspending the system, and locked up USB when I plug a Nexus phone into the high speed port. I’ve got no real desire for USB 3.0 at present, so I worked around this by removing the module.
$ cat /etc/modprobe.d/adp-blacklist.conf
blacklist xhci_hcd
This might improve with later versions of Linux than the one I have at time of writing (3.16-2).
A better solution is to use systemd to remove the module on suspend, and add it back on resume. This means you can have all the USB goodness without suspend being affected.
#!/bin/sh
# /lib/systemd/system-sleep/xhci_hcd
MODPROBE=/sbin/modprobe
[ "$1" = "post" ] && exec ${MODPROBE} xhci_hcd
[ "$1" = "pre" ] && exec ${MODPROBE} -r xhci_hcd
exit 0
Replacement Parts
The battery will be the obvious first thing to start degrading. After four months of pretty much daily use I’ve already experienced this:
$ grep "" /sys/class/power_supply/BAT1/energy_full*
/sys/class/power_supply/BAT1/energy_full:84920000
/sys/class/power_supply/BAT1/energy_full_design:91000000
That is to say: 7% capacity loss, or 1.67% per month. Extrapolating, that will be 29 months until 50% of battery life is lost. The battery can be replaced, it is a 7D1WJ and seems to be between £160 and £320. Sigh.