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

[RussianNeuroMancer]

I'm afraid not. First thing I did when I got it was throw Linux on it to find these flaws. Trying to put Windows back on it, even less hardware works out of the box. I was able to get a zip file of drivers from MicroCenter support way back to alleviate some of the issues, but I long since lost it. I'll try to get them again this weekend.

Once I have them, what should I do with them? How do Windows drivers translate to linux?

Check if Silead driver loads on Linux, and if it is, then you will need firmware file from Windows driver. Google for "silead linux firmware" on GitHub to get idea.

[gamerminstrel]

Touchscreen and auto-rotation should be easy to fix even for non-developer. Do you have windows drivers dump somewhere by any chance?

I'm afraid not. First thing I did when I got it was throw Linux on it to find these flaws. Trying to put Windows back on it, even less hardware works out of the box. I was able to get a zip file of drivers from MicroCenter support way back to alleviate some of the issues, but I long since lost it. I'll try to get them again this weekend.

Once I have them, what should I do with them? How do Windows drivers translate to linux?

[RussianNeuroMancer]

Where would I even begin if I wanted to contribute and help get it running properly too?

Touchscreen and auto-rotation should be easy to fix even for non-developer. Do you have windows drivers dump somewhere by any chance?

[gamerminstrel]

I've got a CherryTrail tablet of my own, the "WinBook TW102" that I bought from MicroCenter a few years back. Running Fedora 36 on it, it still is missing some hardware functionality (no touch screen, no autorotation, maybe other things) and it might be because of the issue described in this article. Where would I even begin if I wanted to contribute and help get it running properly too?

[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.

[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.

[R41N3R]

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

[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.

[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.

[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