summaryrefslogtreecommitdiff
path: root/glamor/glamor_egl_stubs.c
AgeCommit message (Collapse)AuthorFilesLines
2014-12-09glamor: Always destroy EGL image associated with destroyed pixmapKeith Packard1-1/+1
There were three paths that called eglDestroyImageKHR: * The front buffer * The intel driver's flip buffer * pixmaps under DRI3 This patch unifies the second two by having glamor_destroy_pixmap always destroy any associaged EGL image. This allows us to stop storing the back_pixmap pointer in glamor as that was only used to make sure that buffer was freed at server reset time. v2: check for valid pixmap_priv before using it in glamor_egl_destroy_pixmap_image Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
2014-04-01glamor: Move glamor_egl_screen_init() prototype to glamor.hKristian Høgsberg1-1/+3
A DDX that implements the glamor EGL functions need to pull in this prototype but shouldn't need to pull in glamor_priv.h Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-02-14glamor: Put in a pluggable context switcher for GLX versus EGL.Eric Anholt1-11/+1
The GLX side just gets the context from the current state. That's also something I want to do for EGL, so that the making a context is separate from initializing glamor, but I think I need the modesetting driver in the server before I think about hacking on that more. The previous code was rather incestuous, along with pulling in xf86 dependencies to our dix code. The new code just initializes itself from the current state. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-01-27glamor: Hook the module back up to the build.Eric Anholt1-0/+64
For now we're just building an uninstalled library. The extra EGL stubs are required so that we can get the DIX building and usable without pulling in the xf86 DDX code in glamor_egl.c. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Reviewed-by: Keith Packard <keithp@keithp.com>