FWIW: that DSDT hack is replacing a constant return value from the first method in the "HAD" device. It was specified to return 0, but now returns 0xf instead. This is almost certainly the _STA (status) method, which informs the OS about the operational status of the described device. I forget the exact meaning of the bottom four bits offhand, but 0xf is the standard value for "device present and operating normally -- use it!".
That it was returning zero would cause the linux ACPI framework to ignore it and not probe its driver. My vague understanding is that windows works differently, and calling _STA is done by the driver, so it's possible to just not do it and still have a working system.
I don't know what the device itself is, but given that the script says "audio" in there it's probably the audio codec.
PendoPad 11" 'laptop' running Windows 10 Home 32 bit (despite having a 64 bit capable processor).
I replaced the bricked device and I'm going to be a lot more careful this time.
Booting Ubuntu Wily works, but there's no battery (status/charging?), wifi, audio or touchscreen. So if you use the XDA scale it's working perfectly!
I have another Z3735 device (MeegoPad T01 - Intel Compute Stick knockoff), but it's unusable because the clock runs fast, then slow, then fast - enough that an NTP sync makes the clock go backwards and then everything breaks.
These chipsets are turning up everywhere and most of the time the implementation is garbage. I hope Intel did better with the reference implementation/s but I can't afford them at the moment.
The idea of multiple vendors making the same "beige boxes" and only competing on price is bad. One of the things on my wishlist for an Intel/AMD branded laptop is a high quality UEFI implementation.
Keep wishing. Even a $1400 Lenovo X1 had terrible UEFI when I used it - what's the point of re-implementing your old keyboard-only BIOS UI exactly if you have mouse support? Dell does better, at least in the business grade products.
That it was returning zero would cause the linux ACPI framework to ignore it and not probe its driver. My vague understanding is that windows works differently, and calling _STA is done by the driver, so it's possible to just not do it and still have a working system.
I don't know what the device itself is, but given that the script says "audio" in there it's probably the audio codec.