Author
Topic: PadOrbiter 2.0 (Read 2513 times)

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.

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.

That's exactly where I see things going.

Quote

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.

Again, makes total sense. These little touch-screen devices have way too much horsepower now to be used as glorified remote controls.

At the risk of going OT, the only small issue I see is with Qt/Clutter... MeeGo is less of a concern as the underlying OS probably isn't a big deal. It's not clear to me what path development of these libraries will take going forward now that Nokia is in bed with MS for their phones and Qt (commercial) is being forked to Digia. I know, the 'official' line is that these are test-beds for UI design at Nokia, but I cannot imagine there's going to be much paid development on the open source side. That being said, I'm not sure if there are any real alternatives.

Overall, this looks great. Now if only I could get some of those Joggler/openpeak devices in Canada.

I ported more of the system over to MeeGo, mostly needed Boot Scripts to spawn child devices etc.

Then I ported over the Photo Screen Saver.

Once this was done, I created a new Joggler template. This is similar to a Media Director template, in that it has similar device data, but is in the Mobile Internet Devices category. I then modified the Onscreen Orbiter template to be allowed into the new category, and added children devices for the onscreen orbiter, photo screen saver and app server to the Joggler template.

I then added necessary bits to get NFS, SMB, and AutoFS onto the meego image.

This provided the necessary mechanisms to run the on-screen orbiter, and as you can see here, it is now running the Photo Screen Saver in "Animated" OpenGL mode, just fine, blanking and unblanking as needed:

Thom,this is great stuff!What do i need to add to a N900 ks file to get this working for testing? I've got my N900 set up with uboot and a recent meego image, not the fastest in the world but can test away.