This commit fixed two bugs when one client reset the connection.
The first is that we should reopen the graphic device when the previous
node was closed during the screen closing. The second one is we should
call glamor_close_screen (not the ddx version) prior to call
eglTerminate(). As eglTerminate will release the share library. And
the glamor_close_screen may still need to call openGL APIs and thus
will hit segfault. And renamed the ddx functions to avoid naming
conflications with the glamor functions.
GC is redefined in the X11/Xlib.h and include/gcstruct.h which is
a xorg header file. Just use a macro to simply avoid the conflict.
Need revisit latter to find a correct way to fix this problem.
Due to the coordinate system on EGL is different from FBO
object. To support EGL surface well, we add this new feature.
When calling glamor_init from EGL ddx driver, it should use
the new flag GLAMOR_INVERTED_Y_AXIS.
move the original glamor_fini to glamor_close_screen. And wrap the CloseScreen
with glamor_close_screen, Then we can do some thing before call the underlying
CloseScreen().
The root cause is that glamor_fini will be called after the ->CloseScreen().
This may trigger a segmentation fault at
glamor_unrealize_glyph_caches() at calling into FreePicture().
As current glamor implementation depends on the glx library in the
mesa package which is conflict with the version in xorg. We have to
--disable-glx when build Xephyr. But this leads to the linking error
here. We comment out the calling to ephyrHijackGLXExtension() now.
Need revisit latter.
We should include the dix-config.h for all the glamor files. Otherwise
the XID type maybe inconsisitent in different files in 64bit machine.
The root cause is this macro "#define _XSERVER64 1" should be included
in all files refer to the data type "XID" which is originally defined
in X.h. If _XSERVER64 is defined as 1, then XID is defined as CARD32
which is a 32bit integer. If _XSERVER64 is not defined as 1 then XID
is "unsigned long". In a 32bit machine, "unsigned long" should be
identical to CARD32. But in a 64bit machine, they are different.
Sometimes we want to try a couple of different methods for
accelerating. If one of them says "no" and the other says "yes",
don't spam the log about the "no."
They're stored just like a8, but the values are set to either 0.0 or
1.0. Because they're a8 with only two legal values, we can't use them
as destinations, but nobody's rendering to a1 dests anyway (we hope).
It's not an offset from pixmap coords to composited pixmap coords,
it's an offset from screen-relative window drawable coords to
composited pixmap coords.