Dell XPS 15 and Linux

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.


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)


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.



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.


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.


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 .debs, 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.


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.


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.


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.


Go to about:config and change layout.css.devPixelsPerPx to (I suggest) 2.0.


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.



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"

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.


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.


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.


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.

# /lib/systemd/system-sleep/xhci_hcd


[ "$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*

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.

This entry was posted in FussyLogic and tagged , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.

Post a Comment

You must be logged in to post a comment.