More Troublesome x86 Android Tablets Being Fixed Up By New Linux Driver

[phoronix]

Phoronix: More Troublesome x86 Android Tablets Being Fixed Up By New Linux Driver

Last week I called attention to the new "x86-android-tablets" driver being prepared for introduction in Linux 5.17. That driver aims to fix up the mess of various x86 Android-focused tablets failing to run off the mainline Linux kernel or having various device issues in doing so. Since that prior article, more patches have been posted to address additional tablet issues...

https://www.phoronix.com/scan.php?page=news_item&px=x86-Android-Tablets-More

[hansdegoede]

Before people think this is adding bloat to the kernel, quoting a bit more from the cover-letter of the series:

Since the ACPI tables on these devices clearly are buggy this series is written so as to add minimal changes to the ACPI core code, leaving all of the heavy lifting to the recently introduced (in linux-next) drivers/platform/x86/x86-android-tablets.c module, which when built as a module only autoloads on affected devices based on DMI matching.

[sinepgib]

Hi hansdegoede. Is there any chance to find documentation on how to determine which boards are buggy and the proper values to add to the driver?
I have a hobby project that I may or may not actually start and I'm worried I might bump into those kind of issues.

[ernstp]

Hi hansdegoede. Is there any chance to find documentation on how to determine which boards are buggy and the proper values to add to the driver?
I have a hobby project that I may or may not actually start and I'm worried I might bump into those kind of issues.

I guess it's more a case of.. you expect there to be an accelerometer and if one doesn't show up, you start looking into why.

[hansdegoede]

Hi hansdegoede. Is there any chance to find documentation on how to determine which boards are buggy and the proper values to add to the driver?
I have a hobby project that I may or may not actually start and I'm worried I might bump into those kind of issues.

If you are dealing with an x86 based Android tablet, which shipped with Android as factory OS and *only* Android (so no multiboot with Windows as is often seen with e.g. Chuwi devices) then there is a big chance, like 90% big, that the DSDT contains a lot of nonsense.

May I ask what the brand + model is of the device you plan to use for your hobby project ? All models I've been working on so far use an Intel Bay Trail SoC; and to be able to (easily) run the mainline kernel it is also important that the device comes with a standard UEFI BIOS and not with some weird firmware. E.g. The Asus TF103C needs to be updated from Android 4.4 to 5 using the official Asus updates before even thinking about installing the mainline kernel, because the Android 4.4 to 5 update includes a BIOS updates which replaces the weird custom firmware used with Android 4.4 with a standard UEFI BIOS (with broken DSDT, but otherwise a normal UEFI BIOS).

What you can do is connect a *powered* hub over the micro-usb port using a micro-USB to USB-A converter / dongle (AKA an OTG converter), plug in a keyboard and repeatedly hit "ESC" while powering on the device. If it has a normal BIOS this should give you the BIOS menu.

What also is important is to NOT remove Android yet, in order to get mainline to work a bunch of information needs to be collected from within Android (over adb). Let me know if you want a short howto for the information to collect under Android.

Edit: See this postmarket os wiki page for more info on the TF103C Android update

[sinepgib]

May I ask what the brand + model is of the device you plan to use for your hobby project ?

For now, there's none, but I'm part of a small community that tries to keep old hardware alive and useful and redistribute it, so it may come handy to get our hands in some of these tablets and play with them.
I do want to migrate an ebook reader I own, but that one is ARM. I guess the general idea on how to find this kind of ad-hoc stuff may be useful for that too, even tho it's not exactly the random ACPI issue.

Thanks for the thorough explanation.

[caligula]

If you are dealing with an x86 based Android tablet, which shipped with Android as factory OS and *only* Android (so no multiboot with Windows as is often seen with e.g. Chuwi devices) then there is a big chance, like 90% big, that the DSDT contains a lot of nonsense.

But the article also mentions Chuwi devices? Does this work help at all with e.g. Chuwi Hi10 (https://www.devicespecifications.com/en/model/da3636e2). I think these already boot nicely, but may not have supported bt/wifi/touch drivers out of the box in mainline.

[R41N3R]

Maybe this can help to get the Huawei Matebook 12 fully supported on Linux, it requires as well several tweaks.

[hansdegoede]

But the article also mentions Chuwi devices? Does this work help at all with e.g. Chuwi Hi10 (https://www.devicespecifications.com/en/model/da3636e2). I think these already boot nicely, but may not have supported bt/wifi/touch drivers out of the box in mainline.

The one chuwi device which the x86-android-tablets code supports is an older Bay Trail based Windows/Android dual-boot device. You actually select which OS to boot there by flipping a "boot OS" option in the BIOS and when this is set to Android you still get a broken DSDT, but when booting windows the DSDT is fine and the x86-android-tablets code will fail to load because the I2C devices it tries to create are already present.

On newer (Cherry Trail based) Chuwi tablets the DSDT usually is fine independent of the device being in Android or Windows mode.

As for the Chuwi Hi 10, there are many models of that device, most of them should work fine with the mainline kernel, except for the cameras (which don't work on any Bay / Cherry Trail devices at all). Note the touchscreen is a bit finicky though, these are using Silead touchscreens which require firmware which is not in the Linux firmware repo; and if you are the first to run the mainline kernel on it, it also requires which firmware to load exactly to be added to a special table in the kernel. See here for a git repo with collected Silead firmwares.

[caligula]

The one chuwi device which the x86-android-tablets code supports is an older Bay Trail based Windows/Android dual-boot device. You actually select which OS to boot there by flipping a "boot OS" option in the BIOS and when this is set to Android you still get a broken DSDT, but when booting windows the DSDT is fine and the x86-android-tablets code will fail to load because the I2C devices it tries to create are already present.

On newer (Cherry Trail based) Chuwi tablets the DSDT usually is fine independent of the device being in Android or Windows mode.

As for the Chuwi Hi 10, there are many models of that device, most of them should work fine with the mainline kernel, except for the cameras (which don't work on any Bay / Cherry Trail devices at all). Note the touchscreen is a bit finicky though, these are using Silead touchscreens which require firmware which is not in the Linux firmware repo; and if you are the first to run the mainline kernel on it, it also requires which firmware to load exactly to be added to a special table in the kernel. See here for a git repo with collected Silead firmwares.

Cool, thanks a lot for the info.