After working on it off and on for the last year, I have prepared the first version of PadOrbiter 2.
What's different this time?
Primarily, PadOrbiter was a distribution that was hand crafted specifically for a single device, with no allowance for different hardware. It was designed to run on a specific run of WebDT 366 tablets that found their way onto the market in the latter half of 2008. They had very limited amounts of memory, and very constrained resources, so I had to be extremely creative with what I put on the devices.
Times have changed.
Now, we are amidst ever more capable portable devices, which contain much faster processors, more RAM, and more storage space than ever before. These devices also contain video accelleration cores as part of their system design to aid in the playback of high-definition content. These devices take on many forms, but we are starting to see a mass commoditisation across some common axes:
* Intel Based
- Atom Z or N series CPU
- GMA3150, GMA500, GMA600 GPU
* ARM Based
- Cortex A8/A9 based CPU, such as OMAP3/OMAP4 or NVIDIA Tegra
- SGX5535 GPU and TI Video accelleration (found in the N900), or NVIDIA Tegra
More designs are on the way, so the question becomes how do we handle these devices effectively?While the Proxy Orbiter based designs have allowed developers to quickly get existing orbiter designs onto existing iOS and Android platforms, I see this as a stop-gap. This goes against one of the primary goals of LinuxMCE, to unify virtually every single piece of technology in the home.
To do this properly, will take a two pronged approach:
* For native systems, such as Android and IOS, Native DCE implementations need to be ported (in the case of Android), and/or built (in the case of iOS)
* For devices that will just run Orbiter, a version of the Orbiter based on MeeGo technologies can be used,
This thread addresses this particular instance. Why? Isn't Orbiter just a glorified touch menu?Yes, but since these devices have far more advanced video playback and GPU processing features, we can actually make every portable device not only a control point, but also a media end point.
Also, consider PlutoStorageDevices. Once this is running on PadOrbiter v2, the host device will suddenly be able to share USB storage devices with the rest of the house, transparently. Imagine being able to convieniently be able to plug in a friend's portable USB disk, onto a nearby Joggler. It is not only certainly possible, but it will be done.
PadOrbiter v2 also contains in addition to the existing Orbiter code, libraries for Qt Quick/QML and Clutter, which I have been investigating to build a new Orbiter on top of. So the entire stack is FORWARD COMPATIBLE with not only the newer, less expensive hardware coming out, but it also provides the software platform bits needed to carry the Orbiter idea forward to bring in new ideas. Add to this the additional capabilities of media playback and control, and advanced features like pluto storage device points, and you have a solution you can't get anywhere else.
For now, I am placing kickstart files in the following place
http://svn.linuxmce.org/svn/branches/LinuxMCE-0810/src/MeeGoThese can be built using meego-image-creator, which can be found by your friendly google.
Joggler images must be built with -f raw
and for everything else I typically use -f livecd
I will release images later, as I still am refining some bits.
p.s. Oh, there's a video of it running on the Joggler, here:
http://www.youtube.com/watch?v=ZRKkqxWcytIEnjoy,
-Thom
