Decrease X.org XFree86 server footprint - Revision history

Tim Bird: /* Comments */ add to category

2009-12-02T19:07:22Z

‎Comments: add to category

Tim Bird: /* Comments */ fix

 typo

2009-12-02T00:15:00Z

‎Comments: fix <pre> typo

Tim Bird: /* Related work */

2009-12-01T23:31:53Z

‎Related work

Tim Bird: add page

2009-12-01T23:25:08Z

add page

New page

; Summary : Decrease X.org XFree86 server footprint

; Proposer : Mikhail Gusarov

== Description ==
There are two servers with overlapping functionality in
X.org X server source tree, namely Kdrive and XFree86.

Kdrive is small X server developed for embedded needs and then
integrated into X.org server source tree. It is abandoned upstream and
does not receive any attention except of build fixes.

XFree86 is actively developed, features DRI and EXA acceleration, as
well as recent versions of XRandR extension. It would be nice to have
all its functionality available for embedded development.

The only one major obstacle of adopting XFree86 for embedded needs is
large memory footprint. While Kdrive Xfbdev features ~1.75MB RSS,
XFree86 is nearly 20MB.

Proposal is to make XFree86 leaner by both making more configuration
options (e.g. disabling support for AGP or PCI videocards for devices
without AGP/PCI bus), and auditing memory usage, so it can be used for
embedded systems as well.

The benefits are clear: single codebase will reduce duplication of
efforts, make development of specific hardware-accelerated drivers for
embedded devices easier and bring recent X11 enhancements into embedded
devices.

== Related work ==
* X server code: http://cgit.freedesktop.org/xorg/xserver/
* Tiago Vignatti blog post reflecting XDC discussion about XFree86 and embedded http://vignatti.wordpress.com/2009/11/08/my-dear-diary-some-not-so-old-memories/

; Scope : This should take approximately 3 months of development and test effort.

← Older revision		Revision as of 19:07, 2 December 2009
Line 77:		Line 77:
	exposes programmable pixel shaders using GL-ES2.0 so this is not an		exposes programmable pixel shaders using GL-ES2.0 so this is not an
	issue... and people want more than just alpha-channel OSDs these days		issue... and people want more than just alpha-channel OSDs these days
		+
		+	[[Category:Project proposals]]

@@ Line 69: / Line 69: @@
   are usually short on time, they just hack a simple DirectFB driver and
   do their apps using it.
-−
   >> At Sony we're not shipping a lot of (any?) products with X, but if
   >> the footprint problem was solved maybe we would consider it.
-  I guess everything non-TV is every feasible. For TVs, it would need
+  I guess everything non-TV is very feasible. For TVs, it would need
   more work... or new hardware that is not so "fixed". New hardware
   exposes programmable pixel shaders using GL-ES2.0 so this is not an
   issue... and people want more than just alpha-channel OSDs these days

← Older revision		Revision as of 23:31, 1 December 2009
Line 34:		Line 34:

	; Scope : This should take approximately 3 months of development and test effort.		; Scope : This should take approximately 3 months of development and test effort.
		+
		+	== Comments ==
		+	Tim Bird writes:
		+	Is X widely used, or are other graphics systems (like DirectFB, for
		+	example) used?
		+
		+	At Sony we're not shipping a lot of (any?) products with X, but if
		+	the footprint problem was solved maybe we would consider it.
		+
		+	Mike Frysinger writes:
		+	[X] would be more widely used if the footprint wasn't so awful. most
		+	people will take simple convenience over extended software
		+	development, and the closer you match the desktop system, the better.
		+	I've seen people leverage nano-x/microwindows for this reason as it
		+	provides nxlib -- X11 glue to its display server.
		+
		+	Mikhail Gusarov writes:
		+	OpenMoko and Nokia N770/800/810/900 tablets use various X servers (Xglamo,
		+	Kdrive and now XFree86).
		+
		+	Various e-Book readers I looked at use Kdrive, Nano-X (which is X-like,
		+	but not quite X) and plain framebuffer (not DirectFB).
		+
		+	Wolfgang Denk writes:
		+	We see an increasing number of projects using GTK + DirectFB.
		+
		+	Gustavo Barberi writes:
		+	[DirectFB is] widely used, specially in non-TV embedded environments.
		+
		+	The problem with TV environments is the old-fashioned way of doing hw
		+	acceleration. Usually they have lots of different layers, that makes
		+	life for X harder. It's not impossible, but one would have to write
		+	drivers for X that expose those using different X Visuals. As people
		+	are usually short on time, they just hack a simple DirectFB driver and
		+	do their apps using it.
		+
		+	>> At Sony we're not shipping a lot of (any?) products with X, but if
		+	>> the footprint problem was solved maybe we would consider it.
		+
		+	I guess everything non-TV is every feasible. For TVs, it would need
		+	more work... or new hardware that is not so "fixed". New hardware
		+	exposes programmable pixel shaders using GL-ES2.0 so this is not an
		+	issue... and people want more than just alpha-channel OSDs these days