yashsingh1/xdaforums huggingface dataset:
[Windows 8 Development and Hacking] Jhong2:
Cool, I'll keep tracking mixed-mode then. I'm a bit frightened of it at this stage TBH -- I'm not sure how userspace utilities (e.g. efibootmgr) will react to having efi runtime available with a different bitness. Don't want to brick my laptop.
[Windows 8 Development and Hacking] nemuro:
Hope I don't intrerupt things here. Don't know if it adds anything useful to the discussion here, since it seems the Devs started making their thing, but I, as a non-dev, found this interesting: http://forums.anandtech.com/showpost.php?p=35652212&postcount=1500

It seems someone managed to boot using UEFI from an image. More importantly, it seems it's a x64 OS.
[Windows 8 Development and Hacking] Alex Atkin UK:
I still think booting x64 would be hugely wasteful with only 2GB RAM, I would expect the performance benefit to be completely overshadowed by the fact everything uses so much more of that RAM. Still, each to his own.

That said, I would still expect it to be a huge improvement over Windows 8.
[Windows 8 Development and Hacking] Jhong2:
You can boot no problem with an image -- just download an Ubuntu daily build and follow the first posts in this thread here -- in fact they are derived from that guy on AnandTech I think. I'll put a blog post up soon.

I'm using 64bit, more out of habit than anything else, but also because it gets more development and testing these days. It's helped mostly because I can easily compile on my more powerful 64bit desktop and test here. No problem booting. EFI runtime services are just unavailable. For now...
[Windows 8 Development and Hacking] AdamWill:
I do all my builds through the Fedora package system, in fact, because I'm just a packaging nerd =) It's trivial to build for any arch. Most builds I actually use the Fedora build servers for, if I want to build one locally I use mock, which is Fedora's tool for doing a clean build in an isolated chroot; again it's trivial to build for i686 on an x86_64 host when you're doing that.

It's kinda funny because everyone else seems to be building customized kernel trees directly on a 32-bit system or even on the tablet itself, while I'm doing everything in spec files...heh.

I think the Intel guys are mostly using my 32-bit-native approach for now, so the bugs in the 32-bit paths got cleaned up fairly rapidly. A stock 3.14rc4 (well, 'stock' Fedora Rawhide) kernel boots on the V8P now (but doesn't shut down / reboot, or have sound support, and still has the performance bug).
[Windows 8 Development and Hacking] Alex Atkin UK:
I'm glad someone is, I'm more interested in getting Fedora (KDE Spin) on my T100 than Ubuntu.
[Windows 8 Development and Hacking] AdamWill:
Well, give Fedlet a shot:

https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/

it's GNOME not KDE, but it's Fedora. I could do a KDE build for you quite easily, I guess. I haven't had much feedback on the 10" (T100) build, so if you could let me know how it works that'd be great. If you choose to install it (and I really wouldn't recommend blowing away Windows unless the tablet is just a toy for you), you'll have to tweak the video= parameter of the installed system.

---------- Post added at 11:56 AM ---------- Previous post was at 11:54 AM ----------

In case you didn't see it, Matt just posted a mixed mode patch series to linux-efi. http://article.gmane.org/gmane.linux.kernel.efi/3557
[Windows 8 Development and Hacking] GoodDayToDie:
64-bit really doesn't use that much more RAM (a bit more, sure, but not as much as you're suggesting) but it's true that the performance improvements are modest at best. The security improvements (when funning 64-bit programs, which are also the programs that may need more RAM than otherwise) are possibly significant, though.
[Windows 8 Development and Hacking] Alex Atkin UK:
Probably the most relevant thing about sticking 32bit is how much less space you need.

Since using 64bit on my desktop the root partition has literally doubled due to having two copies of everything to maintain 32bit compatibility. This would be a huge problem trying to squeeze onto my T100s eMMC alongside Windows 8, as I only have the 32GB model.

This is why I am keenly watching this thread but haven't tried anything yet - I don't want to risk messing up Windows or the recovery data. With limited RAM and eMMC its going to need to be a pretty precise install to be functional. The Micro SD slot seems to load really slowly so I would rather not use that for root (not that it seems to be possible yet anyway).
[Windows 8 Development and Hacking] GoodDayToDie:
Oh sure, you'll definitely use more storage. It's not quite twice as much - not anywhere close to everything is duplicated - but it's a good 30-50% increase. On devices with very limited storage, by all means stick to 32-bit.
[Windows 8 Development and Hacking] Alex Atkin UK:
Very true, I should probably have been specific that my desktop doubled because of 64bit AND installing development packages. :p
[Windows 8 Development and Hacking] paperWastage:
seeing that i am the guy you are talking about and the OP of this thread :laugh:

get a decent USB 3.0 reader + SDHC. should get decent speeds (or USB 3.0-> sata + SSD)

http://www.youtube.com/watch?v=Ly3PY8EDMPk

I'll let you guys play with it. lack of time on my end to continue investigating. might take the info you guys posted and look at android (since I don't see anyone posting about it)
[Windows 8 Development and Hacking] Jhong2:
- Sound: I can't get the intel/haswell-dsp branch in the Asoc repository to compile at all -- with or without the additional patches. I tried merging their changes into mainline, and just checking out and compiling the whole branch directly. Each time the compilation fails when linking to the net drivers for some reason. Did you encounter this in your builds, [MENTION=1512020]AdamWill[/MENTION] ?

- Buttons: I tried adding the gpiolib/acpi patches I pointed to yesterday in the hope of getting the button driver to work. No joy, the patches apply but there are several basic problems that prevent compilation. Will have to wait until those changes are a bit more mature I think.

- Mixed-mode(aka solving poweroff and suspend/resume on 64-bit with 32-bit UEFI): I can try compiling the changes in efi/mixed-mode but I'm still a bit nervous about the implications of a bug in this branch. To be clear, booting is fine (and has been for a while)....

... but I don't want to sit and twiddle my thumbs, so that leaves the sensors. Has anyone had any success in this area? If not I'll start looking further. It looks like the drivers are all there, but it's a matter of writing the "glue" to bind the sensor drivers to the right I2C bus and talk to the right address. It seems that in the ARM world this is all handled by board files, but there are some examples on x86 for I2C light sensors etc. in Chromium OS.

The light sensor should be easy enough (but useless given we can't adjust the backlight yet). I think the motion sensor is a bit more complicated -- it needs more initialization, and a newer driver than inv-mpu-6050. The newer driver seems to be already available in Android, so I guess we can use that.
[Windows 8 Development and Hacking] AdamWill:
No, not at all, I'm afraid. Sounds odd that it'd fail in linking the network drivers, AFAIK none of the patches touch anything outside of sound.

I'm not aware of anyone working on that stuff yet. You might want to look for anything to do with "Rambi" in the ChromiumOS tree - that's a Baytrail-based device.
[Windows 8 Development and Hacking] Jhong2:
Ah, never mind -- my computer doing the compiling is obviously flaky. I think it needs to sit in a bucket of ice or something...
[Windows 8 Development and Hacking] Jhong2:
OK, I managed to compile the soc audio, but (after a lot of fiddling with the 40+ exposed alsa devices), the best I get is sound through the mono DAC -- very scratchy and limited. Do we need to figure out which DAC is connected to which pins for each laptop? Or anything in /etc/modprobe.d/alsa-base.conf?

BTW I added these to /etc/modules. Are all of them needed?

snd-soc-core
snd-soc-sst-acpi
snd-soc-sst-baytrail-pcm
snd-soc-rt5640
snd-soc-sst-byt-rt5640-mach

Also, note that the patch "Add baytrail GPIO and LPSS IDs" should *not* be applied, at least for the Asus T100. It was actually added prior to 3.13 and then reverted. I tried it anyway, and it seems to bind the devices to the wrong i2c bus, spamming dmesg. It also breaks the touchscreen.

UPDATE

Also, the sides of the screen are getting scaldingly hot. When looking at the screen in landscape mode, about 1/2 to 2/3 of the way down, my screen is quickly getting too hot to touch (80 degrees + I'd say, enough to burn hands through the casing). I reverted to a previous kernel and the problem is gone. It occurred equally on both sides of the screen, so I initially thought it might be backlight controllers, but I'm not sure.

I suspect one of the PWM patches so will try compiling the soc sound stuff without them..... be careful and check your temps, if yours is as hot as mine was getting, the hardware wont last long.

UPDATE 2

... I did a plain merge of soc branch intel/haswell-dsp onto Linus' tree without any additional patches. Still red hot (and sound no less functional).

As soon as I unload snd-soc-sst-baytrail-pcm and reboot, temps go back to normal. Take care if you're trying sound, it's really alarmingly hot.
[Windows 8 Development and Hacking] TheMoro:
Has anyone been able to turn down the backlight on this thing? I see the right devices in /sys/class/backlight but they don't seem to do anything.
[Windows 8 Development and Hacking] Jhong2:
No, not yet.. yeah, you can write to /sys/class/backlight/<>/brightness , but nothing happens.
[Windows 8 Development and Hacking] TheMoro:
So, just a matter of waiting for the Wizardly Devs to work their magic then? I'll be glad when I finally get rid of this awful piece of software called "Windows 8.1". I had thought about poking around the DSDT and stuff, but really havnt gotten around to doing anything. I guess I can wait a little longer :)

If this hasn't been said enough already, hardware wise this is a superb device. $350 well spent, even without a usable OS ;)
[Windows 8 Development and Hacking] Jhong2:
OK, some updates:

- I fixed up a driver for the light sensor (Capella CM3218). There wasn't a suitable driver in the mainline (the cm32181 driver doesn't work), but Capella had submitted a draft for the cm3218 early last year, and apparently didn't follow up requests for changes. I cleaned this up a bit and added ACPI I2C auto-detection to it. Works for me...

Please test it and let me know how you get on: download and instructions for testing here.

So once the backlight control is working, we'll be able to get auto-dimming working. (I don't suppose anyone has leads on the backlight?)

- I also added a screen rotation script. This rotates the screen (including the touchscreen axes) 90 degrees clockwise each time it is launched. Before long we can use this as a base to rotate according to the orientation sensor (which I'm still working on...)

Let me know how you get on :)
[Windows 8 Development and Hacking] AdamWill:
FWIW, with my Fedlet builds, I found at least on the V8P, touchscreen rotation magically started working without special poking of xinput stuff, somewhere around 3.14rc3. So I dropped the xinput bashing from my v8p_rotate.sh script (all it really does now is call xrandr). Does that not apply to the T100?

---------- Post added at 06:18 PM ---------- Previous post was at 06:02 PM ----------

Did you try the config from my git repo? That's straight from the driver author from his T100, so I'd expect it to be right...for the V8P I have to tweak one channel, but that's just because the V8P only has one speaker.

I didn't have to add anything like that; the correct modules were loaded automatically for me (i.e. probing worked).

One of the other patches I added alongside it resolves this, IIRC. Note I'm carrying three patches in a little bunch, there, two of which were not upstreamed in the previous attempt. If you read the reference links for all three patches from https://github.com/AdamWill/baytrail-m/blob/master/kernel/MANIFEST it may make things clearer.

Doesn't seem to be happening here. Interesting that the PWM/LPSS stuff isn't necessary for sound to work, though.
[Windows 8 Development and Hacking] Jhong2:
The touchscreen rotated independently of the screen last I checked... the xinput stuff is needed in order to stay in sync. I'll eventually change the script to accept an orientation so it can receive rotation events. I'd also like to add a fadein/out....

This is all resolution-independent, so I thought there must be packages that do this already; everything I found seemed to be device-specific or a bit overkill though.

Yep, I copied straight into /var/lib/alsa.state. I guess I should check that it is being loaded and used. In the end with some experimentation it may have worked (the 40 or so independent variables are just too much...), but as soon as I discovered the heat issue, I immediately stopped trying (I'm actually surprised that whatever it was heating up did not burn out or damage the PCB).

The modules were auto-loaded for me, but only after I had 'modprobed' them at least once -- and I had to load them explicitly at boot to prevent the "dummy sound card" driver from loading. Once they've been loaded successfully once though, then you can even remove them from /etc/modules and they seem to be preferred.

I tried compiling the haswell-audio-dsp branch:

- with all patches (sound didn't work, + got i2c/dmesg errors)

- with all patches except pwm/lpss (sound "worked", no errors, overheating)

- with no patches (sound seemed to work (popped when turning on, but overheated immediately, didn't test properly.)

It occurs to me that the i2c dmesg errors might be a conflict with the synopsis i2c driver that is auto-loading now since I was playing with it earlier. I might go back and try "all patches" with the synopsis driver blacklisted, and see if it makes any difference.
[Windows 8 Development and Hacking] AdamWill:
I know. Like I say, it *used* to be like that for me. I wrote a script that did much what yours did (actually, that's a lie, I ripped it off from a dude on the Arch forums). What I'm saying is I found with recent kernels that's not the case any more: the touchscreen rotates automatically when I do an xrandr.

It's resolution-independent but it's not always device independent, from the scripts I've seen - they tend to have different xinputs that need poking and some seem to need different manipulations from others, some need calibration changes and some don't...

I'm not sure if that'd work. Er, isn't it asound.state ? Anyway, I used 'alsactl load -f'.

Hum, nope, didn't need any of that. Literally all I needed to do was boot a patched kernel with the firmware in place and the device popped up.

Just to note, I'm kind of doing it the other way round: I'm basing off a Fedora Rawhide kernel, as I always have, and generating a patch series from Liam's branch and applying that to the build. I also haven't put the latest changes into my build - I'm only up to "ASoC: Intel: Suspend baytrail ADSP and Free Blocks". The patches since then looked less like "this makes stuff work" and more like "let's poke these bits and see what explodes", so I've been holding off them.
[Windows 8 Development and Hacking] Xentar712:
Has anyone tried formatting their drive and installing a 64 bit version of windows to get a 64 bit bootloader? Is that even possible?
[Windows 8 Development and Hacking] Jhong2:
The UEFI firmware is supplied by Asus and it is 32-bit. Installing any OS won't change that. It will only be able to invoke a 32-bit bootloader.

We can boot the 64-bit linux kernel because it has two entry points (32-bit and 64-bit). If the Windows kernel doesn't provide that, then it won't boot. You may be able to chainload through some sort of wrapper, or find a 32-bit windows botloader that can boot 64-bit; but I guess that the only people who would know how to build it are Microsoft.

---------- Post added at 04:06 AM ---------- Previous post was at 04:01 AM ----------

Yes my bad, asound.state -- I'll try force-loading it.

I was merging the haswell-dsp stuff into mainline, but the result should be the same. Interesting, I'll try merging up to that specific commit then. For all the above I've been using latest mainline (3.14-rc5 now), so I guess it's the same as Rawhide. Like you, my aim is to get to a simple patchset that users can then apply to an Ubuntu kernel.

On an unrelated note, I'm keen to update to bios 226, assuming it fixes some power-related ACPI bugs. However my Windows is gone and there are reports of the built-in "EasyFlash" bricking some people's devices. Has anyone used "EasyFlash" successfully? I'm assuming I just dump files in EFI/Asus/Firmware to use it?
[Windows 8 Development and Hacking] lufasponge:
AdamWill,

Do you think you can post a guide on how to apply the kernel patches? I'm a super beginner when it comes to kernel compiling and I've never applied a patch. Also, I could not figure out how to download the sound firmware.

Thanks,

Jim
[Windows 8 Development and Hacking] AdamWill:
You might want to just use my Fedlet builds if you want to play around with one of these tablets but you're a beginner. Also, I do my builds a slightly different way from how most people do it, I think (I'm most comfortable working with RPM packages, and I'm putting Fedlet out, so I just do all my builds as RPMs; I think others tend to just do direct source tree kernel builds). https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/

I'm intentionally being slightly vague about the firmware just because of the licensing issue, but you might try searching for the filename.
[Windows 8 Development and Hacking] Jhong2:
An update...

I merged Asoc again, together with the latest changes in the wireless tree, and Matthew Flemming's mixed-mode-merged branch. Applied all additional patches _apart_ from gpio & lpss IDs. No problem compiling, booting.

CPU still runs "warm" but not horribly overheating like before. Perhaps it is because I turned the atom optimisations off.

Sound is almost there. Very scratchy and distorted in the right channel after doing some alsamixer fiddling. Mono through the left channel is almost OK....

EFI mixed mode means poweroff works on 64-bit (with the temporary patch -- I see that it will be worked in in a different ACPI patch soon). EFI runtime services are now available and efibootmgr works (yay!).

Would like to get the cpu heating under control though...

Out of interest, Adam, would you mind posting an 'lsmod' so I can see what modules you have loaded?

In the meantime, I'm going to see how some of these coexist with Ubuntu patches.
[Windows 8 Development and Hacking] Jhong2:
Update: I see now the sound stuff is going upstream quickly :)

It's in broonie/sound - Intel with some recent fixes, then subsequently on to broonie/sound - For-Next so I guess it will be in 3.15

Going to try merging in the Intel branch.
[Windows 8 Development and Hacking] Jhong2:
I put up a draft (ugly) walkthrough of how to get everything set up, including sound, wifi, etc... at least, as far as I've got.

http://www.jfwhome.com/2014/03/07/perfect-ubuntu-or-other-linux-on-the-asus-transformer-book-t100/

Let me know if there's anything that I've remembered wrongly. (I disclaim all responsibility if you brick your laptop).
[Windows 8 Development and Hacking] Jhong2:
I just updated the walkthrough with newer instructions and downloads -- these should work better (there was so much trial and error on my side, I think I simplified them too much).

Please let me know if they still don't work.

Also, my sound appears to be permanently distorted now, even in Windows. I thnk this was from playing with all the options at high volume when the driver was less developed. Either way, reinstalling the windows driver and linux firmware doesnt seem to have helped, so it may be hardware damage. Please be careful....
[Windows 8 Development and Hacking] JoinTheRealms:
Yeah these speakers are fragile, on asus tf700t tablet (running ubuntu) i blew the speaker from just 80% volume but wrong alsa settings. Probably best to keep sound volume below 50% until it's a bit more stable.
[Windows 8 Development and Hacking] Jhong2:
I'm still hoping it's a device enumerated in alsamixer that isn't in my asound.state. Hopefully someone with working sound can dump their state and I'll try to import from that. If not, I'll have to get it fixed :(

In the blog post I added instructions for getting the SD card reader to work too :) Thanks to akira
[Windows 8 Development and Hacking] AdamWill:
the stuff that's been pushed by broonie (Mark Brown) is not the complete series, I don't think. It doesn't have the rt286 codec driver, for instance. There's clearly a plan for upstream merging, but I don't *think* the broonie tree would be sufficient. IMBW, though. I think Liam has rebased https://git.kernel.org/cgit/linux/kernel/git/lrg/asoc.git/log/?h=intel/haswell-audio-dsp on top of the current broonie stuff, in fact, but I may be reading it wrong.

---------- Post added at 06:42 PM ---------- Previous post was at 06:37 PM ----------

the asound.state in my git repo was sent to me direct from one of the Intel folks and was named after the t100, so I'm pretty sure that's what it's meant for. strange if it's not working for you.
[Windows 8 Development and Hacking] Jhong2:
The broonie / intel branch merges well (and sound works will with it). I looked through the commits and it seems to capture everything relevant. With that merged onto 3.14-rc6, sound isn't too bad.

The channels aren't equal (left channel very faint and distorted for me now), but I think it could have been my fault from messing with too many of the alsamixer settings before applying the state. Perhaps some of those devices aren't covered in the asound.state file. If that's the case, I'm hoping someone else will find sound works perfectly for them, and then can save their alsa state for me to apply.

In other news, the new gpiolib-acpi patches are up, and I've managed to apply them. Compiling now. I'm hoping this will allow us to get working tablet buttons :)
[Windows 8 Development and Hacking] AdamWill:
Yeah, we're kinda drowning in patches right now, I'm having trouble keeping them all straight. This is a good problem to have, of course :)

I'm currently doing a build with the non-quirk version of the shutdown/reboot fixes - see https://bugzilla.kernel.org/show_bug.cgi?id=70931 , patches from c#11, c#13 and c#15 there. I'm also throwing the latest sound stuff at it: I've pulled in all the changes from https://git.kernel.org/cgit/linux/kernel/git/lrg/asoc.git/log/?h=intel/test that are after the stuff in broonie's tree. I think this will either destroy my tablet or make sound work across suspend/resume. We'll see. :P

Apparently there's an internal tree at Intel with some fixes for battery monitoring. Hope that makes it outside their firewall soon. Got another Intel guy mailing me for help with building live images.

you're referring to Mika's patch series starting at https://patchwork.kernel.org/patch/3803001/ as 'the new gpiolib-acpi patches', right? Are you expecting just those patches alone will make buttons work, or does there need to be a driver written on top of them?