[cairo] glitz-glx

[Jon Smirl]

--- David Reveman <c99drn at cs.umu.se> wrote:
> I don't know much about mesa-solo, what are the alternatives to using
> mesa-solo through miniglx? Can we use mesa-solo directly? If there are some
> advantages of using mesa-solo directly, then I definitely think we should
> create a mesa-solo backend for glitz, otherwise we should get the GLX
> backend working with miniglx.

I would start with getting a miniglx version going. I've copied the glx version
into a miniglx version on my local system. I have everything compiling now by
adding the appropriate stubs into miniglx. Stubs aren't the right solution but
they let me trace through the code in the debugger so that I can see what it is
doing. 

One problem in glitz is that you are assigning 0 to fbconfig variables. This is
fine for glx since fbconfig variables are longs, but in mesa-solo they are
structures so you can't do the assignment. Are these assignments necessary?

A top thing that needs to be changed is that miniglx does not support X mouse
and keyboard events. Instead you needs to open the Linux devices and
select()/read() them to get events. I have two video cards, keyboards, and mice.
This makes it easy to run X and use the debugger on the target process.

> Whether or not we create a mesa-solo backend, I still like to get miniglx
> running with the GLX backend. We can solve the root window issue by modifying
> the GLX backend in the following way:
> 1. Push back extension querying until the first GLX drawable is created. 
> 2. Only create the root window if pbuffer support is missing and the
> application tries to create an offscreen surface before it creates
> an onscreen surface. Miniglx applications just have to make sure that
> they don't create offscreen surfaces before creating an onscreen one.

I'll try playing around in the code and see if I can move these things around to
get around the one window limit.

Miniglx was created as a very simple windowing system. One process run a master
server that coordinates things. Each additional process is allowed a single
window. There is no windowing manager for moving these windows around. There is
also no input system. Miniglx runs on top of mesa-solo. It was targeted out a TV
set-top box.

Once a miniglx version is going it shouldn't be too hard to build a straight
mesa-solo version. In the mesa-solo one there is only a single process and it
gets the whole screen.  It might even be easier to go straight to a mesa-solo
version but I need to understand your glx code a lot more since all of it has to
be rewritten. mesa-solo has no glx and no xlib call support. If you need things
from xlib/glx you have to call the OS equivalents. Getting this running would be
a giant help to keithp.

I also tried all of the demo programs on software mesa. They all seem to work
but I do think some things were rendering differently so you may want to check
them. It is easy to get software mesa. Just comment out the load DRI line in
XF86Config and leave in the load GLX line. Performance of the sw render is not
that bad. If you can identify anything in particular that is really slow we can
try and get a mesa developer to fix it if possible.

=====
Jon Smirl
jonsmirl at yahoo.com


	
		
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer