Directfb Xorg server

[Mike Emmel]

On 5/30/06, Mike Emmel <mike.emmel at gmail.com> wrote:
> On 5/30/06, Graeme Gill <graeme2 at argyllcms.com> wrote:
> > Adam Jackson wrote:
> >
> > > These extensions are only ever built for the xfree86 DDX.  The code for them
> > > won't even get linked into the other DDXes:
> > >
> > > ~/xserver/xorg% nm hw/vfb/Xvfb | grep VidModeExtensionInit
> > > ~/xserver/xorg% nm hw/xfree86/Xorg | grep VidModeExtensionInit
> > > 080ba5f0 T VidModeExtensionInit
> >
> > Let me throw in a tangential observation, and note that since the XF86VidMode
> > extension provides the only X11 standardized way of accessing
> > frame buffer video lookup tables (RAMDAC's), that any frame buffer
> > driver that doesn't support the "GammaRamp" portion of this extension,
> > won't be capable of being color calibrated.
> >
> > Graeme Gill.
> >
> This is something we will provide a directfb interface when the kernel drivers
> can support it. There is some gamma correction support already.
>
>
I might add that the approach I'm taking certianly starts restricting
X11 every effort
will be made to provide and alternative api.

To expand

Directfb controls all api that are hardware dependent or don't have a
huge use case for being remote this includes.

Hardware configuration
Window Manager
Desktop
Top level composite manager
Cut and Past Buffer
Font Management

This leaves X11 focused on being a nextwork enable drawing canvas for
window contents.
In a lot of ways the goal is reduce X to be a network canvas then
focus on doing a good job at that. Next steps are to explore
alternatives for distributed drawing solutions that can exist along
side X11.  Right now the X protocol is the only well know and well
tested distributed
drawing solution it solves a a useful problem.

With the rise of toolkits such as GTK/KDE that effectivly hide the X11
api and the port of GTK to directfb X11 no longer has to fufill such a
wide range of roles. Apps that really want to be local can used the
directfb toolkit ones that want to be remote can use X11 later other
choices can be introduced.  For example I've turned to using VNC event
though its a crappy protocol for remote displayes because its
stateless and readily available. By isolating the X api to be used by
a few toolkits we can introduce a new api that can be stateless but is
better then VNC.

Anyway the point is that as long as X is the only way to solve the
display problem we must deal not only with new ideas but also all the
legacy support that comes from so many years of development.  I feel
that my approach allows 99% of existing X apps to run but allow
alternative approaches to be explored.

Anyway I'm trying to split the api avialable in X into two groups

A.) Api that are almost always local i.e co-server and seldom used by
applications.
B.) Desktop/Hardware managment
C.) The standard application apis used by programs.

Supporting the C group is the initial goal understanding the impact of removing.
Directfb based solutions will be used for A and be initially via gtk/directfb.

Then see if anyone likes it.

Mike




>
> > _______________________________________________
> > xorg mailing list
> > xorg at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/xorg
> >
>