OpenConsole

This page details a concept for an Open Console Platform. No software has been written for this project, nor has any hardware been built.

The main idea is to leverage current and upcoming Linux Desktop standards to define a uniform platform.

Default solution : X.org with a custom window manager

 * Drops "single app"-pretense.
 * Multitasks fullscreen applications.
 * Interactions via X or D-Bus.
 * With properly X-friendly software, taskswitching should be a breeze. no more "damn, it crashed when I alt-tabbed"-syndrome.  Modern consoles already do this almost ok.

As for implementation, window managers have hooks for communications with applications. Check your favorite toolkit for options. SDL has several WM functions and WM changes are reported via events.

Backup solution : XBMC on Linux as basis

 * We get all advantages of modern Linux kernel.
 * Good mature HTPC/console frontend.
 * Full of badly grown stuffs. (due to convoluted multiplatform support)

Pimp-me-out solution : X.org with custom compositing window manager

 * Advantages of default solution, with additional compositing goodies.
 * Puts additional burden on resources, but this might grow insignificant in following years.

Open APIs

 * D-Bus for component communication.
 * OpenGL for graphics, based on Xorg or Wayland.
 * PulseAudio and/or OpenAL for audio
 * Pulse is a catch-all-do-all kind of solution that has some kinks to sort out.
 * Direct audio is a temporary solution, but one abstractible API is a must.
 * I/O API is still unresolved..
 * XI2, MPX, all welcome
 * PS3/Xbox360/Wiimotes all use Bluetooth, so Bluez is vital
 * LIRC for generic mediacenter work.
 * Needs one API to fixate on, though.
 * XMPP for chatting and presence.
 * PhysicsFS for program data storage?
 * MetaTracker for media indexing?
 * Mediaplayer that leverages tracker + gstreamer?
 * ProjectM for visualizations
 * APIs SHOULD allow independent implementation.

Integration

 * All software must follow certain rules, for example for notifications and menus to work. These must be laid down and tested.
 * Event notification over D-Bus, mechanisms exist already.
 * Task launching over D-Bus, mechanisms exist already.
 * Media sharing over UPNP-AV/DLNA. Several other devices support this also.  Both directions simultaneously, preferably.
 * Memory requirements needs an convention:
 * Some programs eat as much RAM as they want / can.
 * Some know what exactly they need.
 * Need API (via D-Bus?) to tell hungry programs to back off of genuine needs (for example, shutdown torrents when there's a huge game starting.)
 * Swapping by default is out of the question. it makes "clean virtual memory" but is the single thing that makes every PC a slow piece of sh*t.
 * Preferably use mmaps; if memory is running low, pages can be dropped out and retrieved when accessed. includes uncertain latencies, so mainly for background tasks.
 * Other requirements
 * No-one likes a slow or lagging game.
 * Difficult to pin-point exact requirements for playability.
 * RAM and disk space requirements are easier.
 * Capabilities are a good too, but they change for example with driver versions..

Hardware insensitivity

 * APIs abstract hardware, there is no any other way.
 * Hardware capabilities have to be tiered by year, or something. Integrated graphics coming few years later than discrete cards.
 * Support all I/O devices:
 * Wiimotes, Sixaxis, Dualshocks, and so on.
 * Keyboards and mice also, but shouldn't be depended on.
 * LIRC, J2ME, bluetooth.

Evolution support

 * Purpose: Guarantee that old software doesn't stop working,
 * Instead of fixing ABIs, make "releases" and make publishers provide builders for releases.
 * When new release is made, publishers are bound to either release sources so others can build or build by themselves.
 * If rebuilding is too much a chore, it can be outsourced. Platform is open and ABI changes rarely (hopefully) require lot of modifications.
 * Even if source is released, it can be under dedicated license to allow only use with certain scenario. leaks intellectual propery, though.
 * Even if source is released, game data is not released.
 * Evolution support SHOULD allow to switch processor architecture.

Use cases

 * Living-room, games console, web browser, communications.
 * HTPC, DVD/BluRay, torrents (via RSS feeds also), DVB.
 * Sandboxing, run "console platform" as a task on a powerful desktop. Switchable between full-screen "full experience", windowed "sideline experience" or taskbar-icon "background experience".
 * Event management, limited access, tournament rules, stock competitions.