Difference between revisions of "Decrease X.org XFree86 server footprint"
(→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
- 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.
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