First off, let me make clear that this post is written purely from a developer perspective. As a user, I love the Pixel C despite its shortcomings, use it all the time (even if mostly just for web browsing, at the moment at least).
But as an Android developer (both OS and apps), the device makes it really hard to love it.
The Pixel C is, hardware-wise, and firmware-wise, a ChromeOS device. Not maybe, not used to be, but fact. It starts with using coreboot+depthcharge as the bootloader that only on the very top of everything boots Android, and goes over to the ChromeOS EC (Embedded Controller).
And it is this embedded controller, combined with the Tegra X1 chipset, that I have the most gripes with.
What is the EC? The EC is, somewhat contrary to its naming, not a "dumb" controller, but actually a fully-fledged system inside the Pixel C. It has its own CPU (a Cortex A7) and its own operating system (which is much much smaller than the OS the device actually runs, in this case Android).
The EC does basic things like partially controlling the boot sequence, and having direct control over auxilliary hardware like the device's sensors. That means that the OS has to rely on communication with the EC to make use of the sensors, and that is exactly how it is implemented in the Pixel C.
So what is my trouble now, finally, you might be wondering at this point.
Maybe some of you have noticed that over the course of the past weeks I tried to develop Double Tap to Wake for the Pixel C.
My initial approach was the same as on other devices: make sure the touchscreen still receives power and handles events, even if the screen is turned off. Then listen for gestures (like a double tap), and if a gesture is recognized, activate the device.
This didn't work out, because the Tegra X1 chipset is extremely strict when it comes to power management. Similar to the EC, you don't have direct access to the PMU (Power Management Unit), but rather need to go through the Tegra's PMC (Power Management Control).
Basically, while I've succeeded in keeping the touch screen awake after the device is suspended, it amounts to nothing since the Tegra can only be awoken by specific events when in LP0 state (Low Power 0). These events are already pre-determined by the firmware and can be hooked into through the DTB (Device Tree Blob) which contains hooks and information for the various kernel subsystems.
It does so for the PMC as well, but since the events are already hardcoded, there is no way to wake the device from suspend on a touchscreen event in a useful way, or at least not with the Linux kernel 3.18 used in the Pixel C.
So double tap to wake works, until the system goes into LP0 suspend, which happens very quickly after you turn off the screen if everything works well (no wakelocks or wake interrupts).
I gave up on that, and decided to implement double tap to wake through the mechanism the Pixel C already makes use of, as we all know: if you double tap on the back, OR the front, the Lightbar will show you the battery level.
It turns out that this feature is controlled by the EC, but since there is only access to the sensors via the EC, it is the EC and only the EC that can propagate the event to the host system, and possibly wake it up from suspend in case of a double tap.
I had, again, everything working: I've created a small framework overlay APK so you can enable wake settings in Android Settings, modified power.dragon and sensors.dragon (two Android modules that interact with various subsystems in order to control the devices state, and to read sensors, respectively).
Double Tap to Wake using the sensor worked!
Until... the system goes into LP0 again. It was very frustrating, and became even more so once I read the EC source code and realized that the event simply isn't hooked up into the host system on purpose, in order to enable the Lightbar tap functionality.
Now, I'm not saying that this all is deliberately created in such a way as to make development hard for the device. But none the less, it is.
In order to make this work (I don't see much of a chance for DT2W using the screen), I will have to compile my own modified EC firmware, flash it onto the Pixel C, hoping I didn't make some grave mistake that will blow my Pixel C up in smoke, something that I wouldn't have to do on a usual Android device.
As you can see, all this is becoming a little convoluted, hairy, and dangerous. It's akin to getting the mostly undocumented sourcecode for your Laptop's EFI BIOS, compiling it yourself, and then flashing it into your Laptop, hoping you compiled from the right version of the source code, you did everything right while flashing the new firmware, etc.
The next problem is whether this, flashing your own EC firmware, is even possible at all things given. The Pixel C has, like all ChromeOS devices (I'm staying with my point here), a Write-Protect mechanism. In the Pixel's case it's not a screw, but it is the front camera flex.
Only with the Write-Protect disabled you have full access to the device on a similar level which you would have on a normal Android device after unlocking the bootloader. But, in order to access it on the Pixel, you need to take off the screen. You'd have to heat-gun the front until the adhesive comes off, pry off the screen with bezel, disable the Write-Protect, and then somehow reassemble the Pixel.
I bet at this point many will agree that it's all a bit extreme just in order to get a feature like Double Tap to Wake working.
Still, I will be trying. But not today. And probably not tomorrow.
Over and out.
But as an Android developer (both OS and apps), the device makes it really hard to love it.
The Pixel C is, hardware-wise, and firmware-wise, a ChromeOS device. Not maybe, not used to be, but fact. It starts with using coreboot+depthcharge as the bootloader that only on the very top of everything boots Android, and goes over to the ChromeOS EC (Embedded Controller).
And it is this embedded controller, combined with the Tegra X1 chipset, that I have the most gripes with.
What is the EC? The EC is, somewhat contrary to its naming, not a "dumb" controller, but actually a fully-fledged system inside the Pixel C. It has its own CPU (a Cortex A7) and its own operating system (which is much much smaller than the OS the device actually runs, in this case Android).
The EC does basic things like partially controlling the boot sequence, and having direct control over auxilliary hardware like the device's sensors. That means that the OS has to rely on communication with the EC to make use of the sensors, and that is exactly how it is implemented in the Pixel C.
So what is my trouble now, finally, you might be wondering at this point.
Maybe some of you have noticed that over the course of the past weeks I tried to develop Double Tap to Wake for the Pixel C.
My initial approach was the same as on other devices: make sure the touchscreen still receives power and handles events, even if the screen is turned off. Then listen for gestures (like a double tap), and if a gesture is recognized, activate the device.
This didn't work out, because the Tegra X1 chipset is extremely strict when it comes to power management. Similar to the EC, you don't have direct access to the PMU (Power Management Unit), but rather need to go through the Tegra's PMC (Power Management Control).
Basically, while I've succeeded in keeping the touch screen awake after the device is suspended, it amounts to nothing since the Tegra can only be awoken by specific events when in LP0 state (Low Power 0). These events are already pre-determined by the firmware and can be hooked into through the DTB (Device Tree Blob) which contains hooks and information for the various kernel subsystems.
It does so for the PMC as well, but since the events are already hardcoded, there is no way to wake the device from suspend on a touchscreen event in a useful way, or at least not with the Linux kernel 3.18 used in the Pixel C.
So double tap to wake works, until the system goes into LP0 suspend, which happens very quickly after you turn off the screen if everything works well (no wakelocks or wake interrupts).
I gave up on that, and decided to implement double tap to wake through the mechanism the Pixel C already makes use of, as we all know: if you double tap on the back, OR the front, the Lightbar will show you the battery level.
It turns out that this feature is controlled by the EC, but since there is only access to the sensors via the EC, it is the EC and only the EC that can propagate the event to the host system, and possibly wake it up from suspend in case of a double tap.
I had, again, everything working: I've created a small framework overlay APK so you can enable wake settings in Android Settings, modified power.dragon and sensors.dragon (two Android modules that interact with various subsystems in order to control the devices state, and to read sensors, respectively).
Double Tap to Wake using the sensor worked!
Until... the system goes into LP0 again. It was very frustrating, and became even more so once I read the EC source code and realized that the event simply isn't hooked up into the host system on purpose, in order to enable the Lightbar tap functionality.
Now, I'm not saying that this all is deliberately created in such a way as to make development hard for the device. But none the less, it is.
In order to make this work (I don't see much of a chance for DT2W using the screen), I will have to compile my own modified EC firmware, flash it onto the Pixel C, hoping I didn't make some grave mistake that will blow my Pixel C up in smoke, something that I wouldn't have to do on a usual Android device.
As you can see, all this is becoming a little convoluted, hairy, and dangerous. It's akin to getting the mostly undocumented sourcecode for your Laptop's EFI BIOS, compiling it yourself, and then flashing it into your Laptop, hoping you compiled from the right version of the source code, you did everything right while flashing the new firmware, etc.
The next problem is whether this, flashing your own EC firmware, is even possible at all things given. The Pixel C has, like all ChromeOS devices (I'm staying with my point here), a Write-Protect mechanism. In the Pixel's case it's not a screw, but it is the front camera flex.
Only with the Write-Protect disabled you have full access to the device on a similar level which you would have on a normal Android device after unlocking the bootloader. But, in order to access it on the Pixel, you need to take off the screen. You'd have to heat-gun the front until the adhesive comes off, pry off the screen with bezel, disable the Write-Protect, and then somehow reassemble the Pixel.
I bet at this point many will agree that it's all a bit extreme just in order to get a feature like Double Tap to Wake working.
Still, I will be trying. But not today. And probably not tomorrow.
Over and out.
Last edited:
