summaryrefslogtreecommitdiff
path: root/glamor/glamor_polylines.c
diff options
context:
space:
mode:
authorZhigang Gong <zhigang.gong@linux.intel.com>2012-02-10 16:04:07 +0800
committerEric Anholt <eric@anholt.net>2013-12-18 11:23:48 -0800
commit430bc16ca03b3ea00255a4045c8e9fd11aea95ad (patch)
tree1b3eddda6b246f4df504d6aa170eb5ef68045e2b /glamor/glamor_polylines.c
parent0a8fb8563f3cecf2019d3a35d5a61ec2b3a069cd (diff)
GLX: Enable glx support.
If we are using MESA as our GL library, then both xserver's GLX and glamor are link to the same library. As xserver's GLX has its own _glapi_get/set_context/dispatch etc, and it is a simplified version derived from mesa thus is not sufficient for mesa/egl's dri loader which is used by glamor. Then if glx module is loaded before glamoregl module, the initialization of mesa/egl/opengl will not be correct, and will fail at a very early stage, most likely fail to map the element buffer. Two methodis to fix this problem, first is to modify the xserver's glx's glapi.c to fit mesa's requirement. The second is to put a glamor.conf as below, to the system's xorg.conf path. Section "Module" Load "glamoregl" EndSection Then glamor will be loaded firstly, and the mesa's libglapi.so will be used. As current xserver's dispatch table is the same as mesa's, then the glx's dri loader can work without problem. We took the second method as it don't need any change to xorg.:) Although this is not a graceful implementation as it depends on the xserver's dispatch table and the mesa's dispatch table is the same and the context set and get is using the same method. Anyway it works. As by default, xserver will enable GLX_USE_TLS. But mesa will not enable it, you may need to enable that when build mesa. Three pre-requirements to make this glamor version work: 0. Make sure xserver has commit 66e603, if not please pull the latest master branch. 1. Rebuild mesa by enable GLX_USE_TLS. 2. Put the glamor.conf to your system's xorg.conf path and make sure it loaded prior to glx module. Preliminary testing shows indirect glxgears works fine. If user want to use GLES2 for glamor by using MESA, GLX will not work correctly. If you are not using normal MESA, for example PVR's private GLES implementation, then it should be ok to use GLES2 glamor and the GLX should work as expected. In this commit, I use gbm to check whether we are using MESA or non-mesa. Maybe not the best way. Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Diffstat (limited to 'glamor/glamor_polylines.c')
-rw-r--r--glamor/glamor_polylines.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/glamor/glamor_polylines.c b/glamor/glamor_polylines.c
index 0217e8fcb..0d37a1dd1 100644
--- a/glamor/glamor_polylines.c
+++ b/glamor/glamor_polylines.c
@@ -49,6 +49,9 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode, int n,
xRectangle *rects;
int x1, x2, y1, y2;
int i;
+ glamor_screen_private *glamor_priv;
+ GLAMOR_DEFINE_CONTEXT;
+
/* Don't try to do wide lines or non-solid fill style. */
if (gc->lineWidth != 0) {
/* This ends up in miSetSpans, which is accelerated as well as we
@@ -108,6 +111,8 @@ _glamor_poly_lines(DrawablePtr drawable, GCPtr gc, int mode, int n,
&& glamor_ddx_fallback_check_gc(gc))
return FALSE;
+ glamor_priv = glamor_get_screen_private(drawable->pScreen);
+ GLAMOR_SET_CONTEXT(glamor_priv);
if (gc->lineWidth == 0) {
if (glamor_prepare_access(drawable, GLAMOR_ACCESS_RW)) {
if (glamor_prepare_access_gc(gc)) {
@@ -121,6 +126,7 @@ wide_line:
/* fb calls mi functions in the lineWidth != 0 case. */
fbPolyLine(drawable, gc, mode, n, points);
}
+ GLAMOR_RESTORE_CONTEXT(glamor_priv);
return TRUE;
}