Difference between revisions of "Decrease X.org XFree86 server footprint"

From eLinux.org
Jump to: navigation, search
(Comments: fix <pre> typo)
(Comments: add to category)
 
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]]

Latest revision as of 12:07, 2 December 2009

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

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 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