[Windows 8 Development and Hacking] jonpry:
I finally got one of these T100 deals, so I'm actively working on getting linux to run well on it. I currently have Debian Jessie running off of an external hard drive using 3.15rc4. I was able to build the kernel with mixed-mode EFI support which sort of appears to be working as I can read vars and have not detected any errors, although I still don't have suspend or any power button action. 3d graphics work well and I didn't have any trouble with sound.

Wifi is a can of worms, but I'm starting to get a handle on the real problems. SHDCI controller has a number of quirks and straight up bugs in baytrail-m. AdamWill at https://github.com/AdamWill/baytrail-m/tree/master/kernel seems to have a handle on a number of them. One must use the gpio_quirk patch in order to get proper settings for what is wrong with the SDIO port. Still not 100% with that patch but with some fiddling I did get connected at high speed to a very far access point. Much better than my laptop is able to achieve. I believe the pinctrl patch must also be applied as gpio interrupts are currently broken and wifi of course needs those to work. When I tried it just hung the kernel, so need to do some research there.

Looks like progress to me :)

Edit:

It appears that rc4 at least includes some way to deal with GPIO interrupt problems. Not sure that pinctrl is going to fix much of anything. With a modified SDIO quirks patch things do appear to be much better. I am confused as to exactly how though and I always like to have a working theory! According to intel errata the mmc3 power output just doesn't work, and it needs to be done with GPIO. So let's assume for the moment that power output was doing nothing. Then how was wifi working at all? I have never heard of a board with the wifi permanently on, like how to do airplane mode? So does the wifi have some kind of pullup making it on, unless we explicitly turn it off, making this patch all smoke and mirrors, or was it floating somehow? If it was floating, then maybe that explains some instability, but not so much the reduced signal strength.

I was able to get battery meter working on rc4. Buttons would be nice, maybe light sensor, but it's not much good without backlight control. I'll mess with it a little more and then I will post some patches. I'm considering putting up a disk image that will work on usb flash/hdd. I mostly did this as a way to bootstrap my install onto the flash. Not much into using the installers and it's nice to have a fully functional system on removable media you can do repairs with and such.

Edit2:

I tried to take a whack at suspend. This rumor of the problem being lack of mixed-mode EFI is all wrong. Suspend is implemented on T100 with good old fassioned ACPI. But alas it does not work.

Relevant portion of dmesg:

[ 0.305020] ACPI: Interpreter enabled
[ 0.305044] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20140214/hwxface-580)
[ 0.305068] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140214/hwxface-580)
[ 0.305089] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S3_] (20140214/hwxface-580)
[ 0.305110] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S4_] (20140214/hwxface-580)
[ 0.305138] ACPI: (supports S0)

So it would appear the tables do not contain any definitions for any sleep states other than freeze. Could this be one of the fabled connected standby only devices? Could also be a bug in parsing the aml. Don't know enough about acpi to pull the tables and make sure there is really no sleep.