Xlib (was :The forbidden topic: Glamo OpenGL)

Kishore kitts.mailinglists at gmail.com
Mon Nov 17 08:05:26 CET 2008

On Monday 17 Nov 2008 11:24:55 am John Lee wrote:
> On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote:
> > x's internals are definitely up for improvement - callium3d is  there to
> > try and fix this by providing a better more organised and better
> > accelerated driver layer - but again - they aren't going to replace x...
> > just clean up internals. what it means is - the rest of us can continue
> > happily writing x apps and just "wait" for an improvement to pop out the
> > pipeline. indeed x's internal acceleration layer could be improved. it
> > has in the past (especially with xaa) proved an impediment if you have to
> > code AT the driver layer. as such - x was originally designs (as a system
> > - not specifically the xorg tree etc.) to allow full freedom to implement
> > the internals of x any way you like - so as such if you wanted to spend
> > the effort x could accelerate just about everything as long as hardware
> > can do it, somehow - but the points at which that acceleration knowledge
> > need to go into might be much higher up than xaa/exa. you'd have to write
> > a "forked" x with all sorts of hooks higher up. - but it's possible...
> > and then x client work as they always did - and get more use of the
> > hardware :)
> MicroXwin ?
> http://www.microxwin.com/
> "MicroXwin is binary compatible to the Xlib API. However it is niether
> client server nor network oriented. Graphics operations are
> implemented in the linux kernel via a kernel module. An open source
> Xlib library sends graphics commands to the kernel. There is no
> network overhead and no context switch from X client to X server. This
> makes our solution smaller and faster than traditional X Windows."

Looks good and is a direct binary compatible replacement. Perhaps the 
proprietary licence for the kernel module is what is keeping it from being 

More information about the community mailing list