1. 18 Dec, 2013 5 commits
    • Chris Wilson's avatar
      Fixup glx support · 556adfa6
      Chris Wilson authored
      Renaming glamor_priv->dispatch and wrapping the access to
      the dispatch table with a function that also ensured the
      context was bound.
      
       dispatch = glamor_get_dispatch(glamor_priv);
       ...
       glamor_put_dispatch(glamor_priv);
      
      So that we catch all places where we attempt to call into GL withouta
      context. As an optimisation we can then do glamor_get_context();
      glamor_put_context() around the rendering entry points to reduce the
      frequency of having to restore the old context. (Along with allowing
      the context to be recursively acquired and making the old context part of
      the glamor_egl state.)
      Reviewed-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      556adfa6
    • Zhigang Gong's avatar
      GLX: Enable glx support. · 430bc16c
      Zhigang Gong authored
      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: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      430bc16c
    • Zhigang Gong's avatar
    • Zhigang Gong's avatar
      glamor_getimage: Add the optimization path of getImage. · 42a0261c
      Zhigang Gong authored
      This optimization will only call glReadPixels once. It should get
      some performance gain. But it seems it even get worse performance
      at SNB, disable it by default.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      42a0261c
    • Zhigang Gong's avatar
      glamor-for-ddx: Exports all rendering/drawing functions. · 8c7fcefb
      Zhigang Gong authored
      This commit exports all the rest rendering/drawing functions
      to the DDX drivers. And introduce some new pixmap type. For
      a pixmap which has a separated texture, we never fallback
      it to the DDX layer.
      
      This commit also adds the following new functions:
      glamor_composite_rects, glamor_get_image_nf which are needed
      by UXA framework. Just a simple wrapper function of miXXX.
      Will consider to optimize them next few weeks.
      
      This commit also Fixed a glyphs rendering bug pointed by Chris.
      Signed-off-by: default avatarZhigang Gong <zhigang.gong@linux.intel.com>
      8c7fcefb
  2. 16 Oct, 2011 2 commits
  3. 03 Dec, 2008 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Rework symbol visibility for easier maintenance · 49f77fff
      Paulo Cesar Pereira de Andrade authored
        Save in a few special cases, _X_EXPORT should not be used in C source
      files. Instead, it should be used in headers, and the proper C source
      include that header. Some special cases are symbols that need to be
      shared between modules, but not expected to be used by external drivers,
      and symbols that are accessible via LoaderSymbol/dlopen.
      
        This patch also adds conditionally some new sdk header files, depending
      on extensions enabled. These files were added to match pattern for
      other extensions/modules, that is, have the headers "deciding" symbol
      visibility in the sdk. These headers are:
      o Xext/panoramiXsrv.h, Xext/panoramiX.h
      o fbpict.h (unconditionally)
      o vidmodeproc.h
      o mioverlay.h (unconditionally, used only by xaa)
      o xfixes.h (unconditionally, symbols required by dri2)
      
        LoaderSymbol and similar functions now don't have different prototypes,
      in loaderProcs.h and xf86Module.h, so that both headers can be included,
      without the need of defining IN_LOADER.
      
        xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
      not exported (and with a comment about it).
      49f77fff
  4. 25 Nov, 2008 2 commits
  5. 03 Oct, 2008 1 commit
  6. 18 Aug, 2008 1 commit
  7. 12 Mar, 2008 1 commit
    • Mark Kettenis's avatar
      OpenBSD support for libpciaccess. · 06c0372c
      Mark Kettenis authored
      xserver and libpciaccess both need to open /dev/xf86, which can only
      be opened once.  I implemented pci_system_init_dev_mem() like Ian
      suggested.  This requires some minor changes to the BSD-specific
      os-support code.  Since pci_system_init_dev_mem() is a no-op on
      FreeBSD this should be no problem.
      06c0372c
  8. 28 Aug, 2007 1 commit
    • Eric Anholt's avatar
      Replace BSD custom PCI code with a stub implementation thanks to pciaccess. · adf46b57
      Eric Anholt authored
      Note that pciaccess doesn't yet have Net/OpenBSD support, but the relevant
      code should go there instead of disconnected code in the X Server.
      
      While here, remove the now-disabled INCLUDE_XF86_NO_DOMAIN from the headers,
      and un-disable xf8StdAccResFromOS for those OSes without domain support which
      will need it.
      adf46b57
  9. 31 Jul, 2007 1 commit
  10. 01 Nov, 2006 1 commit
    • Daniel Stone's avatar
      input: add non-keyboard bell ringing function · 81728558
      Daniel Stone authored
      Add a generic 'ring the bell' function (console bell on Linux and BSD,
      /dev/audio on Solaris), and add DDX functions for this.  Make this the
      core keyboard's bell.
      Port Xvfb and Xnest to this.
      Port XFree86 to this, with OS-specific hooks for Linux, BSD, and Solaris
      taken from foo_io.c in the old layer.
      81728558