HP (Re-)Announces a 14" Android Laptop 121
PC Mag reports that an upcoming laptop from HP (one that was prematurely announced in April, and now official) has decent-to-good specs — under 4 pounds, battery life more than 8 hours, Tegra processor, and a 1928x1080 touch screen — but an unusual operating system, at least for a laptop. The SlateBook 14 will run Android, rather than Windows (or ChromeOS, for that matter), which helps keep it relatively cheap, at $400. According to the article, Android is "a lot cheaper for HP to implement in a laptop; ChromeOS, in contrast, comes with more stringent system requirements that would cost HP a bit more." Ars Technica's mention in April includes a screenshot taken from a video (note: video itself appears to be disabled) which shows the keyboard layout and which reveals some Android-specific changes. Update: 06/01 19:23 GMT by T : Here's an alternative link to the promotional video.
There *are* additional hardware costs (Score:5, Informative)
ChromeOS, in contrast, comes with more stringent system requirements that would cost HP a bit more.
In other words, this thing is going to be really slow if you try to use it for serious work. Why? Because HP is cheap and doesn't want to shell out for decent components. That and/or they like their locked down bootloader.
There are additional hardware requirements on a ChromeBook:
o No COTS keyboard (ChromeOS requires a custom keyboard)
o Work required on the TP bus input lines and power to deal with wake-from-trackpad
o EC modifications for wake-from-trackpad, including some tricky PS/2 state machine work
o EC modifications including additional GPIO pins and a couple of resisters and capacitors, if the parts PS/2 bus is on the C3 power rail (i.e. there's some issues with C-state transitions if the PS/2 or I2C bus for the TP are powered down in sleep state)
o EC state machine modifications for prioritization of traffic from the keyboard matrix "pretend" i8051/i8042 parts to provide a muxed PS/2 bus with e.g. a Synaptics PS/2 trackpad; specifically, HP's EC parts tend to drop keystrokes under certain conditions, and the typical solution to the hardware problem in the EC firmware is to stop TP input for a period of time following keyboard input - same solution used by Toshiba - and it means you can't use both keyboard and mouse in games, unless you use an external mouse in place of the TP
o If the TP remains powered in sleep state, for wake-from sleep, as part of the C1 rail, then there is an associated batter cost, even if you chat with it to clock it way down; this implies either clam-shell it shut to turn off the TP, -OR- a bigger battery to achieve the same battery life. FWIW, that also means that the C1 line to the TP power has to be gated by *another* GPIO line from the EC
o Wake-from-trackpad also has some implications for BIOS default state on initial boot or wake-from-sleep (C1->C3 state transition); most BIOS are broken in this regard (hint: try holding the TP click down when booting some time, and see how long it takes).
o A TPM to implement the "trusted boot" in a way that it can't be worked around in software (Microsoft Trusted Boot can work without TPM hardware, but can be worked around in software if you are diligent).
o There's a known defect in I2C bus sharing on some TPMs when doing back-to-back transactions, which means that they tend to demand their own I2C bus.
o The last HP ChromeBook was withdrawn from the market due to power supply overheating problem (this is public information), which had to do with the charging circuit and the power draw in sleep state, while leaving certain peripherals powered on that aren't on in a normal Windows sleep state.
o CoreBoot and u-boot for the BIOS (technically, you could flash both and select which one in a setup screen, but that means higher NVRAM costs for the storage of the BIOS)
So... a lot of software work in a sensitive system area, a potentially larger battery, a potentially higher per unit cost for the keyboard, a potentially higher per unit cost for the TP, a modified BIOS and other BIOS costs, and a TPM and maybe an extra I2C line, plus a potential mod to the charging circuit.
Full disclosure: I did the EC state machine work and worked with Synaptics and Samsung on the EC and hardware modifications for a number of TP and keyboard issues, as well as other of the above issues, for ChromeBooks from Samsung, Acer, and other companies while part of the ChromeOS team at Google. Basically, they'd need to make my recommended list of partner modifications to their hardware and firmware in order to build a successful ChromeBook.
I suspect that they will find the android OS not very satisfactory as well, but with a standard keyboard and other features, they can use COTS parts for most things, and pop the rip cord and switch to Windows on the thing if they absolutely had to do so.