Linux support for the Dell XPS 13 9343 (2015 model)

2015-02-03

I’M ALL DONE: I’m not working on Linux compatibility for the XPS 13 any longer. I’ve purchased a Lenovo X1 Carbon (3rd gen) and that’s my preferred laptop. More on this change later.

I’ve been looking for a good laptop to run Linux for a while now and my new Dell XPS 13 9343 has arrived. It was released at CES in 2015 and it received quite a lot of attention for packing a large amount of pixels into a very small laptop frame with excellent battery life. Ars Technica has a great overall review of the device.

Linux support has been historically good on the previous generation XPS 13’s and a blog post from Dell suggests that the latest revision will have good support as well. For a deep dive on the hardware inside the laptop, review this GitHub Gist.

After wiping Windows 8.1 off the laptop, I started with the Fedora 21 installation. If you want to run Linux on one of these laptops, here’s what you need to know:

The good

All of the most basic devices work just fine. The display, storage, and peripheral connections (USB, SD card slot, mini DisplayPort) all work out of the box in Linux 3.18.5 with Fedora 21. The display looks great with GNOME 3’s default HiDPI settings and it’s very readable with the default font sizes without HiDPI (although this is a bit subjective).

The webcam works without any additional configuration the video quality is excellent.

It’s possible to get this card working with the b43 kernel modules but I’ve had better luck with the binary blob STA drivers from Broadcom. There are plenty of guides out there to help you install the kernel module for your Fedora kernel. I’ve had great network performance with the binary driver.

Some users are seeing Intel wireless cards in their Dell XPS 13’s, especially in Europe. Opening the laptop for service isn’t terribly difficult and you could replace the bluetooth/wireless card with a different one.

PRO TIP: If you’re seeing errors in your journald logs about NetworkManager being unable to scan for access points, be sure to hit the wireless switch key on your keyboard (Fn-F12) to enable the card. This had me stumped for about 45 minutes. There’s an option in the BIOS to disable the switch and let the OS control the wireless card.

The special keyboard buttons (volume up/down, brightness up/down) all work flawlessly.

The bad

The touchpad and keyboard are on the I2C bus and this creates some problems. Many users have reported that keys on the keyboard seem to repeat themselves while you’re typing and the touchpad has an issue where X stops receiving input from it. However, when the touchpad seems to freeze, the kernel still sees data coming from the device (verified with evtest and evemu-record).

You can connect up a mouse and keyboard to the laptop and work around those issues. However, dragging around some big peripherals with such a small laptop isn’t a great long-term solution. Some users suggested blacklisting the i2c_hid module so that the touchpad shows up as a plain PS/2 touchpad but I’m still seeing freezes even after making that change.

If you’re having one of those “touchpad on the I2C bus?” moments like I had, read Synaptics’ brief page about Intertouch. Using the I2C bus saves power, reduces USB port consumption, and allows for more powerful multi-touch gestures.

Oddly enough, the touchscreen is an ELAN Touchscreen and it runs over USB. It suffers from the same freezes that the touchpad does.

The ugly

Sound is a big problem. The microphone, speakers and headphone port don’t work under 3.18.5 and 3.19.0-rc7. The audio device is a ALC3263 from RealTek and it should use the same module as the RT286. However, the probing still fails and the module can’t be used. The module code seems to be correct but the probing still fails.

I connected up an old Syba USB audio device to the USB port and was able to get sound immediately. This is also a horrible workaround.

What now?

From what I gather, Dell is extremely eager to make Linux work on the new XPS 13 and we should see some movement on these bugs soon. I’m still doing a bunch of testing on my own with kernel 3.19 and I’ll be keeping this page updated as news becomes available.

If you know much about the I2C bus or about the sound devices in this laptop and you have some time available to help, just let me know where to send the beer. ;)

Latest updates

2015-02-03

Added Red Hat bug link for sound issues.

2015-02-05

The touchpad bug has been reduced to a kernel issue. Recordings from evemu-record look fine when they’re played back in X. Users reported in Launchpad and in the Red Hat bug that kernel 3.16 works perfectly but 3.17 doesn’t. A kernel bisection will most likely be required to find the patch that broke the touchpad.

Many users find that adding acpi.os="!Windows 2013" to the kernel boot line will bring the audio card online after 1-3 reboots. Apparently there is some level of state information stored in memory that requires a few reboots to clear it. I haven’t verified this yet.

2015-02-06

Kernel bisect for the touchpad issue is underway. Every 3.16.x kernel I built would keep the trackpad in PS/2 mode and that’s not helpful at all. There’s no multi-finger taps/clicks/gestures. 3.17.0 works perfectly, however. My gut says something broke down between 3.17.0 and 3.18.0 but it might actually be closer to 3.17.4 since Fedora 21’s initial kernel is 3.17.4 (and the touchpad doesn’t work well with it).

A post was made on Barton’s Blog yesterday about Dell being aware of the Linux issues. (Thanks to Chris’ comment below!)

After about 35 kernel builds during the most frustrating git bisect of my life, I found the problematic patch. The Red Hat bug is updated now and I’m hoping that someone with a detailed knowledge of this part of the kernel can make sense of it:

2015-02-07

2015-02-10

Progress is still being made on the touchpad in the Red Hat bug ticket. If you can live with the pad working as PS/2, you can get sound by adding acpi_osi="!Windows 2013" to your kernel command line. Once you do that, you’ll need to:

Do a warm reboot

Wait for the OS to boot, then do a full poweroff

Boot the laptop, then do a full poweroff

Sound should now be working

If sound still isn’t working, you may need to install pavucontrol, the PulseAudio volume controller, and disable the HDMI sound output that is built into the Broadwell chip.

This obviously isn’t a long-term solution, but it’s a fair workaround.

2015-02-11

There is now a patch that you can apply to 3.18 or 3.19 kernels that eliminates the trackpad freeze:

I’ve tested it against 3.19-rc7 as well as Fedora’s 3.18.5. However, tapping still doesn’t work yet with more than one finger. The touchpad jumps around a bit when you apply two fingers to it.

2015-02-12

Rene commented below that he found a post in alsa devel with a patch for the “Dell Dino” that looks like it might help with the i2c audio issues. Another kernel maintainer replied and asked for some of the code to be rewritten to make it easier to handle audio quirks. UPDATE: Audio patch didn’t work.

We’ve created an IRC channel on Freenode: #xps13.

There’s an interesting kernel patch mentioning “Dell Dino” that is line for inclusion in 3.20-rc1. Someone in IRC found “Dell Dino” mentioned on a Dell business purchase page. The board name from dmidecode in the patch is 0144P8 but that doesn’t match other known board names. My i5-5200U with touch is 0TM99H while a user with a non-touch i5 has a board name of OTRX4F. Other i5 touch models have the same board name as mine. All BIOS revisions found so far are A00 (the latest on Dell’s site).

I received an email from a Realtek developer about the sound card in the XPS:

I see “rt286 i2c-INT343A:00: Device with ID register 0 is not rt286” in the log. It means there are something wrong when the driver is trying to read the device id of codec. I believe that is due to I2C read/write issue. ALC3263 is a dual mode (I2S and HDA) codec. And BIOS will decide which mode according to OS type. So, if you want to use i2s mode, you need to configure your BIOS to set ALC3263 to I2S mode.

After poring through the DSDT and other ACPI tables over the weekend (and building way too many kernels with overriden DSDT’s), it sounds like a BIOS update may be required for the sound card to function properly. The sound devices specified in the DSDT that are on the i2c bus are only activated after a BUNCH of checks succeed. One of them is the check of OSYS, the system’s operating system. Setting acpi_osi="Windows 2013" does flip OSYS to 0x07DD, but that’s only part of the fix. There are other variables checked, like CODS (that shows up very often) that are instantiated early in the DSDT but I can’t find them ever being set to a value anywhere in the DSDT code. These variables equal zero by default and that disables critical parts of the sound device.

My take: This laptop is going to need a BIOS update of some sort before we can get sound working properly in Linux with an i2c touchpad. If someone is more skilled with DSDT’s than I am, I’ll be glad to share all of my work that I’ve tried so far. As for now, I’m going to be waiting eagerly for some type of firmware update from Dell.

There’s some progress on the sound card in Linux! After building the latest commits from linux.git’s master branch, my XPS started showing a device called “broadwell-rt286” in pavucontrol. It showed up as a normal audio device but it had no output support, only input. I tried to enable the microphone but I couldn’t record any sound.

I found a kernel bug from a ThinkPad Helix 2 user with a very similar hardware setup. Their rt286 device is on the I2S bus with a Haswell SoC. Their fix was to copy over the latest firmware binaries from linux-firmware.git and reboot. I did the same and an output device suddenly showed up in pavucontrol after a reboot.

When I played sounds via aplay, canberra-gtk-play, and rhythmbox, I could see the signal level fluctuating in pavucontrol on the broadwell-rt286 device. However, I couldn’t hear the sound through the speakers. I connected headphones and I couldn’t hear any sound there either.

Sound on the I2S bus is working in Linux 4.0-rc2!See note from 2015-03-08 below. I was too exhausted last night for a full write-up, but here’s the gist of what I did:

First off, build 4.0-rc2 with all of the available I2C and ALSA SoC modules. I haven’t narrowed down which modules are critical quite yet. Once you’ve built the kernel and rebooted into it, run alsamixer and choose the broadwell-rt286 card. Hold the right arrow key until you go all the way to the right of the alsamixer display and press M to unmute the last control there. You should now be able to turn up the volume and play some test sounds.

Luckily, no update for linux-firmware is required. Also, there’s no need for any ALSA UCM files as I had originally thought.