Asus TX201LA
Asus Trio TX201LA is a good piece of recent (for 2014) hardware, which allows one to combine desktop, laptop and tablet in a single piece. In fact the tablet is a different story - detachable screen runs Android and is out of scope. Nevertheless the base itself (which can serve as desktop) or with attached tablet (forming laptop) can boast Intel Haswell Core i7 or Core i5 CPU, 4G RAM and 500G HDD. And that is what running Linux, almost smoothly.
Install
You can follow standard Installation process. No problems with UEFI spotted.
WiFi
When installing from 2014.12 image running on 3.17 kernel wifi for some reason doesn't work. It seems it works for some older versions, and for 3.18+ but with 3.17 you'd probably need some USB wifi. WIFI is detected, wpa_supplicant runs on it however it cannot associate in any band. It seems it's caused by way too restrictive regulation settings, so you may also try to adjust AP settings for safe channels (1-11, 36-44) and sit closer to AP to get it working.
Don't forget to install crda among other required wireless packages to apply less restrictive regional regulation domain settings.
pacman -Syu iw iwconfig wpa_supplicant crda dhcpcd
This together with 3.18 or newer kernel make wifi work somehow. To improve WiFi quality even better adjust power management settings, effectively disabling any kind of power management for wifi. E.g.
echo 'options rtl8821ae ips=N fwlps=N swlps=Y' > /etc/modprobe.d/wifi.conf
to switch to software PM. If even that doesn't help you may switch off PM now by
iwconfig wlp2s0 power off
It's really about power management, not power supply for the card (which is managed by rfkill). Or to preserve it permanently across reboots
echo 'ACTION=="add",SUBSYSTEM=="net",ENV{ID_NET_DRIVER}=="rtl8821ae", RUN+="iwconfig $name power off"' > /etc/udev/rules.d/wifi.rules
Troubleshooting
SATA
You may notice during installation or on initial reboot plenty of ata errors, like CRC or READ FPDMA QUEUED - those are result of SATA speed mismatch. Controller is capable of 6Gbps while internal HDD is really poor (you'll definitely notice that over time) and can run only at 3Gbps. That will add boot delay until libata figure out workable speed, by probing and resetting. You'd probably better to enforce 3G speed by adding boot commandline parameter libata.force=3.0Gbps. To apply on next boot you can edit /boot/grub/grub.cfg and add it stright to proper section, or, add it to /etc/default/grub after quiet option and regenerate config:
sed -i 's/quiet/quiet libata.force=3.0Gbps/' /etc/default/grub && grub-mkconfig > /boot/grub/grub.cfg
Kernel
Even though system is capable of running 3.18 kernel it maybe worth spending some time compiling newer 3.19 kernel until it is packaged. With 3.18 kernel you may experience various lock-outs, hang-outs and even kernel panics - due to inadequate memory and resource management. On the other hand 3.19 is running much more smoothly, although it's still RC at the moment (rc4+). That also includes more stable PM and suspend/resume.
When configuring kernel don't forget to enable drivers/options for following device specific components:
Component | HW Name | Kernel menu item |
---|---|---|
WIFI | Realtek 8821AE | Device Drivers -> Network Device Support -> Realtek rtlwifi family -> Realtek 8821AE |
Touchpad | Elantech EPS/2 Touchpad | Device Drivers -> Input device support -> Mice -> PS/2 Mouse -> Elantech PS/2 Protocol extension |
Touchscreen | Atmel maXTouch Digitizer | Device Drivers -> HID Support -> Special HID Drivers -> HID Multitouch Pannels |
Bluetooth | Realtek USB HCI | Networking Support -> Bluetooth Subsystem Support -> Bluetooth Device Drivers -> HCI USB Driver |
Audio | Intel HD + Conexant | Device Drivers -> Sound card support -> Advanced Linux Sound Architecture -> HD Audio -> Conexant and HDMI |
WebCAM | Chicony HD USB Video | Device Drivers -> Multimedia Support -> Media USB Adapters -> USB Video Class |
ACPI / Keys
Special keys and of course backlight. Neither works out of the box if your BIOS is old. The only way then which seems to be somehow working to deal with backlight is using xrandr, but even that is not really decreasing backlight, rather as command says changes brightness:
xrandr --output eDP1 --brightness 1.0
It accepts values from 0(off) to 1 and above, but above 1.5 it becomes overexposed. Workable range 0.0 to 1.2, good default would be 0.5 (which you can put into your local xsession rc file.
Onboard function keys for brightness give acpi parser errors with such old BIOS, something like
ACPI Exception: AE_AML_PACKAGE_LIMIT, Index (0xFFFFFFFFFFFFFFFF) is beyond end of object (length 0x10) (20140926/exoparg2-420) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_._Q0E] (Node ffff88011a448820), AE_AML_PACKAGE_LIMIT (20140926/psparse-536)
and neither acpi_os=Linux nor acpi_os="!Windows 2012" helps. But if you enable auto-backlight in windows and reboot to linux - autobacklight remains working through firmware - which is handy, even though you cannot influence it (if only by covering light sensor - to decrease backlight).
If you upgrade your BIOS to latest (eg. 215) - backlight keys are working then via firmware - although in somewhat restricted range, and only after rebooting from windows. To make them work without dependency on windows add following options to module asus-nb-wmi:
echo "options asus-nb-wmi wapf=4" >> /etc/modprobe.d/asus.conf
and add acpi kernel parameters acpi_backlight=vendor acpi_osi=Linux acpi_osi='!Windows 2012'
Also you can turn backlight on and off and that either by setting brightness to 0 or bl_power to 1.
There are multiple special keys available under the same ACPI event key: Display-Off key (fn+F7), Camera key (fn+V), Screen-profile (fn+C), Auto-backlight (fn+A) and Touchpad-Off (fn+F9). All of them are generating
PNP0C14:00 000000ff 00000000
which makes them useless for acpid. Screen profile key though generates in addition another event (eg, two events are emitted)
button/prog1 PROG1 00000080 00000000 K
so you can bind toggle script which enables/disables backlight using both knobs (in case you turn it off by one of them while debugging). Something like
#!/usr/bin/bash SYS=/sys/class/backlight BLD=intel_backlight PWR_KNOB=$SYS/$BLD/bl_power BRT_KNOB=$SYS/$BLD/brightness PWR_VAL=`cat $PWR_KNOB` BRT_VAL=`cat $BRT_KNOB` if [ $BRT_VAL -eq 0 -o $PWR_VAL -eq 1 ]; then echo 0 > $PWR_KNOB echo 99 > $BRT_KNOB else echo 1 > $PWR_KNOB echo 0 > $BRT_KNOB fi
which could be hooked into system by simple file like /etc/acpi/events/bl
event=button/prog1.* action=/etc/acpi/bl.sh
Additionally volume keys are sending proper acpi events (MUTE/VOLUP/VOLDOWN) so could be bound to the system or left for app to react since they are also sending proper XF86 scancodes.
Other keys sending proper scancodes are XF86TouchpadToggle (fn+F9), XF86WebCam (fn+V), XF86Launch1 (fn+C), XF86Launch6 (fn+Space) and undefined NoSymbol with keycode 248(fn+A) - AutoBacklight. Even though not labeled on the keyboard - fn+F3 and fn+F4 are generating XF86Mail and XF86WWW correspondingly.
Useless keys then are Wireless/Airplane-Mode(fn+F2), Backlight (fn+F5-F7) and DisplaySwitch (fn+F8) as they are not generating any events.