Thursday, January 31, 2013

My Kindle Fire(s)

My passion for the Kindle Fire started shortly after developing a plan for my project in mid 2011. Every now and then I'll drop a few more details about that plan here, too, but now I want to tell you more about how I got my 2 Kindle Fire(s).

Ever since the Kindle Fire came out in November 2011 I wanted to have it. My plan needed a powerful dual-core embedded platform with a good and bright display and a capacitive touchscreen. The Kindle Fire had a lot, not more than I needed. Actually less, but it's good at what it offers and that counts most for me. The rest I could hack and mod myself, learn something by doing so and have some fun at the same time. I had known the Pandaboard and Blaze from Texas Instruments before, so I was familar and happy with that basic TI platform.

At that time my passion had almost gone with the Blackberry Playbook already. But that was not as open as the Kindle Fire. And it was soooo expensive. Blackberry clearly missed the bus... train... what do I say? ...rocket to enter the tablet market! And very much because they got the price wrong. The hardware was very right and I would still prefer it over the Kindle Fire. But the Fire is 1) way cheaper and 2) (more) open!

Ok, talking about pure hardware-mods here, you could argue now: simply ignore that locked Blackberry bootloader and set the OMAP4 SYS_BOOT bits right and you'll get around it. That's true! But then what about the operating system? 3) Amazon releases at least the source code. Well, ...releases! They obviously don't care about us hackers and developers (who should we blame to not include a proper kernel-.config?).

The summary of this: the Kindle Fire is just open enough to be an attractive hacking platform, while the Blackberry Playbook is just closed enough not to be! So, finally my passion went with the Kindle Fire. The absolute right timing for my plan! Amazon, how did you know that I would need...?

Honestly, the story is a bit different and I need to take another short detour. I was a bit more impatient, so in September 2011 I started on my plan with a Huawei Slim S7. What a difference compared to the Kindle Fire lateron: 800MHz single core, 800x480 display, *not* an IPS panel (colors? yes, a lot, but you've no control over them... :-) ), only 4G ROM (what can you do with even less than 8G?), but GPS, WLAN, BT, 3G and the whole bunch of nice toy sensors. Actually not even worth starting to talk about hardware-mods, because it had everything (except a Geiger-Müller counter maybe). I played around with it for a while to learn how to hack Android systems. And hacking here means: get rid of Android, install your own Linux from scratch! A good experience. I learned that I had missed that for some years.

Finally it got 2012 and then March and I had the chance to travel to the US for some business reason. I ordered a Kindle Fire ($199=€150) and learned that Amazon even delivers to hotels (so you don't need to be a permanent resident). Back home I hacked my fresh Fire in the same way as that Huawei Slim S7 and I was immediately happy with everything. That was my Kindle Fire #1.

You guess it already: my plan needs a second Kindle Fire! And that I bought on ebay. A used one, but rarely used. Actually not much more than my fresh new one from March. So, my Kindle Fire #2 was there, crafted back in January.

Wednesday, January 30, 2013

The Ambient Light Sensor

Ok, it's a while ago that I posted something here. What did happen? Actually, I was fairly busy doing some good research on the Kindle Fire's hard- and software side and I'll post the summary of that analysis here over the next couple of weeks.

The topic I would like to start with is Kindle Fire's ambient light sensor. Oh, you don't have any on your Kindle Fire? Maybe you never noticed it as Amazon turned it off with the first software update for some unknown reason (most likely, because it acted too nervously). Some users actually did notice, unfortunately only after the software update had removed the option on the Android GUI, but then could not undo the update. However, in my today's blog entry we're going to activate that sensor again.

So, where is that thing? Here's a not-so-good close shot of it:

The ambient light sensor is behind the touchscreen glass and measures the intensity of surrounding light through a tiny hole. This hole is located in the upper left corner and some may have misjudged this to be a camera.

What else except for a Kindle Fire do we need to try it out? Basically, Amazon's released source code of the kernel or any other kernel source adapted to the Kindle Fire is enough (like the 3.0 series that is being maintained by Hashcode on xda-developers).

The sensor itself is a SenseTek STK22x7 and the kernel driver is in reasonable, but not very good shape and comes with those kernel sources. As the sensor is attached to the mainboard via one of OMAP4's I²C busses, it's located in $KERNEL_SRC/drivers/i2c/SenseTek. Compilation can easily be enabled via make config/menuconfig (in the submenu of I²C drivers), but still it won't detect the sensor simply because prior to releasing the kernel sources Amazon's developers seem to have disabled some of the registering code in the driver.

As all the basic code is there (stk_i2c_als22x7_kcx.c), you only need to change the last 2 occurrences of #if 0 in that file to #if 1 which re-enables that registering code. I myself also changed a few other things:
  1. removed probing for the 3rd I²C address 0x38. There's simply nothing there to probe for. I assume there's more than 1 flavour of the STK22x7 with additional features like a proximity sensor or IRQ-based triggers
  2. changed the STK22X7 config variables to tristate in Kconfig to be able to compile the driver as a module for further development (worked out of the box except for cleanly unloading the module)
I'm not sure why Amazon (or SenseTek) did add another hurdle, but this is still not enough to see it running. So far the sensor will register as input device already. For me it's /dev/input/event3, but it may be different for others as I'm already using a modified Linux kernel. There's yet nothing you can read from that device, as the driver still needs to be enabled.

This needs to be done via sysfs. The sysfs entries of the driver register at /sys/devices/platform/stk-oss and via

echo 1 > /sys/devices/platform/stk-oss/als_enable

you can enable lux measurements. Simply enable it, start continuous probing via

watch -n 1 cat /sys/devices/platform/stk-oss/lux

and cast different levels of light at the sensor from e.g. a torch light or a lighter and you will see how the values that come back from that device file will change.

That's it... :-)

The driver code itself can definitely use some cleanups as suspend doesn't work very well yet and it's still full of debug code. For Android you may need some extra work as this just enables the kernel-level driver.