Xfast is a reimaging of the kdrive ddx and mainloop for a KMS and modern embedded world

[Xfast means faster startup in this version, other embedded optimizations should be made in a way that can be shared with the full Xorg codebase]

Important Goals

1 second configuration
2 seconds to a screen image
sane CHVT semantics, new drivers should not care about enter/exit
simplified configuration system based on randr properties, not xorg.conf and autoconfiguration
id (PCI/platform_bus/etc) based probing is preferrable to driver based
support for preconfigured modes without resorting to VESA mode numbers
support for non traditional framebuffer targets, such as webOS and android as well as rootless modes
unification of dummy, vfb, nest, ephr and other backends

* Driver architecture *
* inspired by linux platform bus design
* drivers have init and probe but register themselves, not through a fixed abi
* drivers can be built in or OS modules (.so)

fbconfig - represents a pixel format and layout independent of framebuffer implementation

- the basis for modesetting, the fbconfig for the root window or associated outputs is the mode, this is similar to the proposed (merged?) ScreenInfoRec/ScreenRec improvements
- does not replace cfb/fb in Xorg but uses existing infrastructure whereever possible

vmtd - video memory technology driver - an abstraction of the access method for the actual framebuffer

- the essential abstraction here is open/mmap which allows for sophisticated binding such as accomplished in GEM, but also allows for simplification of dummy backends and shadow framebuffers

- a single vmtd implementation should be able to provide for multiple usage scenarios, mmap is used for fbdev as well as (kernel) vfb; malloc vmtd is used for shadow implmentations, dummy, Xephry-like and similar; dri2/gem/gles vmtd's provide for more complex usage involving bound (memory mapped) pixmaps

accel - provides extended acceleration functions for vmtd driver, as well serving as a basis for existing (and specific) acceleration frameworks such as EXA/UXA 
- allows related _ops structures to be requested for a fbconfig/vmtd combination(essentially private Rec structures in Xorg driver model)

[this portion is preliminary]

* Startup Proceedure *

* intended to be started directly from init, not from display manager
* (future) trans is not bound to a display/screen until dbus signal from dm
* (future) vt binding is also accomplished through dbus
* does not parse complex configuration file or attempt detection proceedure
* device/output properties (Xrandr 1.2 like) are serialized in an ascii or binary format and loaded by the server binary or external utility (extended xrandr)

* initial configuration and framebuffer is determined from the startup configuration (randrconf), or is passed on the command line (-screen)
this initial configuration can be changed (reallocated) and additional screens (heads) can be added or removed (hotplug) later
* all input is hotplug and managed through an extended xinput utility, compatibility with kdrive maybe maintained for initial devices
* there is no stipple and the screen is not cleared on startup, however, framebuffer can be switched from linear to tiled with LUT-based flicker-free blanking
* PM/DPMS is simplified, the goal being device specific PM and not generic workarounds

* Initial Goals *

* fbdev and intel support
* mmap and malloc vmtd (dummy)
* fbdev is preconfigured or fixed, additional devices will be mutable through xrandr [as the target is embedded devices with fixed tft there is no need for fbdev modesetting, external devices will still be supported fully]
* full rotation support, shadow vmtd or shadow+mmap vmtd
* intel configuration is kms only, preconfigured setup through extended randr properties (to be proposed for standardization in Xorg)
* 2 seconds to usable from upstart on intel 965 kms in Ubuntu M, goals on arm to be deterimined through baseline testing
[ intel support will be accomplished through existing xf86 driver module]
[ dri2 vmtd will eventually allow for xfast native intel kms, not initial goal]

* Intermediate Goals *

* kbuild like build system for /xfast/, all modules can be built-in or .so
* binding to existing surfaces for Xnest, Xephyr, android and webOS modes
* rootless support for other display servers, such as android sf and webOS rpc
* support for building Xfast as a library (libxfast) that can load modules or have them builtin, can be JNI invoked on android or compiled as a game on webOS
* * library loads required modules and randrconf config files