javispedro.com

Surface Pro 2

Surface Pro 2 with blue type cover

My third laptop! This time, I had to battle UEFI and Secure Boot. As usual, this page documents all the nuisances I found and will be updated as I find new fixes.

After a few years of using a 14’’, I finally saw the light and realized that smaller laptops are the way forward. Unfortunately, not many options were available for a reasonably performing 10incher. Fortunately, the Surface Pro 2 appeared in late 2013, promising good performance, acceptable battery life and a compact form factor. It is also my first HiDPI screen. The low definition of the 5820TG was one of my largest criticisms against an otherwise fine laptop.

First impressions are quite good. Despite being Microsoft hardware, virtually everything works out of the box. I obviously repartitioned the drive and installed Gentoo, using kernel 3.13.6 . It’s still a bit early to talk about battery life, but initial estimations say that I will get more or less the same I got with the 5820TG: around 4 hours.  However, thrusting the CPU to a full 100% use will run down the battery in about an hour, which is a bit of a regression.

Even suspend works, out of the box. So let’s go to the problems.

UEFI and Secure Boot

This laptop has secure boot. Not only that: by default, it only comes with the MS key, but not the “MS UEFI CA” key which is the one that everyone talks about. A stock Surface Pro will only boot its own Windows kernel, its own recovery disk and that’s about it. If you keep Secure Boot enabled, that is. You can disable it but then you get a scary-looking red background while booting. Windows itself does not seem to care, though.

Fortunately, on early 2014 MS published the Microsoft Surface Pro UEFI CA OEM PK Tool which can be used to install the MS UEFI CA key to the firmware. From that point on it’s all party time. Even Ubuntu’s modified GRUB works out of the box. Rod Smith will explain how the rest of Secure Boot works much better than I would do. It was easier than I expected.

Something I realized is that the Surface Pro 2 will not show an EFI boot menu if more than one Boot entry is configured in the NVRAM (that is, via efibootmgr). Instead, the first entry is always booted. So I just set rEFInd as my first entry. If you dual-boot Windows, Windows loves to overwrite the first entry, specially when you select the “show advanced boot options”. So don’t do that.

Wi-Fi

The Surface Pro uses a weird setup where a combined WiFi + Bluetooth chipset, the Avastar 88W8797, connected by USB3, provides wireless connectivity. This is an option more commonly seen in phones or tablets, rather than full laptops. Fortunately, the Avastar is supported well under Linux by the mwifiex_usb driver. Depending on your distro you may need to update your linux-firmware package or your kernel version.

You might want to follow kernel bug 60815 for additional information and for links to the updated firmware images.

So far, despite all the reports, the only problem I’ve had with the Avastar is that, when doing light traffic, will fill your kernel ring buffer with a terribly useful “-ENOSR is returned” warning message. This is what Google has to say: “These occur frequently, but don’t seem to hurt anything.”. So I’m not very worried, but will update if I start getting problems. I did have a kernel panic at one point which seemed related to the mwifiex_usb.

Enabling USB autosuspend on this device kills the Wi-Fi connection, so take care if your distribution is enabling autosuspend automatically on all devices. USB autosuspend for the mwifiex has been disabled altogether in recent kernels, though.

Touch Cover

I got a v1 Touch Cover for free. It is disabled automatically when it is flexed behind the tablet, even without any specific any support from the OS. Touchpad works with two finger scrolling. From the special keys, the Windows 8 ones (search, share, devices, settings) don’t work. I seem to be getting the same keycode for all of them. Didn’t research much into the problem, though.

Also: No hotplug of covers. It seems that they are not “simple” USB devices at all. Plugging/unplugging the cover sometimes causes an ACPI error.

Type Cover v2

The type cover v2 is a different beast because it has a so called Precision Touchpad. Precision touchpads can act both as simple HID mouses (so the firmware handles all the gestures on their own) or HID multitouch devices. Seems that some HID work is required in order to get the touchpad to work in to multitouch mode, so for the time being it is stuck in mouse mode.

Since the HID report descriptors are always the same, ignoring whether it is in mouse or multitouch mode, Linux recognizes the entire composite device as a multitouch screen. And, for some weird reason, this means that a separate HID driver is used (hid-multitouch). Since this driver is specific for multitouch devices, it will happily ignore keyboard key press and mouse movements. No multitouch events will be generated because the touchpad is not in multitouch mode. The net result is that nothing works.

Fortunately a patch is floating around that hardcodes the v2 type/touch covers to use the standard hid-generic driver.

Touch screen

The device has both a capacitive touchscreen and Wacom. The capacitive touchscreen shows up as USB device, Atmel maXTouch Digitizer, and works out of the box, including at least two point multitouch. No good use can be made of it under most desktop environments, though.

On the other hand, the Wacom digitizer is present under the same USB composite device as the type covers and the volume up/down buttons. This device has the curious product name MICROSOFT SAM.

Out of the box this means that the Xorg wacom driver will not be loaded, thus no pressure sensitivity nor eraser support will be available. However, with some patches the Xorg wacom driver can be convinced to load on the SAM’s Wacom HID device node, and from that point on everything works as it should.

I am still working on these patches. Feel free to contact me if interested.