Preface

Last (Big) Update: 30/05/2020 | Ninja Edits: 23/06/2021

Hello World

A perpetual work in progress (5-ish years now) and pretty damn complete. If you have time, you too can have Linux on your Bay Trail device and learn why things work and do not work. Primarily this article focusses on the Venue 8 Pro.

Firmware Update, 23.06.2021

I still have outstanding DV8P correspondence that I need to tend to, but this merrits a quick update. Via a courteous internet traveler, I was informed of an alternate firmware that is referenced here.

The GitLab environment in question belongs to Rigado an IoT manufacturer that has uses hardware which appears to use the same revision ath6k chipset as the DV8P. The difference is "fw 3.5.0.349-1 api 5" vs "fw 3.5.0.604 api 1" and in the past 3 weeks of testing it looks to have done away with the problematic 35 - 45 minute functionality cycle.

The "Vesta edition" of the ath6k firmware can be found here. Despite this being an "unofficial" source, I do not perceive it as malicious. A binary comparison (Left: New, Right: Old) shows mostly the same things (as expected). But Caveat Lector and something something proprietary.

As far as my DV8P is concerned, it works a treat. The only persistent bug I am seeing is that this firmware will crash on suspend and leaving a "deepsleep suspend failed" message in the logs (suspends fine), WiFi comes back to life on resume regardless. There will be a couple of "Direct firmware load" error mentions on startup, but these are safe to ignore.

I would still recommend to experiment with disabling WLAN power management if network latency or connection drops are a concern.

Fedora Powered Update, 07.06.2021

Go install Fedora 34. Put ISO on a USB stick, boot, install, have a cup of tea and after 30 minutes or so it is all ready.

Gnome on Wayland works a treat. Pen input, touch input works fine. On-screen keyboard has improved since I last tried, some on-screen arrow keys would be nice when dealing with terminal input.

Wifi still needs its own firmware package but that will not change in the forseeable future due to licensing. Currently waiting to discover how good / bad connectivity behaviour / times are.

Picked up a TP-Link UB400 Bluetooth 4.0 USB dongle (0a12:0001 - Cambridge Silicon Radio, Ltd), works great with the original Venue 8 BT keyboard. Media keys work as expected. Multi-key rollover is fine, fn + ctrl + alt + function key will switch to desired TTY. Can disconnect the dongle at any time, plug it back in and keyboard comes back. 

# btmgmt

[mgmt]# info
Index list with 1 item
hci0:   Primary controller
        addr 00:1A:7D:13:37:AD version 6 manufacturer 10 class 0x6c010c
        supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration
        current settings: powered ssp br/edr le secure-conn
        name BlueZ 5.58
        short name
Notes for future use, will get its own segment (eventually):

Venue 8 BT Keyboard model K07M. 3V 20mA, 2x CR2025 Button Cells.

btmon reports serveral LE events, so currently assuming the K07M is Bluetooth 4.0LE compliant. 

# bluetoothctl

[DELL Keyboard]# info
Device 90:7F:61:10:B3:4D (public)
        Name: DELL Keyboard
        Alias: DELL Keyboard
        Appearance: 0x03c1
        Icon: input-keyboard
        Paired: yes
        Trusted: yes
        Blocked: no
        Connected: yes
        WakeAllowed: yes
        LegacyPairing: no
        UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
        UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
        UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
        UUID: Battery Service           (0000180f-0000-1000-8000-00805f9b34fb)
        UUID: Human Interface Device    (00001812-0000-1000-8000-00805f9b34fb)
        UUID: Scan Parameters           (00001813-0000-1000-8000-00805f9b34fb)
        Modalias: usb:v04F2p1330d0105
        Battery Percentage: 0x52 (82)

Fedora Powered Update, 14.05.2020

Anyone who ends up here trying to install Fedora 32 here's my quick notes.

There is an EFI related bug (happens to manifest on 32-bit UEFI) that seems to get triggered the moment Anaconda has finished the software install stage and goes about installing bootloader related material. The install process is basically dead at this point as the kernel throws its virtual arms in the air. This applies to Fedora 32 install media using kernel 5.6.6

i 1013.257618] BUG: unable to handle page fault for address: 000000001c4fce98
[ 1013.257626] #PF: supervisor write access in kernel mode
[ 1013.257629] #PF: error_code(0x0003) - permissions violation
[ 1013.257632] PGD 72950063 P4D 72950063 PUD 72951063 PMD 1c4000e1
[ 1013.257640] Oops: 0003 [#1] SMP PTI
[ 1013.257645] CPU: 3 PID: 3739 Comm: systemd-udevd Not tainted 5.6.6-300.fc32.x86_64 #1

I initially thought maybe it was an SMP related bug and tried booting with "nosmp". This however resulted in Anaconda not finding the eMMC storage device but as a last attempt I disabled multi-core support in the system BIOS.

(Volume Down / F2 @ Power On) > BIOS > Advanced > Multi Core Support

Set to "1" vs "All", revert after install + update is done.

This hunch resulted in Anaconda finishing the installation process succesfully. (Be advised that it will take a while, I think the whole process took about 1.5 hours as with a single CPU core the system spent most of its time at a load of 4 - 4.5)

As per the bug report above the fixes for this should already be upstream, so after the installation completed and doing a round of updates I turned all cores back on and my Venue 8 appears pretty happy sofar on kernel 5.6.11-300.

If you get "stuck" when updating SElinux related packages you'll probably find "restorecon" eating up CPU cycles, give it about 25 - 30 minutes. After the relabelling process is done DNF will continue and finish up.

Initial impression are _very_ good. Headphone detection works now, microphone input with an iPhone headset as well as the internal microphone switch and work fine, there is no more need to deploy UCM files to make audio behave right, touch works, IIO proxy + Wayland makes screen rotation happen in a literal "blink". The only "manual" labour sofar has been installing the ath6k firmware blobs. I'll let it do random things over the next few days, if I find something truly egregrious my dear reader I'll let you know.

Venue 11, Writings have moved.

- DV11P Writings -

In an effort to clean up and get to a point where only the latest information is on the base index I've begun migrating material for the DV11P to it's own page. The current index was already 95% Venue 8 oriented anyway.

Venue 8, Archived writings.

- DV8P Archive -

Like the Venue 11 segments, there's alot of cruft about the Venue 8 dating back to Kernels from yoinks ago. If you are missing something here there is good chance it's in the Archive.

The News

I'm currently testing Fedora 32 and, as of writing, my Venue 8 is at an record uptime of 6 days and 2 hours whilst discharing, charging, disconnecting, connecting, removing kernel modules, probing kernel modules, suspending, unsuspending, etc. Sofar I've had a couple of moments where I was anticipating the device had crashed but a little patience and pushing one of the hardware buttons would prove me otherwise.

I'm currently preparing a 2.0 of "iwup.py" which is a little tool I made in Python that monitors the WPA Supplicant and then reloads the kernel module if WiFi throws a wobbly.

It's been a long time since kernel 4.12 which, to me, fixed the most egregrious issues and made the tablet usable as long as you adhered to a couple of rules. Primarily, Do not hotplug USB and do not suspend. This was fine for me since I mainly used it for inflight entertainment and bits of nerdery after which it was turned off again. It is a delight to see all the improvements that have come to the latest Kernel.

<pre> Blocks are still horrible, for now hover to see the full content or use links, lynx, elinks. Re-doing CSS eventually.

Shout Box

A warm and sincere thank you to the 26500+ or so people (May Stats) that have come by and explored this slab of text since January 2016.

Lastly a shout out to the Dragonbox Pyra which is slowly nearing completion!

The Pyra is a made and designed in Europe, community driven, niche and unique piece of hardware which combines the best of a miniature tablet with a hardware keyboard and full Linux support.

Google Bait

Running Linux on the Dell Venue 8 Pro (5830), Intel Bay Trail tablet with Arch Linux and Friends

Ye ol' Index

Demo Time

Venue 8, Kernel 4.7.0, USB Rpi Wifi + Keyboard.
Hello Sway on Wayland.
- Full Size, 1920x1440, 277KB -
Venue 8, Kernel 4.4.0, USB Wifi + Keyboard.
Much usable, Very Linux, So wow.
- Full Size, 1920x1440, 360KB -
Kernel 4.12.0, E21, Terminology, Onboard
An unsuspended portrait of Antergos.
- Full Size, 1280x800, 248KB -
Venue 8, Native 800 x 1280 EFI resolution.
Kernel 4.9+ handles EFI to KMS correctly.
- Full Size, 1920x1280, 271.5KB -
Kernel 4.11.0-rc2 (git), Enlightenment.
This is how a missing battery looks.
- Full Size, 1280x800, 197KB -

More screenshots in The Archive.

First, Thank you Internets

Because wizards should be celebrated.

Adam Williamson - For his work on the Bay Trail Fedlet.
John Wells - Valuable clues on running Linux on the Asus T100.
Bastien Nocera - Patch collection and LKML posts.
Pierre Bossart - ALSA UCM files for Bay Trail Audio.
Hans de Goede - Fixing EFI to KMS handover. (Pipe / DSI fixes)
Jan-Michael Brummer - Bay Trail Kernel work, Protips and other input.

Fellow Linux Explorers, Arch Wiki and Kernel Devs - For obvious reasons.

The information collated and provided were an immense help in getting started on installing Arch, other distros and getting going.

Project Status

Currently Running

Fedora 34 on Venue 8, Kernel 5.12.8-300

The TL;DR; Version

When I started this journey at the end of 2015 everything was pretty horrible.

We are now 4-ish years onwards, and I get this silly idea of installing Fedora 32. I figured with the various news posts and kernel mailing list items I've seen come by, the support for Bay Trail would have improved and it has tremendously so. I'm planning on doing a couple of distro hops but right now install Fedora and enjoy.

There's a number of distributions out there with Multi-Arch support meaning that the media comes with 32-bit and 64-bit UEFI support. With newer Kernel releases in place it's also alot less painful to get a distro to boot.

Booting a 64-bit kernel with Grub works fine combined with Kernel 4.10+. No startup workarounds needed anymore. If you intend to have your rootFS on a MicroSD card you will need to keep bug #150881 in mind.

If you are a kernel developer, this is my giant bug report with kisses and strawberries on top.

Just the facts Ma'am.

The Goal

Getting Linux operational on "niche" hardware, documenting it and learning from it.

With Linux working, keep functional hardware out of landfills because of user dissatisfaction with Windows and it's associated behaviours.

Less dramatically: do Linux things and enjoy some media while being in control of my operating environment and it's components.

The Why

Having procured a Dell Venue 8 Pro & 11 Pro for various reasons, the opinions whether these models can run Linux reliably and how it can run Linux are all over the place. With the Venue 8 Pro being a Bay Trail device much of this likely applies to similar hardware. (Asus T100, Asus X205, Etc.)

This slab of text is my contribution from over 4+ years of fun and entertainment sofar in the journey of this learning experience. Some of it may be flat-out wrong or relying on too much assumption, perhaps it will inspire you to think out of the box.

The overall somewhat irreverent writing style is because I can, if you are expecting a super serious engineering tone go read RFC's or MANpages.

Technically, to make it all work you are reliant on at the bare minimum the Kernel 4.4+ series as this brings in a number of hardware support features such as PMIC, CrystalCove and Intel Atom SoC Support where the Venue 8 Pro is concerned.

Realistically, Kernel 4.10+ is where you want to be for basic proper operation. Ideally though, Kernel 4.12+

Lastly this article is oriented towards explorers and enthusiasts so some assumptions are in place here and there. Some explanation may also seem rather verbose to answer the "If you did X what would Y then do".

Bug Reports

@kernel.org
-----------
#67921   - Dell Wireless 1537 / 1538 support
#73081   - Fail to setup bluetooth on Dell Venue 8 / 11 Pro
#86581   - Baytrail-T no sound
#96571   - [CHV] Backlight init fails on Surface 3
#97330   - [CHV DSI] black screen
#100356  - [DSI][BYT] Panel detection fail
#101205  - [i915][BYT] Blank screen on DSI panel
#109051  - intel_idle.max_cstate=1 required on BayTrail
#111481  - Call trace with snd_soc_sst_mfld_ platform when suspend to freeze 
#150881  - mmc0: Failed to request irq 8: -16
#1830149 - [abrt] suspend_devices_and_enter. suspend_test.c:53

@freedesktop.org
----------------
#31313  - X rotates display with delay and black screen effect
#82880  - Blackscreen on modesetting
#85977  - Backlight support Dell Venue 8 Pro
#96571  - Backlight init fails if module load order is wrong

Mailing & Reading List

@internets
----------
Arch Wiki :: Tablet PC - Tablet PC Protips
Arch Wiki :: TouchScreen - TouchScreen Calibration
Arch Wiki :: Touchegg - Multitouch Gestures
Alsa-Devel - Baytrail mixer settings
Alsa-Devel - Intel SST
Spinics - Crystalcove (CRC) PMIC based panel and pwm control
IIO Proxy - Industrial IO Sensor Proxy tool
EFI memmap - purpose of efi_memmap kernel argument
LKML - SDHCI Power Management on Bay Trail.
Intel Stick - Experiences similar issues as Venue 8 does.
ath6kl - AR600X series kernel driver
BayTrail Clocksource - Android works best with "tsc" clocksource

Device Status

Venue 8 Pro (5830) on 5.6.11-300

MicroSD Card Slot Notes

Per Dell: SD card slot speeds on Dell Venue Tablets

Thread: Dell Venue 128GB MicroSD card support

BIOS Notes

The internet mentions that in BIOS release A03 for the Venue 8 there were settings allowing HS200 support (LPSS & SCC Configuration) for the internal eMMC and DDR50 support for the MicroSD card slot.

I've had a brief look at modifying the A14 BIOS but AMIBCP doesn't show me any of the "setup configuration" options, which would make adjustment a click of the button, leaving me only with the DMI data and generic BIOS strings.

It's probably very unwise to flash the previous BIOS back on, it likely bricks the tablet and even if it worked would likely make the unit very unstable.

My current theory is that maybe just taking the setup EFI module from the A03 release and swapping it into the A14 release may do the trick but right now the A03 setup module doesn't even register as valid so something seriously changed in the overall firmware structure over time.

This is the lowest on my priority list to have another look at for the time being.

Hat Tip to BIOS-Mods for valuable clues.

Overall Experience

With a recent kernel (5.6+) the Venue 8 Pro is a functional device providing me with a laptop like experience when combined with a USB wireless keyboard and mouse.

With a light workload I'm getting to 6 - 8 hours, on a battery that currently reports having 3238 mAh (65% of design capacity) life left in it, not bad considering the age of the device at this point.
Stability is excellent, in testing I've enjoyed several days of uptime where this was once measured in hours.
WiFi can be hit and miss, but this also seems to be an issue on Windows if the Internet is to be believed. Average is ~35 minutes of connectivity before having to reset the card.

Running Linux from a MicroSD card with BTRFS nets about 15-20MB/sec throughput, despite this, startup to login is about 8 seconds and programs launch pretty swiftly. It's good enough for me anyway.

Internal MMC nets about 155 - 165MB/sec.

MPV plays 8-bit and 10-bit fansubs fine. 8-bit H264 content is processed by the onboard decoder when enabled. Audacious and friends provide audio content. Firefox does Internets. Chrome is a little more "Finger friendly".

Speaking of Audio, it's set to 48Khz so any 44.1Khz has to be resampled which incurs a cost of processing cycles and is heavily dependent on using Pulseaudio.

Multi-touch is functional, with "onboard" installed (onscreen keyboard) I can hold down multiple keys so I assume that works correctly. Wayland has a multi-touch test which shows the hardware is doing the right things. Having said that, trying to use a UI designed for a mouse with your fingers...

Pen input works fine. Up to 255 pressure levels and the button can be configured as left, right or middle click.

Pen makes for a reasonable mouse replacement and is smooth in usage.

Preliminaries

I often excel in the virtues of hedonism and such is the pleasure of having something "just work" so I've tested a couple of distributions.

If you go with Fedora or Debian you'll be up and running with relatively little effort. Other distributions require you to simply add the 32-bit bootloader to the install media and then may require you to manually deploy it again after installation.

Public Service Announcements

The Venue 8 has a 32-bit UEFI (despite being a 64-bit capable system) you'll need an install / live media that has "bootia32.efi" lurking around to get started.

Use the newest possible Kernel. Some things may not work regardless of how hard you try.

You'll likely need the updated Atheros Wifi firmware files, and a UCM file to get audio to work.

It may also be beneficial to blacklist "snd_hdmi_lpe_audio" in your /etc/modprobe.d/blacklist.conf (remix as appropriate) so Pulseaudio doesn't end up with a dummy output.

Depending on your distribution of choice you may find yourself compiling a kernel to get things working such as PWM support which is required for brightness controls.

Fedora: Rawhide Kernel

You can consider trying the testing Kernel which last I tested was at 4.13.0, it is able to adjust the screen brightness correctly and most things appear well behaved with my limited testing. 

dnf config-manager --add-repo=http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo
dnf update
dnf install kernel

Should your startup go all wonky consider temporarily adding "enforcing=0" to your Kernel flags and letting the system do an auto-relabel to keep SELinux happy. Upon reboot things should go back to normal.

Hat tip to the Fedora Wiki.

Blank Screen: Failed panel detection

On older Kernels the handover between EFI and KMS is less then ideal resulting in people being left with a blank screen or being forced to use the nomodeset flag to atleast get a console and unaccelerated Xorg working.

From Kernel 4.9 onward this issue is fixed. However there appear to be some isolated cases where despite the improvements made Bay Trail devices still end up with a blank screen.

Parker's Venue 8 is such a case. I've been trying off and on to find clues to no avail and then I got an email reporting success with a little bit of hackery. Have a look at bug reports #100356 and #101205 for more details.

Session Manager: GDM

GDM comes with an onscreen keyboard out of the box that is activated when it detects a touch event into user / password fields which is very practical.

Session Manager: SDDM

SDDM comes with an onscreen keyboard out of the box that has to be summoned with a touch on the "virtual keyboard" button, unlike GDM where the keyboard pops up the moment a touch event in an input box is detected.

Session Manager: LightDM

Many distributions default to LightDM and while basic accessibility features are there adding an onscreen keyboard may require a little bit of effort. The virtual keyboard support is provided via Onboard.

Add Onboard to LightDM

#/etc/lightdm/lightdm.conf
greeter-session=lightdm-gtk-greeter

#/etc/lightdm/lightdm-gtk-greeter.conf
keyboard=onboard

If you did it right "On Screen Keyboard" will show up as a selectable option under the accessibility menu.

uPower Daemon

If your device has an issue with battery management or is not able to detect Charger / AC correctly it may help to disable "upower" if you find your device shutting down the moment you log in to your graphical session be it using a Live system or an established install. 

# Append to Kernel Parameters to "stop" systemd before the GUI comes in.
# Usually accomplished by highlighting your boot option and
# then pressing "e" for edit.
# It may also help to remove "rhgb quiet splash" flags if present
systemd.unit=multi-user

# When prompted, press enter for maintenance mode.

# Remove executable powers
chmod -x /usr/bin/upower
chmod -x /usr/lib/upower/upowerd
pkill upower
pkill upowerd
systemctl disable upower.service

# Resume Booting
Ctrl + D or "exit" to resume boot to graphical.target

Should this not work as a last resort, pop to a TTY as soon as you can and quickly punch in those commands. I had to do it this way with Debian Live as the root account is locked at start up.

SquashFS

If you have a need to "remaster" a squashfs image, this is all you need. Keep in mind, the following assumes you have enough RAM with /tmp being tmpfs based. 

unsquashfs -d /tmp/casper -f /mnt/stick/casper/filesystem.squashfs

# remove, edit, remix, etc.

mksquashfs /tmp/casper /tmp/filesystem.squashfs

rm /mnt/stick/casper/filesystem.squashfs

cp /tmp/filesystem.squashfs /mnt/stick/casper/

bootia32.efi - 32-Bit Bootloader

Grub and 32-bit UEFI

The gist of the _un_official story [citation needed], as I've cobbled it together, is that Intel relented to Microsoft to provide a 32-bit environment on the platform because they couldn't get the InstantGo feature to work right on Windows 8 in a 64-bit environment. This was fixed with Windows 8.1 supposedly, however many OEMs would still ship a 32-bit version of Windows 8.1 making it kinda moot so the UEFI was kept 32-bit anyway on those devices.

Officially the story [mirror] is effectively one of cost and 64-bit Windows not being the best fit on low memory / space devices.

Previously it took a certain ammount of effort to get Linux booting correctly but since Kernel 4.9 things have been good.

Likewise a number of distributions now have support for 32 and 64-bit UEFI out of the box, look for "multi-arch", and others have announced support planning to do so in the short term.

The Fedora Project

I've been looking for a more "official source" to link to for a proper bootloader package and have found a very suitable option.

You can copy the loader out of the Fedora 27 ISO be sure to take both "bootia32.efi" and "grubia32.efi" or alternatively the Fedora Project has a ready made RPM package.

For the time being we'll stick with the Fedora 26 release package as Fedora 27 made everything modular "grub2-efi-2.02-0.40.fc26.i686.rpm".

It's recommended you move your downloaded RPM to a folder of it's own and then proceed with the commands below. 

# Extract's RPM to root of current folder.
rpm2cpio grub2-efi-2.02-0.40.fc26.i686.rpm | cpio -idmv

# If you have your install / live media ready.
cp ./boot/efi/EFI/fedora/grubia32.efi /mnt/stick/boot/efi/bootia32.efi

Sofar this version has given me the best possible odds at getting various distributions to boot.

Jeff's Github

Jeff's version seems more amicable to booting vanilla Ubuntu, alternatively you can roll it yourself and remix to suit.

Making an EFI System Partition

We're assuming the internal storage is void of any partitions and we just want a place to park the bootloader while we juggle another Live media. 

# Depending on your Live system
sudo -s || su

# Start Fdisk
fdisk /dev/mmcblk1

# Follow the prompts
"n" for new partition
"1" for first partition

First Sector: Enter for default
Last Sector: +100M

"t" to set partition type
"1" to set type to "EFI System"

"w" to write new partition table.

# Format new partition with FAT 32
mkfs.vfat -F 32 /dev/mmcblk1p1

# Make a mount point
mkdir /mnt/mmc_efi

# Mount 
mount /dev/mmcblk1p1 /mnt/mmc_efi

# Copy Loader
cp /some/src/bootia32.efi /mnt/mmc_efi/

Reboot and set a boot entry for your freshly copied loader in the BIOS and do some science.

Boot Flags

A number of distros use "linuxefi" and "initrdefi" in their grub.cfg for initialisation over the more common "linux" and "initrd" but they appear to be inter-changable.

This is a good thing because many of the "bootia32.efi" binaries out there lack support for these "*efi" commands. From what I can read these commands exist to handle a scenario in which SecureBoot is used and the entire boot chain is signed and verified.

Supported Distributions

Before you read on, scope out the P.S.A in the preliminaries above.

Keep in mind that most distributions are configured for a normal desktop or laptop scenario. Overall performance will vary pending your choice of desktop, filesystem and so on.

32-bit is dead. Long live 32-bit. As such, unless mentioned specifically otherwise, 64-bit releases are referenced.

Sofar in testing GalliumOS get's top marks from me as the distro that mere mortals can install and is amazingly fast out of the box.

Current Picks

Android X86: 7.1-rc1

The Android X86 7.1-rc1 release comes with 32-bit and 64-bit UEFI bootloaders, Kernel 4.9.31 and, as expected, makes touch input a first class citizen.

"Burn" iso to USB stick, insert stick, select from boot manager and the live session loads.

Some may experience the installer as a little cryptic. Basically use the paritioning tool to make two paritions. An EFI partition (type ef00) say 200MB in size as a safe bet and a Linux partition (type 8300). The installer will then ask which will be your root partition and then it will ask which parition to install Grub on.

The install itself takes minutes, deploys the right bootloader and after rebooting does the right thing.

Wifi, Audio, Rotation (with cold boot) work out of the box. The "meta" button next to the headphone jack doubles as a home button.

By default installation from "Unknown Sources" is disabled under Settings > Security. With this enabled F-droid is easily deployed.

With Kernel 4.12 this has the potential to be glorious and it's damn nice to see how smooth a UI can be on the Venue 8 compared to Windows / Linux.

Verdict: I'm not much of an Android user, but this has the potential to recycle so many tablets. Take it for a spin if you can.

Further Android Reading:

Antergos: 17.12

The Antergos install media comes with Kernel 4.13.12 out of the box.

Follow the steps as outlined to prepare your boot media just like you would for regular Arch Linux. Optionally you can add this antergos-grub.cfg for your convenience.

You won't have brightness control in the live session but after installation it works fine.

When doing automatic partitioning the installer doesn't like the Venue 8's MMC and tries to tinker with "/dev/mmcblk1rpmb" causing input/output errors.

RPMB is a Replay Protected Memory Block, the installer treats it as block device (when it shouldn't). Manual partitioning bypasses this issue. Remix as you see fit.

Antergos, Old screenshot, Still relevant, Manual partioning
- Full Size, 823 x 498, 77.3KB -

Let the installer run and let it finish, don't reboot and open a terminal. 

# Become root
sudo -s

# The installer has already unmounted everything so...

# Remount Root Filesystem
mount /dev/mmcblkp2p2 /install

# Remount EFI Filesystem
mount /dev/mmcblkp2p1 /install/boot/efi

# Change path
cd /install

# Prepare for Change Root
mount -t proc proc proc/
mount -t sysfs sys sys/
mount -o bind /dev dev/

# Change Root into the Install Base
chroot /install/

# These should already be installed by Cnchi.
pacman -S grub efibootmgr os-prober

# Deploy 32-bit Bootloader
grub-install --target=i386-efi --efi-directory=/boot/efi --bootloader-id=Antergos --recheck

# Generate a Config
grub-mkconfig -o /boot/grub/grub.cfg

Reboot and optionally make a boot entry in the BIOS if it hasn't yet. Also consider telling LightDM not to use a webkit greeter as I got a black screen the moment it started but manually starting an X session is fine.

Verdict: Arch install with a couple of clicks and relatively painless, what's not to like.

Arch Linux: ∞

Arch Linux has been getting the job done since the start of this adventure.

Verdict: You are awaited. You will read eternal, Shiny and Chrome.

Debian: 9.1.3

There are a number of media available from the project. If you want a 64-bit userland you'll still need a 32-bit bootloader. Debian has a solution for this in the form of their "multi-arch" release. Otherwise the i386 release has a 32-bit UEFI bootloader out of the box and just works.

The Debian 9.1.3 release ships with Kernel 4.9.0. This time around I tried to install the system using a WiFi dongle but Debian did not approve of my Raspberry Pi wifi or my Ath9k USB dongle. Not wanting to try my luck with the internal WiFi by adding blobs manually I went with USB Ethernet which was fine.

Verdict: Debian the "universal operating system". Hurray for Debian!

Fedora: Workstation 27

Fedora joins the party in being able to boot 32-bit UEFI systems out of the box. Live sessions work as you'd expect and Anaconda correctly installs the distribution itself with the appropriate bootloader. It's pretty much on cruise control start to finish.

However, it did take me 5 attempts to get the installer going. Anaconda just "hangs" during the disk setup depending on feels. Be patient, 5th time lucky it took half a minute for the installer to move along.

My major gripe is how memory hungry Fedora 27 is overall and how slow / laggy Gnome 3 is. It feels worse then Fedora 26. After startup with Gnome on Xorg, memory use averaged out to 907MB of memory that's almost half of the Venue 8's available RAM. Tumbleweed is doing a much better job here.

Grub to Login startup time averaged to 31.77 seconds. Then add another 16 seconds for your desktop session to start.

Minor gripe number one, my "landscape" view is upside down. Tumbleweed doesn't have this issue. Minor gripe number two, if I tell GDM to lock rotation after login this lock is ignored.

Verdict: +1 for 32-bit UEFI support, Good job Fedora 27.

Fedora: Performance
GalliumOS: 2.1

GalliumOS bills itself as "A fast and lightweight Linux distro for ChromeOS devices." being based on top of Ubuntu, it offers a Bay Trail optimised release which is what piqued my curiosity.

XFCE + Compton makes for a powerful combination and Kernel 4.12 is available from the testing repository. Meanwhile it's also one of the few distros that deployes zram out of the box for swap rather then the internal storage device.

You can try a straight boot from the Grub command line if you already have a bootloader on your EFI partition:

grub> root=(hd0)

grub> configfile (hd0)/EFI/BOOT/grub.cfg

If you've copied your bootloader to the install media try the following change. We edit "linux" to "linuxefi" and "initrd" to "initrdefi". This can also be done on the fly within Grub by pressing "e". 

# Original Boot Entry
menuentry "GalliumOS Live Image and Installer" {
  linux /casper/vmlinuz boot=casper file=/cdrom/preseed/galliumos.seed acpi_osi=Linux tpm_tis.interrupts=0 galliumos_hwspec=baytrail gpiolib.acpi_lookup_can_try_crs=1 quiet splash --
  initrd /casper/initrd.img
}

# Updated Boot Entry
menuentry "GalliumOS Live Image and Installer" {
  linuxefi /casper/vmlinuz boot=casper file=/cdrom/preseed/galliumos.seed acpi_osi=Linux tpm_tis.interrupts=0 galliumos_hwspec=baytrail gpiolib.acpi_lookup_can_try_crs=1 quiet splash --
  initrdefi /casper/initrd.img
}

The installer benefits from having a network connection so installing with a USB ethernet adapter is recommended over relying on only the install media. Without a network connection it will fail to deploy Grub.

Verdict: The live session just works and is very very snappy performance wise, snappier after installing. Speaking of which the installation correctly deployed a 32-bit bootloader upon completion. Alot of love has gone into this and it shows.

openSUSE: Leap 42.3

In the previous update I dismissed Leap with its 4.4 series Kernel but by chance I came upon a thread where Richard Brown, the chairman of openSUSE mentions that there's plenty of backported material in their LTS kernel effectively on par with the 4.10 series.

Here's what is missing:

In short, challenge accepted. Use Jeff's version of the 32-bit UEFI Loader as the Fedora one hangs after loading the init ramdisk. 

grub> configfile (hd0,msdos1)/EFI/BOOT/grub.cfg

Ignore the complaints Grub may have and make sure to add "nomodeset" to the kernel command line. You can now install Leap despite the installer looking a little awkward due to the display scaling. It won't install the bootloader for you but will finish everything up correctly. So before you reboot, copy your boot loader from the install media to your EFI partition and add a BIOS entry for it.

Then to boot your system: 

grub> linux (hd0,gpt3)/@/boot/vmlinuz nomodeset
grub> linux (hd0,gpt3)/@/boot/initrd
grub> boot

As promised, the system runs appropriately albeit without modesetting.

One could add a newer kernel from the Kernel Repo to compensate for this or go for Tumbleweed.

Verdict: I have a lot more admiration for openSUSE now.

openSUSE: Tumbleweed

The eternal rolling release with all the latest goodness. Went with the KDE Plasma install which is actually very enjoyable to use on the Venue 8.

The Tumbleweed ISO is 2 parts, 1st part is boot segment, 2nd part is data. Same as Fedora, "linuxefi" and "initrdefi" are used so we'll take the following steps. 32-bit UEFI boot support has been discussed but hasn't shown up yet.

So with that in mind, the following applies: 

dd if=openSUSE-Tumbleweed-DVD-x86_64-Current.iso of=/dev/sdX status=progress

mkdir /mnt/stick

mount /dev/sdX1 /mnt/stick

cp /some/src/bootia32.efi /mnt/stick/EFI/BOOT/

# Depending on how well made your bootia32.efi is.
find /mnt/stick/EFI/BOOT/grub.cfg -type f -exec sed -i 's/linuxefi/linux/g' {} \;
find /mnt/stick/EFI/BOOT/grub.cfg -type f -exec sed -i 's/initrdefi/initrd/g' {} \;

umount /mnt/stick

If you are left at the Grub startup prompt try the following, you have tab completion powers. 

grub> configfile (hd0,msdos1)/EFI/Boot/grub.cfg

Grub may or may not complain about a couple of things missing but at the minimum you should get a selection menu to start the installer.

From here do as the Romans do. Follow the installer steps and let the installer do its thing. When it's almost done you'll get a polite message: 

Execution: /usr/bin/shim-install

Error: /usr/lib/grub2/i386-efi/modinfo.sh doesn't exist.

Keep calm and carry on. The installer will still deploy a grub.cfg and the other essentials so when everything is done copy your bootloader onto the eMMC EFI partition and then make a boot entry in the BIOS. Let the good times roll from there.

Verdict: Tremendous!

openSUSE: Performance

Tumbleweed effectively uses half the memory Fedora 27, boots faster and feels snappier overall. No idea what GDM is doing but the overhead is rediculous for what is nothing but a session manager. The hand over time from GDM to the chosen session is also slower then SDDM.

Ubuntu: 17.10

Before we continue, an honorable mention for "Linuxium" which is an Ubuntu for Bay Trail and Cherry Trail based devices. While I had a mixed experience with it previously I don't feel it warrants its own section any more seeing as how well Ubuntu 17.10 runs out of the box.

Ubuntu 17.10 comes with Kernel 4.13.0.21 and can be booted with Jeff's bootloader or Fedora's bootloader provided you change the boot commands to "linuxefi" and "initrdefi" respectively.

Remember to be connected to the internet during the installation so Ubuntu can install a 32-bit Grub correctly on your behalf. That's all there is to it really.

The ISO when burned to a USB stick will create 2 partitions, the EFI partition is relatively small so we'll make some space by deleting the 64-bit bootloader and copying a 32-bit version on.

dd if=ubuntu-17.10-desktop-amd64.iso of=/dev/sdX status=progress

# Bootloader
mkdir /mnt/stick
mount /dev/sdX2 /mnt/stick

rm /mnt/stick/efi/boot/{bootx64.efi,grubx64.efi}

cp /some/src/bootia32.efi /mnt/stick/efi/boot/

# Optionally
mkdir /mnt/bunty
mount /dev/sdX1 /mnt/bunty

mkdir -p /mnt/stick/boot/grub/
cp /mnt/bunty/boot/grub/grub.cfg /mnt/stick/boot/grub/

sed -i '1i root=(hd0)' /mnt/stick/boot/grub/grub.cfg

# Unmount
umount {/mnt/stick,/mnt/bunty}

If you didn't do the optional steps, boot your stick, when in Grub hit "c" and punch commands: 

grub> root=(hd0)

grub> configfile (hd0)/boot/grub/grub.cfg

Your screen will be dark for a moment or two followed by a familar purple background, just be patient and the live session will boot.

The installer finishes up and provided you are connected to the internet it correctly deploys a 32-bit bootloader which boots properly at the first reboot.

Don't really have any other comments. The new Gnome based environment feels faster then Fedora 27.

Verdict: 64-bit Ubuntu is as Ubuntu does and it does it very well indeed.

Preparing Arch Linux

I'm a big fan of Arch Linux so some things may not apply to your particular flavour of distro. I hope that you may atleast gleam helpful clues from all this.

Before we begin there are a couple of basic requirements:

Preparing your install media

Make sure nothing of value is left on your USB stick then download the Arch Linux iso and clone to USB:

dd if=archlinux-2016.12.01-dual.iso of=/dev/sdX bs=4M && sync

Fire up GParted, select your USB storage device.

Right click > Manage Flags, then disable "esp".

This enables the boot partition on the stick to be modified as normally it's mounted read-only.

Eject your stick and re-plug, you can now modify the boot slice.

You'll need a 32-bit UEFI bootloader, there's a couple of options to get that sorted.

The UEFI spec expects the file to be called "bootia32.efi" if you want it to be auto detected. You can have a different name but that will require you to make a seperate boot entry and likely having to manually get Grub going with the internal command line. 

Copy "bootia32.efi" to "/{Arch ISO USB}/EFI/boot/"

I've concocted a BayTrail Grub.cfg that has a number of helpful options if you don't feel like manually punching commands as outlined below. This version will fit the "201612" release, in case I don't get a chance to update be sure to search and replace accordingly. Grub will automatically pick it up when copied to the right path. 

Rename "baytrail-grub.cfg" to "grub.cfg"
Copy "grub.cfg" to "/{Arch ISO USB}/boot/grub/"

Fire up GParted again and renable the "esp" flag for your USB storage device.

Done.

Booting your install media

Disable secure boot

Turn on or restart your device

Press the "Volume Down" button / F2 key to enter the BIOS.

In the "Boot" section, set "Secure Boot" to "Disabled".

Exit and Save Changes

Boot from USB

Turn on or restart your device

Press the "Volume Up" button / "Down Arrow" or "F12" key to enter the "Boot Mode" menu.

Your USB stick should show up as "UEFI: Brand Foo USB"

You can either use the "Volume Up" button to scroll your selection followed by "Volume Down" to acknowledge or use your attached keyboard.

If all is right you'll be greeted by GNU Grub.

Booting your installer, Manually

If you don't have a need for fancy boot menus and are not using the grub.cfg mentioned above this is the process for you.

On the grub command line we must first set a root device: 

root=(hd0)

If Grub complains, issue the "ls" command for a list of other sources.

Now we'll tell Grub what to boot, if root is set correctly you get tab complete powers. Keep in mind to match the "archisolabel" accordingly with the volume name of the ISO, here I'm using the December 2016 release.

Protips:
- You have tab-completion powers.
- Get each command perfectly right.

Console in Portrait Mode: 

linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_201612

Console in Landscape Mode: 

linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_201612 fbcon=rotate:1

Init Ramdisks and Boot: 

initrd /arch/boot/intel_ucode.img
initrd /arch/boot/x86_64/archiso.img
boot

If you end up with a black screen after the initial init try adding "i915.modeset=0" or "modprobe.blacklist=efifb" to your kernel flags.

Installing Arch Linux

The December 2016 install media comes with kernel 4.8.11 which technically works well on the Venue Pro 8 but the MicroSD slot won't function out of the box which makes it hard to have your RootFS or home folder there.

Use a MicroSD reader in the interrim and be ready to compile a Kernel to work around bug #150881. Afterwards, with the magic of UUID, swapping the card from reader to internal slot becomes hassle free.

Remember that if you are doing a re-install to clean up your old kernel / initramfs files on the internal EFI partition.

Should you be installing on the internal eMMC you are good to go, this bug doesn't affect you.

If you still run into issues corruption or other issues during installation it may be worth having a look in the Power Management Section for possible clues.

If the deities smiled upon you then your device should be presenting the base Arch environment from which you can commence your installation as per the Beginners Guide.

Take note installing the bootloader is the step that will deviate, as by default it is assumed a 64-bit environment will have a 64-bit bootloader which is a no-go given we are dealing with 32-bit UEFI on the Venue 8 Pro. The Venue 11 Pro has a 64-bit UEFI and is thus fine.

Optionally, if you intend to dual boot you'll have to partition accordingly.

fstab

UUID's and MicroSD cart booting can in some cases anger the kernel.

See what works out best for you. Opt for /dev/mmcblkXpY if your lazy or have issues with UUIDs. UUID is preferred though as MMC device numbering can change.

Kernel 4.4.2 is happy with UUID's
Kernel 4.5rc5 got angry and has to resort to /dev/mmcblk.
Kernel 4.7+ is happy with UUID's again

Use "blkid" or "ls -l /dev/disk/by-uuid" to find your relevant UUID.

#Anonymized Example Data, Don't copy me bro.

[root@DellV8 ~]# blkid
/dev/mmcblk2: UUID="ea35b5b9-f40d-452d-a3c3-202ac21760b8" UUID_SUB="88259bb5-9001-4eb0-afff-db510e23ceea" TYPE="btrfs"
/dev/mmcblk0p1: LABEL="WINRETOOLS" UUID="CE72DF8C72DF5985" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="ec343780-5fe4-4efd-9f3e-3f9186a12705"
/dev/mmcblk0p2: LABEL="ESP" UUID="28DF-DE5B" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1e2e38fa-ebbd-4f6c-8b5d-b3dd36f5d850"
/dev/mmcblk0p5: LABEL="PBR Image" UUID="12E8577CE8572987" TYPE="ntfs" PARTLABEL="Microsoft recovery pfrtition" PARTUUID="f6e919b1a-15df-4b51-a6d7-f53f843f4479"
/dev/mmcblk0: PTUUID="22bcb65f-6194-47a6-b715-50b3c67ffdaa" PTTYPE="gpt"
/dev/mmcblk0p3: PARTLABEL="Microsoft reserved pfatition" PARTUUID="ec343780-5fe4-4efd-9f3e-3f9186a12705"
/dev/mmcblk0p4: PARTLABEL="Basic data partition" PARTUUID="2f1cd7fc-d51f-85ce-9151-ba195588e852"

#Alternatively.

[root@DellV8 ~]# ls -l /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 15 Oct  5 00:04 12E8577CE8572987 -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 15 Oct  5 00:04 28DF-DE5B -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 13 Oct  5 00:04 ea35b5b9-f40d-452d-a3c3-202ac21760b8 -> ../../mmcblk2
lrwxrwxrwx 1 root root 15 Oct  5 00:04 CE72DF8C72DF5985 -> ../../mmcblk0p1

Dual Booting

For the boot department we'll use the EFI partition from the internal eMMC so there's no need to partition for one on the MicroSD card.

It bears repeating, if you've previously tried to install Linux in any form or have tried other experiments it's a good idea to clean up any old kernels (vmlinuz) or initram disks (initramfs / initrd) files.

A quick "lsblk" provides the clues we need.

[root@DellV8 ~]$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0boot0 179:16   0    4M  1 disk
mmcblk0boot1 179:24   0    4M  1 disk
mmcblk0rpmb  179:32   0    4M  0 disk
mmcblk0      179:8    0 29.1G  0 disk
├─mmcblk0p1  179:9    0    1G  0 part
├─mmcblk0p4  179:12   0 22.3G  0 part
├─mmcblk0p2  179:10   0  500M  0 part
├─mmcblk0p5  179:13   0  5.2G  0 part
└─mmcblk0p3  179:11   0  128M  0 part
mmcblk2      179:0    0 29.8G  0 disk

Assuming the stock Dell configuration the second partition on the internal eMMC will be 500MB for EFI booting purposes. 

mount /dev/mmcblk0p2 /mnt/boot

If you mounted the correct partition the following path should show you the Windows boot manager. 

ls /mnt/boot/EFI/Microsoft/Boot

Swap

Why give up valuable space, use zramswap instead.

However, you'll need storage backed swap space if you'd like hibernation to function.

Reminder, BTRFS and swap files means you're gonna have a bad time.

Ext4-fs

You can partition your MicroSD card with a single partition for Linux use as per the guide if you intend to dual boot. Otherwise use your internal MMC as you see fit.

BTRFS

Assuming you are installing to a MicroSD card you can just feed the entire device to BTRFS and forgo partitions. Otherwise, again, do as you would.
Combined with SSD mode + compression it works wonderfully. 

# Make btrfs filesystem
mkfs.btrfs /dev/mmcblkX

# Default zlib, for better compression.
mount -o compress /dev/mmcblkX /mnt

# Or use lzo, for speed.
mount -o compress=lzo /dev/mmcblkX /mnt

Do make sure you install btrfs progs before you mkinitcpio, else you'll get complaints that btrfs.fsck is missing. 

pacman -S btrfs-progs

Wireless

If you'd like to use "wifi-menu" you'll need a some extras. 

pacman -S dialog wpa_supplicant

Deploying the bootloader

There may be some angry diagnostic output, don't worry but do pay attention. 

pacman -S grub efibootmgr os-prober

grub-install --target=i386-efi --efi-directory=/boot --bootloader-id=ArchLinux --recheck

grub-mkconfig -o /boot/grub/grub.cfg

Power Management 3.0

It's been a long wait and an interesting journey but with Kernel 4.12 in hand we're actually in a very good place.

See the Kernel's System Power Management Sleep States documentation for additional background information.

Battery

pacman -S acpi

acpi -V

As long as your battery is reporting for duty then capacity and charge status are correctly reported.

"Disappearance" Fix

TL;DR: Missing Battery? Suspend your device and patiently wait for your battery to drain.

Some time ago my Venue 8's battery decided to disappear, updating the BIOS brought it back and then a month later it disappeared again. Trying a forced reflash of the BIOS did not result in any change.

Now to clarify the battery itself still remains functional but the charging light gives no feedback (no white or orange colour) and software is unable to report any details such as charging status or charge level. Running the onboard diagnostics will show you there's something there but all the values are incorrect.

One characteristic of this "confused" power state is that the Venue 8 will turn on immediatly when pressing the power button where as under normal circumstances powering on requires a good 2 second press of the button. My theory is that in this instance it's almost like the power manager has a variable stuck where the tablet thinks it's always left in a stand-by state and it is never cleared. Because of this stand-by state it assumes it has a battery but never checks it exists and thus nothing is reported.

While I was testing suspend I forgot to keep track of time and thus drained the battery flat. Initially the Venue 8 refused to power on or show any signs of life but after leaving the charger connected for a couple of minutes the charging status light came on white which was a very promising sign.

I left the unit to charge for half an hour after which it turned on fine again. Booting into the system confirmed that things had turned back to normal and with an over night charge the system reported a full battery and a 9 hour possible run time.

Charging

A good 2A USB power supply is recommended. The charger block from the Venue 11 is also compatible.

You'll get the fastest charge rate when connected directly about ~1.49A, if you're charging via an OTG cable try to limit your connected USB devices. Your charge rate can easily drop to less then 0.5A when you have a USB hub + bits connected which effectively means your battery won't charge much at all whilst using your device.

Stability

Each new Kernel has progressively improved the stability of the Venue 8. Initially I was lucky to get an hour of uptime and at the very worst constant freezes, fast forward to the present and using the device for an entire day with few surprises is now achievable.

I've not had any issues with filesystem corruption since Kernel 4.7 and the slight performance drop that showed up around Kernel 4.9 seems to have been mitigated.

On AC power I've managed to get to 2 days and 7 hours straight, on battery as much as 10 hours and 33 minutes (2 Cores, audio streaming and light browsing) with randomly connecting the charger to see if it would upset things.

There seems to be some correlation with having removed and reinstated the ath6kl kernel modules. A number of days prior I had a full lock up some hours after an rmmod cycle after about a days worth of uptime.

The USB OTG port is still a weird creature. Using a powered OTG cable you can safely plug and unplug from both the Venue port or the OTG cable end. Unpowered it does not appreciate any plug and unplug activities on the Venue side, causing the system log to overflow with ACPI errors, but you can safely do things on the OTG cable end.

Suspend (4.12+)

echo "freeze" > /sys/power/state

systemctl start systemd-sleep.service

With Kernel 4.12 suspend now operates correctly. The device will resume when either the "meta" button near the headphone jack or the power button is pressed. The volume buttons will not wake the device. Likewise any USB attached keyboard or mice will not wake it either.

Only niggles I've found sofar is that sound doesn't always re-initialize right if you had an audio source playing. Stopping any playback before suspend negates this issue. Plugging in a USB device may or may not anger it depending on your OTG cable situation.
Surprisingly Wifi is very well behaved and has sofar been reconnecting on resume.

I've done a test run of 3 days with 22 suspend / resume cycles without issue. During this I've kept an eye on the battery discharge rate and it averages out to about 2% per hour of stand by.

Hibernate

echo "disk" > /sys/power/state

systemctl start systemd-hibernate.service

Kernel 4.12 delivers. Looks good overall. Wifi and Audio continue working correctly.

Suspend + Hibernate

systemctl start systemd-hybrid-sleep.service

Hibernate vs Suspend + Hibernate doesn't seem to have much performance difference at first glance but it works as per the above.

TuxOnIce

TuxOnIce is an alternative sub-system for hibernation that offers a more compelling feature set then the stock mainline sub-system does. (The author's webpage seems to be under construction at the moment so a wayback machine link is provided, alternatively see Wikipedia).

Tried to compile the latest git release but no luck today.

ToDo: Experiment more another day.

SDHCI ACPI

Previously one had to toggle certain power states, doesn't seem to matter on Kernel 4.12+

Power Adapter Check

I use this when testing so it disables things immediately upon boot when running from battery power.

I can confirm acpid sees "ac_adapter" and "battery" events which paves the way for automation. But this will suffice for now. 

#!/bin/bash
if [ -f /sys/class/power_supply/ADP1/online ]
then
  ADP=`cat /sys/class/power_supply/ADP1/online`
fi

if [ "$ADP" -ne "1" ]
then
  #Disable cores, turn off turbo, etc.
fi

i915 / DRM

The Intel GPU kernel driver has a number of options that can be tried.
enable_rc6=1, does not seem to offer improvement.
enable_fbc=1, does not seem to offer improvement.

drm.vblankoffdelay=1, seems to save 0.05 - 0.09 watts when added to the kernel command line.

System Devices

Power Management can be enabled on i2c devices to save a little more. While PowerTop has an auto pilot I'm not sure if I want to trust it at present so we pass some selective flags. Saving up to another 0.4 watts.

#!/bin/bash
#Observed from PowerTop.
#Kernel
echo '0' > '/proc/sys/kernel/nmi_watchdog'
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs'

#Intel Atom Power Control Unit
echo 'auto' > '/sys/bus/pci/devices/0000:00:1f.0/power/control'

#Intel Atom SoC Transaction Register
echo 'auto' > '/sys/bus/pci/devices/0000:00:00.0/power/control'

#Intel Atom Trusted Execution Engine
echo 'auto' > '/sys/bus/pci/devices/0000:00:1a.0/power/control'

#Intel Atom USB xHCI
echo 'auto' > '/sys/bus/pci/devices/0000:00:14.0/power/control'

#Suspecting main intel i2c.
#Seems to trigger PM for all i2c devices and Atom GPU + Display.
#The i2c reference can change, adjust accordingly.
echo 'auto' > '/sys/bus/i2c/devices/i2c-9/device/power/control'

Power Monitoring

You can install "powertop", but powertop can be slow in refreshing the overall battery discharge rate. However, we can ask the kernel these things combined with a little math. Keep in mind you'll need to disconnect your power adapter to get a correct output.

#/bin/bash
#Usage: watch -n 1 ./watts.sh

V=`cat /sys/class/power_supply/BATC/voltage_now`
A=`cat /sys/class/power_supply/BATC/current_now`

((P1 = $A * $V))
P2=`echo "$P1 / 1000000000000" | bc -l`

printf "Current discharge rate of "
printf %.2f $(echo $P2)
printf " Watts.\n"

Disable CPU Cores

I tend to live in shells most of the time so I don't need quad core power. Additionally, this saves about 0.2 watts in energy.

There was once a "sched_mc_power_savings" option but this seems missing after kernel 3.4 which was responsible for minimizing the number of cores used so idle cores could sleep in full. Meanwhile I'm curious as to why the P-State driver is not turning cores off.

In lieu of this, we force cores offline which achieves a "similar effect". 

#!/bin/bash
#Disable unneeded cores.
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
echo 0 > /sys/devices/system/cpu/cpu3/online

#!/bin/bash
#Enable all cores.
echo 1 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu2/online
echo 1 > /sys/devices/system/cpu/cpu3/online

C-State Tweaking

There is still bug #109051 but the Venue 8 seems very well behaved now.

P-State Tweaking

Set a maximum CPU frequency.
FYI, can cause i2c to complain in rare circumstances.

#Set maximum frequency to 500Mhz
cpupower frequency-set -u 500MHz

#Set maximum frequency to 1.84Ghz
cpupower frequency-set -u 1.84GHz

Disable turbo state which can save up to another 0.8 watts of energy.
The CPU is also likely to generate less heat.

#!/bin/bash
#Disable Turbo (no_turbo is true)
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

#!/bin/bash
#Enable Turbo (no_turbo is false)
echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

CPU Governor

Bay Trail CPU's are classified as being friends with the Sandy Bridge architecture and Intel recommends the "ondemand" governor for best results.

However, to minimize heat you can consider using "powersave" instead. Either you can set it on the command line or you can set it as a default when compiling the kernel.

cpupower frequency-set -g powersave

Disable WiFi

WiFi eats up to 0.25 watts of energy. Without a bluetooth keyboard in use this is a practical measure at the moment. 

#!/bin/bash
#Load WiFi kernel modules
modprobe ath6kl_core
modprobe ath6kl_sdio

#!/bin/bash
#Remove WiFi kernel modules
rmmod ath6kl_sdio
rmmod ath6kl_core

Wattage

Based on Kernel 4.4 we started out originally around the 2.3 Watts mark, with tweaks applied we get the following.

Wifi off, XFCE: 1.15 Watts.
Wifi off, TTY: 1.12 Watts.

Power Sipping

Fun fact, a USB Mouse / KB dongle eats between 0.20 - 0.24 watts you can try and see if USB autosuspend works for you.

Your choice of wallpaper and UI theme can impact power use. Likewise your choice of application can impact power use. Visible applications that have interface elements that constantly refresh, for example the visualizer in Audacious can eat 0.2 watts. Simply hiding it becomes instant savings.

ToDo: New table with facts.

Wayland

Fedora 27, Gnome on Wayland

As per title, this is the shipping default. Screen rotation works as does touch input. So far so good.

If you are using MPV for media playback it will by default run in XWayland which doesn't play well with VA-API for hardware accelerated decoding.

The following switches offer a solution to this. 

# MPV says:
# "va_getDriverName() failed with unknown libva error, driver_name=(null)"

# MPV native Wayland. (Decoder > GPU mem)
mpv --opengl-backend="wayland" --hwdec="vaapi" /foo/bar.mkv

# MPV through XWayland. (Decoder > System mem > GPU mem)
mpv --hwdec="vaapi-copy" /foo/bar.mkv
Weston

Do not my friends expect alot of excitement here, it is still early days but we have a little progress since last time.

"libinput" shows touch capabilities for the digitizer and the "weston-simple-touch" demo confirms multi-touch magic when running under Weston. The same demo under Sway seems broken at this time. Mouse input is obviously fine in both lands.

For now a traditional X11 environment is more fruitful. 

# Weston in landscape
# ~/.config/weston.ini
[output]
name=DSI-1
transform=90

X.org

Intel Hardware

I've had little difficulty with the framebuffer overall since the start of this journey and you have two options to explore. You can use KMS or the Intel Graphics driver.

Xorg Essentials
pacman -S xorg-server xorg-xinit xorg-xinput xorg-xrandr
Input Devices
#Option 1, libinput is the future:
pacman -S xf86-input-libinput

#Option 2, tried and tested:
pacman -S xf86-input-evdev
VA-API / Hardware Video Decoding
pacman -S libva-intel-driver mesa vdpauinfo

We can save battery by using the onboard H264 video decoder by deploying VA-API support. Combined with a supported player it means 5% cputime on a single core vs eating up 4 cores at XY% cputime.

ModeSetting

Using the KMS driver works fine, comes with Glamor and uses DRI2 by default. 

#/etc/X11/xorg.conf.d/20-intel.conf

Section "Device"
	Identifier "Intel Graphics"
	Driver "modesetting"
EndSection
Intel DDX
pacman -S xf86-video-intel

If you want to enable Glamor, DRI3 and TearFree rendering, use the following config. Be advised the overall stability of all options combined is up in the air at present. Remember, only one "AccelMethod" at a time.

SNA (default) with TearFree enabled looks and feels great with no tearing.
Glamor uses slightly less power at approximately 0.01 Watt vs SNA.

Feel free to experiment with the config below.

Note: "TearFree" only works with SNA. Should not be needed with DRI 3 enabled. 

#/etc/X11/xorg.conf.d/20-intel.conf

Section "Module"
	Load "glamoregl"
EndSection

Section "Device"
	Identifier "Intel Graphics"
	Driver "Intel"
	Option "AccelMethod" "glamor"
#	Option "AccelMethod" "uxa"
#	Option "AccelMethod" "sna"
	Option "DRI" "3"
#	Option "TearFree" "true"
EndSection

Xrandr

The "RandR" (Resize and Rotate) protocol is what allows for rotating the desktop as well as changing resolutions. It is also helpful in setting your scaling factor to keep everything reading by way of changing the DPI level. At this point in time it's normal if the screen stays black for a brief period as Xorg does its thing.

This tends to occur if you rotate in any direction that is not 180 degrees (mirrored) to your current setting.

This behaviour happens both with the Modesetting and Intel Xorg Driver.

Instant Change
Delayed Change
Commands
xrandr --screen 0 -o left
xrandr --screen 0 -o right
xrandr --screen 0 -o inverted
xrandr --screen 0 -o normal

ToDo: Add DPI explaination. Default is pretty reasonable though.

Window Manager: XFCE

Let's install XFCE and not care for LightDM / MDM etc. 

pacman -S xfce4 xorg-xinit

echo "exec xfce4-session" > ~/.xinitrc

startx

Window Manager: Enlightenment

Let's install Enlightenment. If you're happy to use your fingers, pen or keyboard to work the UI, it's decent. 

pacman -S enlightenment terminology xorg-xinit

echo "exec enlightenment_start" > ~/.xinitrc

startx

Window Manager: Openbox

Let's install Openbox, if you feel adventurous.
Protip: learn about your .xprofile

pacman -S openbox openbox-themes obconf tint2

echo "exec openbox-session" > ~/.xinitrc

startx

Pen Input

OpenTTD is hard to play without a "right mouse" button. By default Button 1 (bottom click) is mapped to "left" and Button 2 (upper click) to "middle".

Button 1 is shared with the pen tip so we seem to loose "left click" on the tip if we change it, Button 2 can be freely changed to right click.

Be advised, some may consider Pen Input somewhat sensitive. 

xinput set-button-map "SYNA7500:00 06CB:00F2 Pen" 1 3 2 4 5

Rotation (Venue 8 Pro)

A modified rotation script based on the T100 version by John allows us to set the touch input, pen input and screen rotation appropriately but we are dependent on parsing the output of xinput and xrandr. 

#!/bin/bash

TOUCHSCREEN=`xinput | grep SYNA7500 | grep -v Pen | cut  -f2 | cut -d= -f2`
PEN=`xinput | grep SYNA7500 | grep Pen | cut  -f2 | cut -d= -f2`

CURR_ROT=`xrandr -q --verbose | grep DSI | cut -d" " -f 5`

if [ "$CURR_ROT" == "normal" ]; then
        ROT_TO="right"
        SWAP_TO="1"
        INV_TO="0, 1"
elif [ "$CURR_ROT" == "right" ]; then
        ROT_TO="inverted"
        SWAP_TO="0"
        INV_TO="1, 1"
elif [ "$CURR_ROT" == "inverted" ]; then
        ROT_TO="left"
        SWAP_TO="1"
        INV_TO="1, 0"
else 
        ROT_TO="normal"
        SWAP_TO="0"
        INV_TO="0, 0"
fi

xrandr --screen 0 -o $ROT_TO

xinput set-int-prop $TOUCHSCREEN "Evdev Axis Inversion" 8 $INV_TO
xinput set-int-prop $TOUCHSCREEN "Evdev Axes Swap" 8 $SWAP_TO 

xinput set-int-prop $PEN "Evdev Axis Inversion" 8 $INV_TO
xinput set-int-prop $PEN "Evdev Axes Swap" 8 $SWAP_TO

Add a desktop icon for seasoning. 

#/home/user/Desktop/

[Desktop Entry]
Name=Rotate
Comment=Rotate the screen
Keywords=rotate;screen;
Exec=/path/to/rotate-script.sh
Terminal=false
Type=Application
Icon=rotation-allowed-symbolic
StartupNotify=true 
Categories=System;

For me personally, my desktop is already set in landscape and I just want the input rotated 90 degrees. 

#!/bin/bash

TOUCHSCREEN=`xinput | grep SYNA7500 | grep -v Pen | cut  -f2 | cut -d= -f2`
PEN=`xinput | grep SYNA7500 | grep Pen | cut  -f2 | cut -d= -f2`

CURR_ROT=`xrandr -q --verbose | grep DSI | cut -d" " -f 5`

#XFCE, Openbox
if [ "$CURR_ROT" == "right" ]; then
	SWAP_TO="1"
	INV_TO="0, 1"
fi

#Enlightenment
if [ "$CURR_ROT" == "(0x47)" ]; then
        SWAP_TO="1"
        INV_TO="0, 1"
fi

xinput set-int-prop $TOUCHSCREEN "Evdev Axis Inversion" 8 $INV_TO
xinput set-int-prop $TOUCHSCREEN "Evdev Axes Swap" 8 $SWAP_TO 

xinput set-int-prop $PEN "Evdev Axis Inversion" 8 $INV_TO
xinput set-int-prop $PEN "Evdev Axes Swap" 8 $SWAP_TO

Firmware

Atheros 6K / Dell 1538 wireless

For wifi to work we need a newer release of the ath6kl firmware then is currently shipped in the Linux firmware package.

Qualcomm has these in their ath6kl firmware repo.
The AR6004 folder sits in /lib/firmware/ath6k/ on your filesystem.

Bay Trail SST Audio

Bay Trail SST Audio firmware is included by default.
The Intel folder sits in /lib/firmware/intel/ on your filesystem.

For reference, the intel firmware repo may have updated versions available if you run into difficulties.

ALSA

Kernel 4.4 - Seriously, this I do not even and that's with truncated item names.
- Full Size, 9256 x 340, 408KB -

Bay Trail audio is a very odd beast. Weird mixers, everywhere...

ToDo: Scope ALSA Compress API and TinyCompress

Getting Started 

pacman -S alsa-utils pulseaudio

Straight ALSA works but the overall experience is better with PulseAudio as it will make it easier to switch between headphones and speaker output as well as having input controls to toggle between device microphone or your headset microphone.

You may want to blacklist "snd_hdmi_lpe_audio" to keep things happy. - Thanks J-M!

Can confirm automatic sensing of a headphone jack being present works on recent Kernels. (5.6+)

Use Case Manager

This may still be the case on older distros, this is a legacy item at this point

For ALSA to properly configure the hardware we need a set of "Use Case Manager" files which help ALSA understand how the hardware works and what the correct default initialisation state should be.

I've had success using the "bytcr-rt5640" UCM data from Pierre's GitHub. 

cp -rf bytcr-rt5640 /usr/share/alsa/ucm

Copy these in place as directed and just to be safe remove your current ALSA state file if present.

rm /var/lib/alsa/asound.state

Proceed to reboot to activate the UCM data and regenerate the state file. You should now have sound.

PulseAudio 

pacman -S pulseaudio pavucontrol

Works, if you are so inclined. Out of the box resampling will cause CPU time overhead but fortunately we have ways of controlling this. 

pulseaudio --dump-resample-methods

This command will show you all supported resampling methods from "cheapest" to most "expensive" CPU wise. Pick and then apply your choice pending on personal preference. "trivial" is the cheapest in my case and "soxr-vhq" the dearest. Make sure to uncomment the option.

#/etc/pulse/daemon.conf

resample-method = trivial
; enable-remixing = yes

After this change make sure to either kill the daemon or restart.

Side Note, to see the configured output sample rate: 

This:
pacmd list-sinks | grep sample

Returns:
sample spec: s16le 2ch 48000hz

Speakers / Headphone Toggling

Something changed in 4.12.x that causes audio to fall completely silent when you try to change outputs. In some cases I've had the kernel refuse to detect audio exists afterwards and had to manually modprobe.

You can bypass Pulseaudio's management with ease. 

#In alsamixer

#Mute
"Speaker Channel"

#Unmute
"Headphone" (at start), "HP Channel", "HP L", "HP R"

#Volume control
"HP" (slider)

Then reverse inverse steps to go back to speaker, or you can have both on if you so please.

48Khz or Bust

Keep in mind that most sources will output 44.1 Khz and in order for audio to come out at 48Khz you're dealing with resampling which can in some instances eat a fair chunk of CPU time.

If you're using Pulseaudio it will take care of this on your behalf and this can be tweaked. If you are using pure ALSA then Audacious and MPD offer a number of ways you can configure resampling it's worth taking a moment to scope it as it can impact battery life.

I tried to find a 44.1Khz firmware, looking at the original ASOC patch there may have been one but only the 48Khz one exists in the official repo.

48Khz technically makes more sense though, 44.1Khz is a compact disc mastering hold over.

Hardware Buttons

As per the kernel compiling notes, the physical buttons on the side and top of the Venue 8 are dependent on 2 kernel modules to function correctly: soc_button_array and gpio_keys.

For the Venue 11 only soc_button_array is needed.

By default the mappings are thus:

Power Button

While under Xorg the power button behaviour will depend on how your desktop environment is configured. On the console we can disable the default behaviour by changing the following: 

#/etc/systemd/logind.conf

HandlePowerKey=ignore

Volume Keys

With Xbindkeys we can map the volume buttons to do our bidding. You can find the PulseAudio variant on the Arch Wiki the following is for straight ALSA on Kernel 4.4.2. 

#Increase Volume
"amixer sset DAC1 5%+"
    m:0x0 + c:123
    XF86AudioRaiseVolume

#Lower Volume
"amixer sset DAC1 5%-"
    m:0x0 + c:122
    XF86AudioLowerVolume

GPIO reference

$ cat /sys/kernel/debug/gpio

GPIOs 338-381, platform/INT33FC:02, INT33FC:02:

gpio-16  (power               ) in     hi pad-8   offset:0x080 mux:1  fall rise

GPIOs 410-511, platform/INT33FC:00, INT33FC:00:

gpio-4   (volume_down         ) in     hi pad-99  offset:0x630 mux:0  fall rise       up   20k
gpio-5   (volume_up           ) in     hi pad-102 offset:0x660 mux:0  fall rise       up   20k
gpio-6   (home                ) in     hi pad-98  offset:0x620 mux:0  fall rise       up   20k

# works out to
gpio354, gpio414, gpio415, gpio416

Fun with Industrial I/O

Sensors sit on the i2c bus and with Kernel 4.12+ it appears they initialize all the time now where as with pevious Kernels it would be luck of the draw.

If you struggle to see any IIO devices do a warm reboot on 4.4.0+ or a cold reboot / power down on 4.7.0+.

All the sensors get a new device / trigger number every time the kernel is started so don't make assumptions.

Hello Sensors

Raw IIO demo time.

Meanwhile I fabricated a little script that talks to all the raw outputs and puts them into neat columns as shown in the screenshot.

#!/bin/bash
# This scripts reads the various HID IIO Sensors.
# Ex. usage: watch -n 0.2 './poll_iio.sh'

# Device numbering changes every time things are initialized.
# Little crude use of grep and cut. awk or sed could be nicer.
iio_als=`cat /sys/bus/iio/devices/trigger*/name | grep als | cut -d '-' -f 2 | cut -c 4`
iio_rot=`cat /sys/bus/iio/devices/trigger*/name | grep rotation | cut -d '-' -f 2 | cut -c 4`
iio_gyro=`cat /sys/bus/iio/devices/trigger*/name | grep gyro | cut -d '-' -f 2 | cut -c 4`
iio_magn=`cat /sys/bus/iio/devices/trigger*/name | grep magn | cut -d '-' -f 2 | cut -c 4`
iio_accl=`cat /sys/bus/iio/devices/trigger*/name | grep accel | cut -d '-' -f 2 | cut -c 4`
iio_incl=`cat /sys/bus/iio/devices/trigger*/name | grep incli | cut -d '-' -f 2 | cut -c 4`

# Ambient Light Sensor
als=`cat /sys/bus/iio/devices/iio\:device$iio_als/in_intensity_both_raw`

# Rotation, doesn't seem to do much on Venue 8.
rot=`cat /sys/bus/iio/devices/iio\:device$iio_rot/in_rot_quaternion_raw`

# Gyro
gyro_x=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_x_raw`
gyro_y=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_y_raw`
gyro_z=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_z_raw`

# Magnetometer
magn_x=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_x_raw`
magn_y=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_y_raw`
magn_z=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_z_raw`
magn_n=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_rot_from_north_magnetic_tilt_comp_raw`

# Accelerometer
accl_x=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_x_raw`
accl_y=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_y_raw`
accl_z=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_z_raw`

# Inclinometer
incl_x=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_x_raw`
incl_y=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_y_raw`
incl_z=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_z_raw`

# Awkwardly formatted printf to prepare output for column.
printf "
 Gyro, Accel., Magneto, Inclino, ALS, Rotation\n
-----------,----------,-------------,----------,---------,------------\n
 X: $gyro_x, X: $accl_x, X: $magn_x, X: $incl_x, L: $als, R: $rot\n
 Y: $gyro_y, Y: $accl_y, Y: $magn_y, Y: $incl_y, , \n
 Z: $gyro_z, Z: $accl_z, Z: $magn_z, Z: $incl_z, , \n
, , N: $magn_n, , " | column -t -s ','

# -- END --

Manual Exploration

# Find our sensors and device numbers.
cat /sys/bus/iio/devices/trigger*/name

# Results
als-dev0
magn_3d-dev1
dev_rotation-dev2
gyro_3d-dev3
accel_3d-dev4
incli_3d-dev5

# Find specific sensor
grep -rn "als" /sys/bus/iio/devices/iio*/name

# Result
/sys/bus/iio/devices/iio:device0/name:1:als

Read out the ambient light sensor

# Shine a light on the device. Bright light value of 1500+.

watch -n 0.2 'cat /sys/bus/iio/devices/iio\:device0/in_intensity_both_raw'

Read out magneto meter

watch -n 0.2 'cat /sys/bus/iio/devices/iio\:device1/in_rot_from_north_magnetic_tilt_comp_raw'

iwup.py - Is Wireless UP

About

You can find the full backstory and annotated source within the Python file itself. In short this tool will reload the ath6kl_sdio kernel module that powers the Venue 8 internal WiFi when WPA supplicant detects a connection drop. I've been using this myself since July '17 and been since polishing it to a point where I felt comfortable releasing it into the wild.

It may not be a perfect solution but atleast the connection drop stays short enough for my shells to stay connected.

The Python D-Bus module is realistically the only dependency you will need to install prior to use. It is assumed you are already joined to a network at the moment. Don't forget to chmod +x when you're ready.

Download

iwup.py - v1.2

Runtime Output 

    WPA D-Bus Bot v1.2
[%] No interface specified, assuming wlan0.
[%] No module specified, assuming ath6kl_sdio.
[#] Subscribed to 'PropertiesChanged' on NetworkManager.
[#] Updating D-Bus Paths.
[-] 16:12:36
[#] Path : /fi/w1/wpa_supplicant1/Interfaces/15
[#] Net  : /fi/w1/wpa_supplicant1/Interfaces/15/Networks/0
[#] SSID : "SuperSmashTV"
[#] Subscribed to 'PropertiesChanged' on WPA Supplicant.
[-] 16:32:52
[!] - Disconnect Detected -
[!] DeAuth, Reloading kmods.
[-] 16:32:52
[#] modprobe: Phase 1, Removed module 'ath6kl_sdio'.
[#] modprobe: Phase 1, Adding module 'ath6kl_sdio'.
[#] modprobe: Phase 2, Confirming...
[@] modprobe: Procedure complete.
[-] 16:32:52
[!] - Interface Disabled...
[-] 16:32:58
[#] NM Connectivity State: 4
[#] Updating D-Bus Paths.
[-] 16:32:58
[#] Path : /fi/w1/wpa_supplicant1/Interfaces/17
[#] Net  : /fi/w1/wpa_supplicant1/Interfaces/17/Networks/0
[#] SSID : "SuperSmashTV"
[#] Subscribed to 'PropertiesChanged' on WPA Supplicant.

Wireless .alt.venue8

USB Dongles

Cheap and effective until the internal WiFi behaves as you'd expect. I've used the following dongles extensively without issues. 

- RaspberryPi Wifi Dongle, Broadcom BCM43143
- Unbranded Pigtail, Ralink RT5390
- Nintendo Wi-Fi USB, Buffalo RT2570

Android Tethering

Ref: Arch Wiki: Android Tethering

A non-nerfed Android phone should be able to bridge WiFi to USB. I had success with an HTC One running Cyanogen 12.

See: Settings > Wireless & Networks > More > Tethering & portable hotspot > USB tethering.

When toggled the HTC phone changes it's USB identifier and the RNDIS kernel module kicks in.

The only downside to this method is that the phone will be charging from the tablet battery which is less then ideal. I tried a data-only USB cable but nothing is triggered unless there's power present.

If you have full root on your Android device you may have a chance at disabling the charger input by either using a terminal app or ADB. The following is specific to the HTC one and may not apply to other models but maybe it helps you in the right direction.

Keep in mind that depending on your UX that even with charging turned off your battery icon may still indicate it is charging. The best indentifier in my case is the status light as that will turn on and off depending on what the charger control is actually set at. 

# Note: This was done via ADB which is part of the "android-tools" package.

# sysfs Charge Controls
root@evita:/sys/class/power_supply/battery # ls -l char*
--w--w---- root     root         4096 2016-08-15 23:33 charger_control
--w--w---- root     root         4096 2016-08-15 22:24 charger_timer
-r--r--r-- root     root         4096 2016-08-15 22:24 charging_enabled
-r--r--r-- root     root         4096 2016-08-15 22:24 charging_source

# Disable charging, status light turns off.
root@evita:/sys/class/power_supply/battery # echo 0 > charger_control
root@evita:/sys/class/power_supply/battery # cat charging_enabled
0

# Enable charging, status light turns on.
root@evita:/sys/class/power_supply/battery # echo 1 > charger_control
root@evita:/sys/class/power_supply/battery # cat charging_enabled
7

iPhone Tethering

Ref: Arch Wiki: iPhone Tethering

An iPhone will only do mobile data tethering as WiFi is automatically used as a hotspot thus negating the possibility of making a WiFi-bridge.

An iPhone modded with a form of jailbreak may be able to control charging but I don't have a spare iDevice to test this.

Wireless "ath6kl"

Work in Progress: 4.14, still bag of hurt.

Getting WiFi to work

WiFi is based on the Qualcomm Atheros AR6004 series. While the driver has been in the kernel for quite some time the device ID for the Dell Wireless 1538 has arrived in Kernel 4.9 negating the need for manual patching. The Venue 11 Dell Wireless 1537 is still up in the air at this point in time.

Read the Firmware Section for blobs.
Read the Kernel Compiling Section to get things to work.

Optionally add iwup.py into the mix.

Getting WiFi to connect

Before you do anything with your wifi at all: 

echo "on" > /sys/bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control

Without power management disabled the card will either not work, not join an AP, connect but have 1000ms+ latencies, crash it's firmware or show other weird behaviour.

You can also try to disable wireless power management but I didn't see any change. 

iwconfig wlan0 power off

TL;DR; Have constant traffic of some form going to "keep it going".
Having a flood ping on a seperate TTY generating 8 - 20KB/sec of traffic is a terrible but functional hack.

ping -f 192.168.x.x

A flood ping combined with Kernel 4.11.1 has given 1 Day, 9 hours, 31 minutes of wifi connectivity before dropping. Interestingly in this instance I did not have to remove the ath6kl module I could just rejoin the AP and continue on my way.

On kernel 4.8.0, courtesy of audio fixes, I noticed an interesting observation that connecting to an access point from cold-boot and streaming radio non-stop (~64kbit stream) I've been able to stay connected for as long as 5 hours and 47 minutes.

Wireless then mysteriously dies, on occasion I have to rmmod / modprobe twice in a row and then it stays up again from anywhere to 50 minutes to 2 hours while streaming. On one rare instance Wireless refused to come to the party at all and a reboot was required. Having a charger connected or not doesn't seem to make a difference.

(New record on the 7th of October: From cold boot, 8 hours and 13 minutes with 22% battery left.)

I suspect just enough traffic prevents any deep sleep modes as with non-stop ICMP traffic to a random host on the LAN wireless still dies after the ~35 minute mark. Earlier kernels may exhibit similar behaviour. We have learned new clues.

Meanwhile under low traffic use cases, you may now enjoy 35 (4.7.0 and newer) - 45 (4.4.0) minutes of connectivity before you have to rmmod and modprobe the ath6kl module again. Failing to follow the rmmod procedure has a chance to cause a kernel to panic if you attempt to rejoin your access point.

#!/bin/bash
rmmod ath6kl_sdio
rmmod ath6kl_core

#!/bin/bash
modprobe ath6kl_core
modprobe ath6kl_sdio

How WiFi fails

Without debugging enabled you'll find multiple "failure" notices when the interface goes down. A debug mode example can be found further down. It doesn't really matter if you're idling, doing small ICMP packets or pushing full bandwidth transfers. 

[7910.515323] ath6kl: wlan disabled
[7910.515557] ath6kl: wlan disabled
[7910.516008] ath6kl: wlan disabled

Thought: I'm entertaining a theory that maybe WPA key changes is what confuses it.
Testing Complete: Open (non-encypted) mode or WPA mode make no difference.

MMC debug mode

It may help to make the kernel diagnostic buffer larger. Passing "log_buf_len=32M" will allow for such things given the potential for verbosity.

MMC debugging was enabled for this portion and at the end we rmmod the relevant modules. It appears the interrupt is disabled for unknown reasons.

FYI, "mmc0: Too large timeout requested!" is harmless. 

[ 2683.960730] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
[ 2683.960750] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 2683.960756] mmc1:     24 bytes transferred: 0
[ 2683.960775] ath6kl: failed to get pending recv messages: -125
[ 2683.960780] ath6kl: host is going to stop blocking receiver for htc_stop
[ 2683.960788] mmc1: starting CMD53 arg 94083004 flags 000001b5
[ 2683.960794] mmc1:     blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0
[ 2683.960815] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
[ 2683.960829] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 2683.960834] mmc1:     4 bytes transferred: 0
[ 2683.960862] SDIO: Disabling IRQ for mmc1:0001:1...

[ 2683.962059] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
[ 2683.962076] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000
[ 2683.962082] mmc1:     4 bytes transferred: 0
[ 2683.962105] SDIO: Disabling device mmc1:0001:1...

[ 2683.962112] mmc1: starting CMD52 arg 00000400 flags 00000195
[ 2683.962132] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001
[ 2683.962145] mmc1: req done (CMD52): 0: 00001002 00000000 00000000 00000000
[ 2683.962424] mmc1: starting CMD52 arg 80000400 flags 00000195
[ 2683.962446] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001
[ 2683.962458] mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000
[ 2683.965985] SDIO: Disabled device mmc1:0001:1

[ 2683.971995] systemd[1]: Starting Load/Save RF Kill Switch Status...
[ 2683.991931] mmc1: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 timing 0
[ 2684.004667] systemd[1]: Started Load/Save RF Kill Switch Status.

ath6kl debug mode

Current: Find clues with debug_mask=0x50480 enabled.

Kernel.org ath6kl debug wiki is incorrect.

ath6kl_sdio has no debug_mask support.
Apply debug_mask to ath6kl_core instead.

Be advised you'll find an increase in CPU usage as the debug option can be quite "chatty". 

#!/bin/bash
modprobe ath6kl_core debug_mask=0x50480
modprobe ath6kl_sdio

What follows is an example where the chip has decided to disconnect with 0x50480 debug mode enabled. 

[ 4596.878491] ath6kl: <------------------------------->
[ 4596.878495] ath6kl: pending mailbox msg, lk_ahd: 0x5E60001
[ 4596.878604] ath6kl: rd addr 0x800 (fixed) buf 0xffff88006a3cdc24 len 1536
[ 4596.878613] ath6kl: wmi rx id 4112 len 1504
[ 4596.878617] ath6kl: WMI_EXTENSION_EVENTID
[ 4596.878621] ath6kl: wmi event dbglog len 1500
[ 4596.878631] ath6kl: valid interrupt source(s) for other interrupts: 0x0
[ 4596.878635] ath6kl: bypassing irq status re-check, forcing done
[ 4596.878639] ath6kl: proc_pending_irqs: (done:1, status=0
[ 4596.879518] ath6kl: wr addr 0x418 buf 0xffff88005c6a3d5c len 4
[ 4596.879558] ath6kl: cold resetting the device
[ 4596.879598] ath6kl: wr addr 0x474 buf 0xffff88005c6a3d54 len 4
[ 4596.879638] ath6kl: wr addr 0x479 (fixed) buf 0xffff88005c6a3d04 len 4
[ 4596.879675] ath6kl: wr addr 0x47a (fixed) buf 0xffff88005c6a3d04 len 4
[ 4596.879712] ath6kl: wr addr 0x47b (fixed) buf 0xffff88005c6a3d04 len 4
[ 4596.879751] ath6kl: wr addr 0x478 buf 0xffff88005c6a3cfc len 4
[ 4596.879759] ath6kl: sdio power off

Bonus round

Neat, and perhaps a source of future pleasure.
Ath-next Repo 

cat /sys/kernel/debug/ieee80211/phy0/ath6kl/tgt_stats

Bluetooth

Work in Progress: Not functioning on Venue 8.

FYI: I have not looked at this for a long time. I'm under the impression that this is heavily dependent on WiFi working reliably as well.

This is a big pile of unsorted notes, "qca" is the only protocol that seems to atleast get some form of response out of the chipset.

Current list of clues

ACPI

The actual Bluetooth UART

Device (BTH0)
	
Name (_HID, "DLAC3002" /* Qualcomm Atheros Bluetooth UART Transport */)  // _HID: Hardware ID

UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne,
    0xC0, LittleEndian, ParityTypeNone, FlowControlHardware,
    0x0020, 0x0020, "\\_SB.URT1",
    0x00, ResourceConsumer, ,
    )

Default: 115200, 8, n, 1, flow
0x0001C200 = 115200
0xC0 = 192
0x0020 = 32
0x00 = 0

GPIO toggles sit in the last GPIO pool. 

$ cat /sys/kernel/debug/gpio

GPIOs 410-511, platform/INT33FC:00, INT33FC:00:

From ACPI table

GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionOutputOnly,
    "\\_SB.GPO0", 0x00, ResourceConsumer, ,
    )
    {   // Pin list
        0x0034 // gpio-52 // 410 + 52 = 462
    }
GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionOutputOnly,
    "\\_SB.GPO0", 0x00, ResourceConsumer, ,
    )
    {   // Pin list
        0x0035 // gpio-53 // 410 + 53 = 463
    }

GPIO direct

0x0035 needs to be high for any response to be received.
0x0034 doesn't seem to react much at all.

# Claim
echo 462 > /sys/class/gpio/export
echo 463 > /sys/class/gpio/export

# Power on?
echo "high" > /sys/class/gpio/gpio462/direction
echo "high" > /sys/class/gpio/gpio463/direction

# Power off?
echo "low" > /sys/class/gpio/gpio462/direction
echo "low" > /sys/class/gpio/gpio463/direction

# debugfs
$ cat /sys/kernel/debug/gpio | grep sysfs
gpio-52  (sysfs               ) in out hi pad-88  offset:0x580 mux:0
gpio-53  (sysfs               ) in out hi pad-92  offset:0x5c0 mux:0

HCI Uart

.id		= HCI_UART_ATH3K,
.name		= "ATH3K",
.manufacturer	= 69,
.open		= ath_open,
.close		= ath_close,
.flush		= ath_flush,

Kernel

Networking support
⌞Bluetooth subsystem support
⌞Bluetooth device drivers
⌞HCI UART driver

UART (H4) protocol support
Atheros AR300x serial support
Qualcomm Atheros protocol support

Debugging Bluetooth

It appears that there's no nice kernel flag and documentation is sorely lacking for such a critical piece of infrastructure. The following a very heavy handed method that will deliver into the kernel log.

#src/drivers/bluetooth
#src/net/bluetooth

find . -type f -exec sed -i 's/BT_DBG/BT_ERR/g' {} \;

RFkill / ACPI GPIO mod

[    7.369615] rfkill_gpio DLAC3002:00: GPIO lookup for consumer reset
[    7.369624] rfkill_gpio DLAC3002:00: using ACPI for GPIO lookup
[    7.369630] acpi DLAC3002:00: GPIO: looking up reset-gpios
[    7.369636] acpi DLAC3002:00: GPIO: _DSD returned DLAC3002:00 0 0 0
[    7.369709] rfkill_gpio DLAC3002:00: GPIO lookup for consumer shutdown
[    7.369714] rfkill_gpio DLAC3002:00: using ACPI for GPIO lookup
[    7.369719] acpi DLAC3002:00: GPIO: looking up shutdown-gpios
[    7.369724] acpi DLAC3002:00: GPIO: _DSD returned DLAC3002:00 1 0 0
[    7.369854] rfkill_gpio DLAC3002:00: DLAC3002:00 device registered.

#rfkill block 0
gpio-52  (reset               ) in out lo pad-88  offset:0x580 mux:0
gpio-53  (shutdown            ) in out lo pad-92  offset:0x5c0 mux:0

#rfkill unblock 0
gpio-52  (reset               ) in out hi pad-88  offset:0x580 mux:0
gpio-53  (shutdown            ) in out hi pad-92  offset:0x5c0 mux:0

RFkill list

0: DLAC3002:00: Bluetooth
	Soft blocked: no
	Hard blocked: no

Initialize

We should be using "ath3k" but there's no observable output so, again, we use "qca" while we figure things out.

btattach -B /dev/ttyS1 -P qca

Attaching BR/EDR controller to /dev/ttyS1
Switched line discipline from 0 to 15
Device index 0 attached

rfkill unblock 0 + init

[ 1994.993890] Bluetooth: hci0: ROME setup
[ 1994.993902] Bluetooth: hci0: Set UART speed to 3000000
[ 1995.392837] Bluetooth: hci0: Frame reassembly failed (-84)
[ 1997.299427] Bluetooth: hci0 command 0xfc00 tx timeout

hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN INIT RUNNING
	RX bytes:4 acl:0 sco:0 events:0 errors:0
	TX bytes:10 acl:0 sco:0 commands:2 errors:0
	Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Packet type: DM1 DH1 HV1
	Link policy:
	Link mode: SLAVE ACCEPT

rfkill block 0 + init

[ 2035.866828] Bluetooth: hci0: ROME setup
[ 2035.866840] Bluetooth: hci0: Set UART speed to 3000000
[ 2038.166100] Bluetooth: hci0 command 0xfc00 tx timeout

hci0:	Type: BR/EDR  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:10 acl:0 sco:0 commands:2 errors:0
	Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Packet type: DM1 DH1 HV1
	Link policy:
	Link mode: SLAVE ACCEPT

Does Nothing

btattach -B /dev/ttyS1 -P ath3k
btattach -B /dev/ttyS1 -P h4

"hciattach" is the old and trusted way and doesn't talk the newer init protocols but can be used with ath3k. Using "any" did not result in anything. "btattach" is the successor to "hciattach". In saying that hciattach IS responsible for getting the firmware and rampatch loaded from userspace. 

hciattach -n -s 115200 /dev/ttyS1 ath3k flow nosleep
hciattach /dev/ttyS1 any 115200 flow

Firmware Files

Windows 8.1, 32-bit

# C:\Windows\System32\Drivers

 90K - AthrBT_0x01020201.pst
1.3K - ramps_0x01020201_26_DLAB.pst
1.3K - ramps_0x01020201_26_DLAB_gpio.pst
1.2K - ramps_0x01020201_26_DLAC.pst
1.2K - ramps_0x01020201_26_DLAC_gpio.pst
1.2K - ramps_0x01020201_26_HPAA.pst
1.2K - ramps_0x01020201_26_IAAE.pst
1.2K - ramps_0x01020201_26_IAAE_gpio.pst
1.3K - ramps_0x01020201_26_QDMN.pst
1.2K - ramps_0x01020201_26_SSAD.pst
1.2K - ramps_0x01020201_26_SSAD_gpio.pst

Arch 07.2016 install

# /lib/firmware/ar3k

-rw-r--r-- 1 root root  48K May 20 03:24 AthrBT_0x01020201.dfu

-rw-r--r-- 1 root root 1.2K May 20 03:24 ramps_0x01020001_26.dfu
-rw-r--r-- 1 root root 1.3K May 20 03:24 ramps_0x01020200_26.dfu
-rw-r--r-- 1 root root 1.2K May 20 03:24 ramps_0x01020200_40.dfu
-rw-r--r-- 1 root root  264 May 20 03:24 ramps_0x01020201_26.dfu

Kernel Compiling

Before you begin

Keep in mind that if you are dependent on a using a MicroSD reader because of the workaround you'll be dealing with a limited power budget. Disabling turbo and dropping down to 2 cores may be beneficial.

Once you have your sources and dependencies installed it's best to only have a keyboard and your MicroSD reader plugged in and nothing else before starting the make process.

The quality and therefore speed of your MicroSD reader may cause the host Kernel watchdog to report hard lockups on one of the cores as the compile process is running while it is doing a write operation.

Failure to keep this in mind will result in comedy. Otherwise it's usual fare.

AUR Linux Kernel Package

With Kernel 4.10 being released and all the essentials contained there in you can opt to do an automated package build. Be advised that due to bug #96571 and the way that the AUR package is compiled you'll find yourself unable to control the backlight. Secondly, due to bug #150881 if you dual-boot with your RootFS on a MicroSD card you'll be out of luck unless you grab an external card reader. Both matters can be addressed manually but for those just testing their hardware this may be a worthwhile method.

#AUR Package
AUR Linux-Git

# Protip
"wget" and "makepkg -si" are your friends.

# For your ~/.bashrc to optimize compile concurrency
export MAKEFLAGS="-j$(expr $(nproc) \+ 1)"

Venue 8 and 11 Pro

Kernel 4.9-rc4 sees the Venue 8 Pro Wireless identifier mainlined so that negates any need for manual patching. Thanks Adam!

For Venue 11 and older kernels, the following adds support for Dell Wireless 1537 (0x19) & 1538 (0x18).

/drivers/net/wireless/ath/ath6kl/sdio.c
#Kernel 4.8.11, go to line 1398.

{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},

Add in

{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x19))},

There are no other exotic things to deal with at this time so read on for clues and just follow Arch's kernel compiling guide.

Kernel Config File

May edition is an updated 4.11-rc2 config.
February edition is an updated 4.9.0 config.
December edition is an updated 4.8.11 config.
November edition is an updated 4.8.0 config.
October edition is an updated 4.7.0 config.
August edition adds extra USB, Filesystem and Networking material beneficial to daily use.
If you want to save time use the the July config which is more bare bones.

May 2017 :: DV8Pro-Kconfig-4.11.1-May17.txt - 143.1 KB
February 2017 :: DV8Pro-Kconfig-4.10.0-Feb17.txt - 139.1 KB
December 2016 :: DV8Pro-Kconfig-4.9.0-Dec.txt - 136.8 KB
November 2016 :: DV8Pro-Kconfig-4.8.11-Nov.txt - 135.2 KB
October 2016 :: DV8Pro-Kconfig-4.8.0-Oct.txt - 135.2 KB
August 2016 :: DV8Pro-Kconfig-4.7.0-Aug.txt - 133.6 KB
July 2016 :: DV8Pro-Kconfig-4.7.0.txt - 122.0 KB
January 2016 :: DV8Pro-Kconfig-4.4rc8.txt - 120.3 KB

BTRFS

Add BTRFS to the kernel directly, not as a module if you're using a MicroSD card as rootFS. Bonus points for replacing the "fsck" hook with "btrfs" in your mkinitcpio.conf.

Getting Ready

Baking Dependencies: 

pacman -S bc base-devel

The Arch Wiki explains compiling your kernel the best so there's no need to repeat everything.

#Kernel 4.8 compile time, October 2016 config.

real	47m28.266s
user	125m32.049s
sys	10m10.763s

#Kernel 4.11-rc1 compile time, February 2017 config.

real	43m1.400s
user	126m58.409s
sys	10m43.063s

Grab your kernel, extract it and to save time do a "make localmodconfig".
Be advised, localmodconfig may disable many useful things. (Like loopback device, FUSE support). It's recommended once ready to do a full compile so you'll have all the kernel goodness with sugar on top.

Automation

A little crude perhaps, but most efficient. This is how I bake my Kernels straight from the tarball. Script sits in the root of the unpacked Kernel source. 

#!/bin/bash
make -j 4
make -j 4 modules
make modules_install
cp -v ./arch/x86/boot/bzImage /boot/vmlinuz-linux412
mkinitcpio -k 4.12.0-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux412.img

Manual Selection

ToDo: Audio, I should make a mention of snd_soc_core and snd_soc_rt5640. localmodconfig should include these though.

MicroSD reader (Bug #150881)

This regression happened from 4.8.x to 4.11.x and is now fixed in Kernel 4.12. The bug prevented the MicroSD reader from working correctly.

This makes sure the root filesystem on a MicroSD card can be found.
	
Device Drivers
⌞ Real Time Clock
⌞ PC-Style 'CMOS'

CONFIG_RTC_DRV_CMOS [=m]
Processor Support
Processor type and features

We require: /dev/cpu/*msr - Model-specific register support
Enables: powertop / cpupower to function correctly

CONFIG_X86_MSR [=m]
Atheros 6K Wifi

Enable debug and tracing too if your beard is long like mine.

Device drivers
⌞ Network device support
⌞ Wireless LAN
⌞ Atheros/Qualcomm devices
⌞ Atheros mobile chipsets support

We require: Atheros ath6kl SDIO support
Enables: Atheros SDIO Wifi Support

CONFIG_ATH6KL [=m]
CONFIG_ATH6KL_SDIO [=m]
Backlight PWM Support
Device Drivers
⌞ Pulse-Width Modulation (PWM) Support

CONFIG_PWM [=y]

We require:
- Intel Crystalcove (CRC) PWM support
- Intel LPSS PWM Support
- Intel LPSS PWM platform driver
Enables: Backlight PWM

CONFIG_PWM_CRC [=y]
CONFIG_PWM_LPSS [=m]
CONFIG_PWM_LPSS_PLATFORM [=m]
Backlight ACPI PMIC Support
Power Management and ACPI options
⌞ Power management and ACPI options
⌞ ACPI support
⌞ PMIC operation region support

We require: ACPI Opration region support for CrystalCove PMIC
Enables: Backlight Power Management

CONFIG_PMIC_OPREGION [=y]
CONFIG_CRC_PMIC_OPREGION [=y]
Backlight Control Support
Device Drivers
⌞Multifunction device drivers

We require: Support for Intel Atom SoC PMIC
Enables: Backlight Controls

CONFIG_INTEL_SOC_PMIC [=y]
GPIO / I2C / Sensor Support

You'll also need basic IndustrialIO support so hid_sensor modules can actually read out values generated by said sensors, if you're doing a localmodconfig these should already be on.

Device Drivers
⌞I2C support
⌞I2C support
⌞I2C Hardware Bus Support

We require: Synopsys Designware Platform
Enables: Sensors and Backlight GPIO

CONFIG_I2C [=y]
CONFIG_I2C_DESIGNWARE_CORE [=m]
CONFIG_I2C_DESIGNWARE_PLATFORM [=m]
Hardware Buttons

The Venue 8 has 4 buttons. Power, Volume Up, Volume Down and a "home" button with branding.

The Power button is responsible for generating the wake-up interrupt when device has been put to suspend mode. 

Device Drivers
⌞Input device support
⌞Miscellananeous devices

We require: Windows-compatible SoC Button Array
Enables: Physcal hardware buttons

CONFIG_INPUT_SOC_BUTTON_ARRAY [=m]
GPIO Keys mapping
Device Drivers
⌞Input device support
⌞Keyboards

We require: GPIO Buttons
Enables: GPIO buttons to Keyboard mapping

CONFIG_KEYBOARD_GPIO [=m]
Industrial I/O Sensors

I completely forgot to document the relevant sensor modules in the original write up.

There appears to be a power problem in that IIO only seems to show up reliably after a cold boot.

ToDo: Sort out correct modules

Device Drivers
⌞Industrial I/O support

We require: MODULE ALL THE THINGS.
Enables: Hardware Sensors

CONFIG_IIO [=m]
CONFIG_HID_SENSOR_IIO_COMMON [=m]

Device Drivers
⌞HID support
⌞HID bus support
⌞Special HID drivers

CONFIG_HID_SENSOR_HUB [=m]
Intel Signal Processor

The Venue 8 has a front and rear camera connected to a MIPI-CSI Bus.

Kernel 4.12 staging brings initial support. 

Device Drivers
⌞Staging Drivers
⌞Media Staging Drivers
⌞Enable support to Intel MIPI camera drivers

We require: Modules all the things!
Enables: Camera(s), potentially.

CONFIG_INPUT_ATOMISP [=y]
CONFIG_VIDEO_ATOMISP [=m]

At the moment when compiled the Kernel will show a number of trace reports during boot. As the camera modules appear to be in an unpowered state it is not able to finish probing correctly. 

[9.257441] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_I2CAddr
[9.257451] ov5693 i2c-INT33BE:00: gmin: initializing atomisp module subdev data.PMIC ID 1
[9.258085] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CamClk
[9.258684] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_ClkSrc
[9.259280] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CsiPort
[9.259874] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CsiLanes
[9.265595] ov5693 i2c-INT33BE:00: sensor power-up failed
[9.265608] ov5693 i2c-INT33BE:00: sensor power-up failed
[9.265615] ov5693 i2c-INT33BE:00: sensor power-up failed
[9.265622] ov5693 i2c-INT33BE:00: sensor power-up failed
[9.265628] ov5693 i2c-INT33BE:00: ov5693 power-up err.
[9.265634] ov5693 i2c-INT33BE:00: sensor power-gating failed
[9.306753] ov5693: probe of i2c-INT33BE:00 failed with error -22

[9.346612] mt9m114 i2c-INT33F0:00: gmin: initializing atomisp module subdev data.PMIC ID 1
[9.347285] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CamClk
[9.347905] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_ClkSrc
[9.348506] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CsiPort
[9.349096] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CsiLanes
[9.349257] mt9m114 i2c-INT33F0:00: sensor power-up failed
[9.349264] INT33F0:00: mt9m114 power-up err
[9.366735] mt9m114: probe of i2c-INT33F0:00 failed with error -22

That's a wrap

If the "i915" module starts BEFORE gpio is registered, you'll find your dmesg spewing "Failed to own gpio for panel control" at you which then means you can't control your backlight. So if you want early KMS happening correctly make sure you have the Intel and control interface modules loaded like thus. 

# /etc/mkinitcpio.conf
MODULES="i2c_designware_platform i2c_designware_core i915"

#Copy your kernel
cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux4120

#Roll a init ram disk:
mkinitcpio -k 4.12.0-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux4120.img

If you haven't already, make sure your Grub is properly configured.

Troubleshooting

Kernel Compiling
MicroSD Slot
Intel Video
Atheros Wifi
Bay Trail Audio
IIO Sensors
Venue 8 "Quirks"
Dual Boot

Dislocker

Accessing a Bitlocker Volume

For, I suppose understandable reasons, Dell shipped the Venue 8 with a "Bitlocker" volume instead of a standard NTFS volume. This means that you can't just mount it. Fortunately there is "dislocker" which offers a FUSE module (depending on how it's compiled) for mounting said volume.

AUR has a package available with FUSE mode enabled.

Process and roll your package according to the rules and then proceed to make 2 mount folders.

mkdir /mnt/dislocker/
mkdir /mnt/ntfs/

With those in place we can mount our internal eMMC thus, assuming no password. "-c" Indicates a clear key. If you have an encryption password try "-u" instead.

Further alternative authentication modes include via USB "bek" file or recovery password. For these options consult the man pages.

This following works fine for me. 

#!/bin/bash
# Read only all the things.
dislocker -r -v -V /dev/mmcblk0p4 -c -- /mnt/dislocker/
mount -o loop,ro /mnt/dislocker/dislocker-file /mnt/ntfs/ -t ntfs

System Summary (V8P)

Todo: Add Wifi / Bluetooth ACPI and Vendor/Device Data.

Data Dumps

MMC Devices

Atheros SDIO Wifi

Dell Venue 8 Pro

lspci

00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Graphics & Display (rev 09)
00:14.0 USB controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series USB xHCI (rev 09)
00:1a.0 Encryption controller: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine (rev 09)
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx Series Power Control Unit (rev 09)

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 55
Model name:            Intel(R) Atom(TM) CPU  Z3740D @ 1.33GHz
Stepping:              3
CPU MHz:               959.147
CPU max MHz:           1832.6000
CPU min MHz:           499.8000
BogoMIPS:              2663.33
Virtualization:        VT-x
L1d cache:             24K
L1i cache:             32K
L2 cache:              1024K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse
sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon
pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni
pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr
pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand
lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi
flexpriority ept vpid tsc_adjust smep erms

Mudkips

They don't wear coats.

If you have a need to say hello email 0x431999 at this particular domain. Ensure the use of a sensible subject line so you'll make it past the filters. Replies are not guaranteed. This is a hobby / learning project and day to day work keeps me busy enough.

This slab of text is written with the best of efforts and may be incomplete or unintentionally cause global warming and hell to freeze over. I take no responsibility of any kind, no guarantee is implied or given.

Give or take the couple of spelling mistakes you may encounter.
Most of this is written after midnight with a brain that's running low on power. Meanwhile, I manage to remain surprisingly coherent.

Now that you've reached the end of this you shouldn't:
Follow me, Like me, Flattr me, Web 3.0 me.

In fact, don't worry about me.
Walk your own path with your head held high.

I only claim credit for reading many internets and adding some ketchup. Nothing else. Ergo, my contributions are licensed under the WTFPLv2.

LLAP,

    Blake

Revision Log

15/12/2015
- Initial Write-up.
17/12/2015
- Updated X.org settings.
18/12/2015
- Added IIO experiments.
19/12/2015
- Fixed early KMS support.
- C-State notes.
21/12/2015
- Added additional patch set.
- EFI mem map info found.
- Dislocker, Delivers.
22/12/2015
- System Summary, CSS tweaks, Proper TL;DR;
23/12/2015
- Venue 11 Pro SDIO Wifi ID.
- Updated Venue 11 Pro operational status.
- P-state testing, sdhci-acpi testing.
- Power Management Section.
24/12/2015
- Stability testing day!
- Updated ALSA notes.
29/12/2015
- MMC / SDHCI / ath6kl notes.
- Updated Power Management.
- Hardware / GPIO Buttons.
30/12/2015
- Clean ups.
31/12/2015
- Wireless / Bluetooth Sections.
04/01/2016
- Bluetooth notes. Headphones!
05/01/2016
- Kernel notes, Kconfig.
06/01/2016
- ALSA, Bluetooth, Button, Power notes updated.
15/01/2016
- Kernel 4.4 Notes.
18/01/2016
- Hibernation / Sleep / Power notes updates.
26/02/2016
- Preliminary Kernel 4.4.2 / 4.5rc5 notes.
March/2016
- Quick Notes, time constrained.
July/2016
- Kernel 4.6 / 4.7 notes.
- Selective Revisions, Venue 11 updates.
- ALSA section rework.
August/2016
- New Shots.
- Wireless.alt section added.
- Wayland section added.
- Adjustments and cleanups.
October/2016
- Kernel 4.8 config + notes.
- New Action Shot.
- Wayland improvements.
- Re-organized Power Management section.
- Cleaned up various sections.
November/2016
- Venue 11, improvements.
- Cleaning up for clarity.
- Return of the ALSA init script.
- Found Grub forum post.
December/2016
- Venue 11, Wireless card support section.
- Venue 8, BIOS "Boot Mode" menu explained.
- Rephrasing for clarity in sections.
- Kernel 4.9.0 lands, update time.
- Initial EFI vs KMS Research.
- Testing various Grub Releases.
- Added NFC section.
- MicroSD Card, Bios Notes.
February/2017
- Kernel 4.10, feels good man.
- Re-ordered status list.
- X.org Modesetting.
- TL;DR; & Intro revised.
March/2017
- AUR Git Kernel
- ALSA modprobe blacklist
- Misc. Documentation fixes.
- Kernel 4.11-rc1 experimentation.
- The power of a Name.
May/2017
- Kernel 4.11.1, stable-ish cstate-ish.
July/2017
- Kernel 4.12
- Suspend Works, Windows removed.
- Distro Hopping!
- Updated bugs list.
- Updated segments.
- Battery has returned!
- "BayTrail" vs "Bay Trail" consistency fixes.
- 4.12 Screenshot & Native EFI Photo.
- Table of Content Robot.
January/2018
- Kernel 4.14
- Distro Hop, Round 2!
- Dropped 32-bit distributions.
- General clean ups.
- tocGen 0.5
- iwup.py v1.2 released.
May/2020
- Fedora 32 Notes
- Cleanups
June/2020
- ... 

//- Rev -// v0.x // Epoch