Now, fbcmap_mi.c contains the fb functions which just wrap mi functions.
Previously, these were in fbcmap.c and compiled when XFree86Server was defined.
Now, clients of fbcmap should either use fbcmap.c or fbcmap_mi.c and not worry
about setting the XFree86Server symbol.
It seems that the changes to X input exposed a problem that wasn't detected
before. The axis clipping code in GetPointerEvents() uses those limits to
constrain the pointer's coordinate range. The max was zero so the pointer
couldn't move.
Use new dmxCoreMotion2() function which enqueues motion events with
GetPointerEvents()/mieqEnqueue().
The clipAxis() code in GetPointerEvents() is causing some grief. The
limits seem to have always been (0,0) according to the original calls
to InitValuatorAxisStruct() in dmxinputinit.c.
Terrible hack for now: Call InitValuatorAxisStruct() with hard-coded max
values of 1280 (my screen width).
Use newly added XMesaCopyContext() and drop the GlxSetRenderTables() call
for Xgl, as this is now done inside XMesaForceCurrent(). This leaves xmesaP.h
but only for the declarations of the three XMesa/XFree86 functions. Also,
GlxSetRenderTables() stays but is only used in hw/xgl/glxext/ .
Also drop xf86glxint.h, no longer used.
Depends on mesa commit 7439a36785b6a2783e80a40a96c09db8f56dc2bc of 2007-03-30.
One of the problems is that the GLX code resets the DRI driver
first and then CloseScreen is called in each driver causing things
to blow up.
Temporarily stop the GLX layer from resetting until an alternative
approach can be worked out.
From a driver perspective, all that needs to be done
is call...
glucoseScreenInit(pScreen);
and glucose will take over for the acceleration. Something
like this should do...
if (!exa && !xaa)
glucoseScreenInit(pScreen);
else if (!exa)
driversXAAinit(...);
else
driversEXAinit(...);
This code has been tested with the i915, i915tex and i810
and there's a few odd rendering quirks that need to be worked
out but they'll probably be in their respective drivers but
the framework is here now.
