I’ve wanted a tablet running GNOME on GNU/Linux for a while now and, based on past experiences, I know that trying to run it on an ARM processor would be a driver nightmare (I’m still disappointed that my Genesi Efika MX smartbook is permanently stuck on Linux 2.6.32 or thereabouts due to lack of support…it was a nice little device). So, when I saw the opportunity to pick up a Lenovo ThinkPad Helix 2nd Gen 2-in-1 (released in 2015) laptop for a relative steal, I jumped at it. This is a convertible device: it has a tablet top and a keyboard base (a real, mechanical laptop keyboard, not some keyboard-in-a-tablet-case thing). With a standard x86_64 Intel processor, I figured it would be more straight-forward to get up and running than an ARM device. Plus, since it’s a few years old now, I assumed that most hardware quirks would have been sorted out in the kernel by now.
For the most part, these assumptions were correct. I was in business pretty quickly as far as laptop features were concerned. I want to stress that in case there are readers who are frothing at the mouth at the opportunity to criticize Linux for its hardware support: for the average parts, this was a 100% pain-free installation. Tablet functionality, however, has taken a bit more work to get sorted out. I’ve outlined the technical steps that need to be taken to get the device to a satisfactory state over at the Arch Linux Wiki, but here’s a basic look at what it entailed.
The biggest challenge was figuring out why the sensors like the accelerometer (for automatic screen rotation) and ambient light sensor (for automatic screen brightness adjustment) weren’t working, despite having all the right libraries installed. All of my digging around eventually led me into the kernel source code where I found that a fix specific to this device had been added a couple years ago. However, in a general clean-up of device-specific fixes, it was subsequently removed.
Unfortunately, the all-purpose fix that the module maintainers added
did not work for the Helix 2. Indeed, if I downgraded to Linux 4.13,
the last version that included the patch, the sensors worked.
Fortunately for me, the file where the offending code resided hasn’t
otherwise been touched since then, so I could revert the "clean-up"
commit cleanly. I created a patch, compiled a custom 4.16 kernel,
and, voila, I had my sensors. There is still a strange quirk where
you need to suspend and resume the device once after booting to get
the accelerometer into a normal state, but I can live with that.
(Fixed!)
Ah, suspend and resume. That’s the other big topic. I had seen in my research before buying the system that there were some problems with it not resuming after suspending to RAM. I figured that this would have been sorted by now. Indeed, my desktop at work has an Intel processor from the same era and couldn’t resume from suspend until a couple months ago. I figured it was the same bug. Wrong. As I re-read the (long) original bug report more carefully, I found out that the system doesn’t support suspend-to-RAM. It only supports suspend-to-idle (aka "freeze"), however the BIOS misreported its capabilities and still allowed suspend-to-RAM.
You can tell systemd to suspend to idle, so that was easy to take care of the root problem. Nevertheless, bugs still existed where it couldn’t resume in certain situations like after undocking while suspended. Recent BIOS updates from Lenovo claimed to fix some suspend/resume issues (in Windows), so I went ahead and updated (fortunately they provide bootable disc images!) and voila #2, suspend and resume now works in all cases. Interestingly, comments in the bug reports based on intermediate BIOS versions claim that it still has problems, but it seems that with the latest BIOS, now everything is fine.
The last major task was getting multi-touch to work on the screen. I
could do two-finger scrolling with it as if it were a touchpad, but
that’s it, no pinch-to-zoom, etc. The touchscreen is a Wacom tablet
device, but I couldn’t find any good information online in wikis or
forums. Most people said it "just worked". However, once I dug into
the xf86-input-wacom driver for X11 documentation, I found that if I
somewhat counter-intuitively disabled the Gesture option in the
driver, I would have full multi-touch. See, the driver was only
designed to handle two-finger touch events. By the time that
multi-touch was becoming more common, they decided to let other
software handle the events. So, with Gesture disabled, the driver
passes multi-touch events on to the X server where they can be handled
by, e.g., GNOME. So, just like that, multi-touch worked.
A minor feature that bugged me was that, out of the box, the "rotation lock" button on the tablet doesn’t do anything in GNOME. I found that the button is visible to the kernel as part of an Intel Virtual Button device, but of course there’s no code anywhere in the system responding to its button-press events. So, I hacked together some code to do just that (actually, maybe "hacked" isn’t the right word…"over-engineered" might be more appropriate). It’s a small daemon that lets you lock and unlock the screen orientation by hitting the rotation-lock button. It also supports automatically locking/unlocking the orientation when you dock/undock the tablet. I say it’s over-engineered, because this could probably have been done in a small Bash script, but I wanted something that wouldn’t be spawning sub-processes to do this simple task. So, this uses the libevdev and GSettings (from GLib) libraries directly to handle events and change settings, and it comes with a systemd service file to launch it.
So, that gets the system to a place where I’m quite happy with it. Not everything works, sadly. The fingerprint scanner, for example, would be super-useful for logging in while in tablet mode, however as far as I can tell, it’s completely invisible to the kernel. So, no drivers and no simple event system to tap into mean that it’s just a lumpy decoration on the back of the device. I also haven’t tested Bluetooth or the SD card reader yet, but I don’t really have much of a need for them. Finally, I would also love to replace the wifi with an Atheros-based chip so I can ditch the non-free firmware, but I’m not sure if it’s possible with anything other than a USB dongle.
As for the actual GNOME tablet experience, well, it’s ok. Unfortunately, software support for this kind of device is still a mixed bag. A particular problem is widget support for touch interaction. GNOME/GTK+ is mostly ok in this regard, but some widgets are small by default. At the moment, I’m experimenting with taking advantage of the relatively high DPI of the screen to have desktop scaling at 200% (on 1920x1080 resolution), and then scaling down my fonts to a normal size. Everything’s big and chunky, so easy to manipulate, but of course a lot of screen real estate is wasted.
Screen rotation is quite slow and noticeably blanks the whole screen while rotating. There’s also pretty bad tearing while scrolling in portrait orientation. The ambient light detection leads to very rough screen-brightness transitions; I’ve disabled automatic brightness adjustment altogether. Finally, I hate all of the on-screen keyboards. GNOME’s is pretty but pretty light on features. Onboard is ugly but featureful (I haven’t looked for new themes, though), but it has a hard-dependency on X11 do draw it as an overlay, so it appears to be a no-go on Wayland.
Overall, I’m quite pleased though. GNOME in fact has a very pleasant design for touch interaction (but I’ve been happy with GNOME 3 on the desktop since it launched). As such devices become cheaper and more common, hopefully more development attention will be given to supporting them. I hope that what I’ve written here and at the Arch Linux Wiki will help other people trying to get their device to work. Happy hacking!