As an early Christmas present from my girlfriend I recently got myself a Lenovo IdeaPad Miix 320 to replace my old faithful Acer netbook. Whilst still perfectly functional, my little netbook is really starting to reveal its age, even with its harddrive replaced by an SSD and its RAM upgraded. Using Xfce on Arch I still happily used it, but the limited screen resolution (1024×600) finally prompted me to upgrade.
The Miix 320 is a budget 2-in-1 laptop, thanks to magnets you can detach the screen from the keyboard and use it as a tablet. The base model has a 10.1″ screen using a 1280×800 pixel resolution and it cost me around €150 on Ebay, but there are dearer versions as well with more RAM, more storage and a full-HD screen. For a budget model, the build quality is quite good, but you need the judge the device for what it is. It runs on an Atom processor and eMMC storage and is by no means a powerhouse. It certainly won’t replace my deskop pc. It comes with Windows but, what I like best about it thus far: as it turns out it runs Linux rather well.
I am by no means the first to try Linux on this machine: you can find a few valuable resources on the internet such as Mansoor’s blog on Ubuntu 18.04, this blog on Debian, another one here on Lubuntu and quite a useful page here (in German, get your dictionary out) on Ubuntu. However, time never stands still in the world of technology and a few things have changed for the better in recent days. Here I describe my experience loading Arch Linux onto the Miix 320. I like Arch for the lack of bloat and good documentation (contrary to popular belief, I don’t think Arch is difficult. But it definitely is more time-consuming). If you’re new to Linux you might want to try something a little more aimed at starters and I would recommend Fedora (I think it makes sense to run a cutting edge system on these machines. Newer kernel versions have improved the experience a lot lately. Hence why I would say Fedora over Ubuntu).
Starting the installation
On older kernel versions the Miix 320 would need a few kernel parameters to start the installation ISO. With the Arch ISO (01/11/2018) too I had to set acpi_backlight=vendor and acpi_osi=Linux at the Grub2 prompt because of a problem with a backlight pwm module. The bug has been reported here. You’d get an error somewhere during boot and the screen would go blank at the login screen. Apparently opening and shutting the lid a few times brings the picture back, but with above kernel parameters I had no issues.
Interestingly enough, after installation, I can boot into the new installation without any parameters. From here it’s relatively smooth sailing as a lot of stuff works without further intervention. In the ideal world that would be the end of this article, but here and there some fine-tuning was still needed.
X11 vs Wayland and Gnome vs Plasma
Using Gnome on a touch screen device would make a lot of sense. Its interface, with its headerbars and large buttons is quite touch-friendly and gesture-oriented. Gnome has very decent support for Wayland with only a small few issues remaining. And Wayland works well with touchscreens and tablets, or at least much better than X11. Under the Gnome Wayland session, the screen rotation works out of the box, and things like a virtual keyboard and gestures are better organised than under X.
However… Gnome is not the most lightweight option and this is a computer with limited resources. Gnome runs a bit sluggish. That, and the fact that I personally prefer KDE’s Plasma desktop, made me choose Plasma for this install. I like the configurability of Plasma and dislike the trend in Gnome of removing UI elements that have worked for decades; like the menubar. That little hamburger-icon is inferior! I haven’t tried Plasma and Wayland that much yet, I know there are a few issues unresolved. When I did give it a go I had just gotten the screen rotation working under X and under Wayland it was all messed up again, so I quickly went back to X.
Touch screen and gestures
Getting the screen rotation to work under Plasma was fairly straightforward; the package kded_rotation can be installed from the Aur and provides a module that does the rotating business using the accelerometers with a nice notification in the centre of the screen. It’s not just the screen that needs rotating, the touchscreen driver also needs to be told to rotate. Don’t forget to add your touchscreen’s name in the /usr/bin/orientation-helper file:
The log-in screen still showed up in portrait. A few lines added into /usr/share/sddm/scripts/Xsetup remedied that.
#!/bin/sh # Xsetup - run as root before the login dialog appears xrandr --output DSI1 --rotate right xinput set-prop $(xinput list --id-only "FTSC1000:00 2808:1015") "Coordinate Transformation Matrix" 0 1 0 -1 0 1 0 0 1
One of the Miix 320’s main features is that it can be used as a tablet. Now I’m the first to admit Linux and Plasma are not the best suited candidates for a tablet. The main problem here is that most apps are designed for mouse and keyboard, not a touch screen. But that goes for a lot of the UI elements inside Plasma as well. Touch screen gestures, such as three or four finger pinches and swipes, do not work out of the box under X (or technically, it’s up to the application, and Google Chrome / Chromium actually support them very well, but most do not).
This is where the situation on Linux at the moment is a little bit in limbo. On the one hand, there’s Wayland with improved gesture support, a better virtual keyboard, automatic screen rotation etcetera, but it’s not quite finished yet. And on the other hand there’s X, where all these things can be made to work, but not quite as easy or as well as on Wayland. On X there’s not a lot happening to make it better, since we’re all just waiting on Wayland.
Anyways, back in the day when Ubuntu touch was still a thing, based on some of its underlying technology, a program called Touchegg was developed. It allows for multi-touch touch-screen gestures. I’ve tried it on Fedora before but it wouldn’t even compile (due to odd Ubuntu-dependencies) but on Arch it was relatively easily pulled in from the Aur. A hurdle: Touchegg does not like the new libinput driver now used for input under X and Wayland. So I installed xf86-input-evdev and created a config-file /etc/X11/xorg.conf.d/10-evdev.conf. Use the command cat /proc/bus/input/devices to find the touchscreen’s event handler number (8 in my example).
Section "InputClass" Identifier "touchscreen with gestures" MatchDevicePath "/dev/input/event8" Driver "evdev" EndSection
Now, add touchegg to your list of apps to autostart (under Plasma in System settings -> Startup and Shutdown -> Autostart). Using touchegg-gce you can configure your gestures. For now I’ve added a three-finger-swipe left for the application dashboard, a three-finger-swipe right for the application spread (the Mac OS exposé thing) and lastly a two-finger tap set up as a right-click to bring up the context menu. The computer is actually quite usable in tablet-mode this way. Onboard is the virtual keyboard I like best, but it can only show up automatically for text input within Gtk apps (untested) so you’ll have to click its icon in the systemtray when you want to enter text.
Note: for libinput, a tool called libinput-gestures is often suggested. But this does not work with touchscreens, only touchpads. You can still use it in conjunction with my setup and configure gestures with it for the touchpad. Or, alternatively, set the system to load the synaptic driver for the touchpad and use it with touchegg too.
One of the remaining issues was the S3 ‘suspend to RAM’ mode, often just called ‘sleep mode’. It was not working: the screen would go blank but something kept the tablet awake and it would not enter the S3 mode properly. I’m not sure how efficient the sleep mode actually is – these tablets under Windows use something called Connected Standby. This lets the tablet poll for e-mail and notifications just like a phone whilst in sleep mode. I’ve never quite understood why I would want my tablet checking these things whilst I’m away, plus I already have a phone for this reason. And worst of all: sleep mode uses quite a bit of battery.
Anyway, the sleep mode not working had me vexed. Luckily the soon-to-be-released kernel version 4.20 will address it. It turns out the Miix 320 has a chip called the Intel Signal Processor to control the cameras. A driver for this chip was supplied in kernel versions 4.12 – 4.17 but then removed as it allegedly did not work very well. Without the driver, the chip would not get disabled at bootup and then prevent the system from entering S3 sleep.
Kernel 4.20 will have a dummy driver (Intel AtomISP2 dummy / power-management driver, under X86 Platform Specific Drivers) in it for the chip, its only function being to switch the chip off (put it in D3). This in turn allows the system to enter S0ix modes. Kernel 4.20 is not yet released, and the git-version on Arch did not have the driver enabled in the configuration. I had to manually enable the CONFIG_INTEL_ATOMISP2_PM flag and compile 4.20-rc4 but have since had the sleep mode functioning perfectly. The LED on the device now turns amber when in sleep.
Wifi, bluetooth, graphics, sound, touchscreen (multitouch), screen rotation, headphone jack, battery indicator and power management.
The SD card slot is a tricky one. When I insert a card the BIOS phase of the startup takes considerably longer, but does eventually succeed. When booted up, the system can see the SD card. But when I start KDE’s partitionmanager to create my partitions, the screen goes completely black and unresponsive. It all comes back to live when I remove the card. The erratic nature of the behaviour, coupled with the fact it’s a bit of hassle to insert and remove SD cards, has not made me test this more. To be continued, as I would like to be able to expand the storage.
Secondly, the Miix 320 has a camera on the front and on the rear. I touched on it earlier already: they are connected via a chip called the Intel Image Signal Processor and there is no driver for that chip. So even though the actual camera modules (front: ov2680 and rear: ov5670) are supported by the kernel, it cannot ‘see’ them and therefore the cameras do not work. It is not expected this will change in the near future. Kernel version 4.12 actually had a driver for the module but it was removed as it allegedly did not work. It is also said the computer won’t let you use the microphone but I have not tested this. To be fair, the cameras in this device are nothing to write home about (most tablet camera modules aren’t, it dazzles me to see so many people use them in public – but these are particularly shoddy) and as a result most people, including myself, won’t care too much about them not working. Still, they could prove handy for a family Skype sometime when WhatsApp is being slow.
My loyal Acer D257 netbook will go into retirement. Or better yet; I’ll find another use for it. Likely to be an MPD server in the kitchen or a pi-hole on my network. If you have any other ideas, let me know in the comments :-). For now, I’m actually impressed by how well the Lenovo Miix 320 is working with new Linux kernel versions. When I got the device a few weeks ago I had not expected it to work this well, particularly considering all the caveats from the past outlined on other sites.