1. 04 Dec, 2017 1 commit
  2. 01 Dec, 2017 2 commits
    • Adam Jackson's avatar
      glx: Prepare __glXGetDrawable for no-config contexts · f0fffa92
      Adam Jackson authored
      Any proper (GLX 1.3) drawable will already have a bound config, but if
      we're doing the GLX 1.2 thing of making a Window current, we need to
      infer the config from the window's Visual.
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
    • Adam Jackson's avatar
      glx: Fix glXQueryContext for GLX_FBCONFIG_ID and GLX_RENDER_TYPE (v2) · 5d667df6
      Adam Jackson authored
      Just never filled in, oops. Seems to have gone unnoticed because
      normally glXQueryContext simply returns the values filled in by the
      client library when the context was created. The only path by which you
      normally get to a GLXQueryContext request is glXImportContext, and then
      only if the context is already indirect.
      However, that's a statement about Mesa's libGL (and anything else that
      inherited that bit of the SGI SI more or less intact). Nothing prevents
      a mischeivous client from issuing that request of a direct context, and
      if they did we'd be in trouble because we never bothered to preserve the
      associated fbconfig in the context state, so we'd crash looking up
      GLX_VISUAL_ID_EXT. So let's fix that too.
      v2: Fixed missing preservation of the config in DRI2 (Eric Anholt)
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
  3. 29 Nov, 2017 6 commits
  4. 23 Nov, 2017 1 commit
  5. 20 Nov, 2017 3 commits
  6. 15 Nov, 2017 2 commits
  7. 14 Nov, 2017 3 commits
  8. 07 Nov, 2017 5 commits
  9. 06 Nov, 2017 7 commits
  10. 03 Nov, 2017 1 commit
    • Thomas Hellstrom's avatar
      glx: Duplicate relevant fbconfigs for compositing visuals · f84e59a4
      Thomas Hellstrom authored
      Previously, before GLX_OML_swap_method was fixed, both the X server and
      client ignored the swapMethod fbconfig value, which meant that, if the dri
      driver thought it exposed more than one swapMethod, it actually just
      exported a duplicated set of fbconfigs. When fixing GLX_OML_swap_method
      and restricting the choice for built-in visuals to a single swap method
      that meant we didn't have that many fbconfigs to choose from when pairing
      the compositing visual with an fbconfig, resulting in the fbconfig paired
      with the compositing visual becoming too restrictive for some applications,
      (at least for kwin). This problem would also happen if the dri driver
      only exposed a single swap method to begin with.
      So, to make sure the compositing visual gets a good enough fbconfig,
      duplicate fbconfigs that are suitable for compositing visuals and make
      sure these duplicated fbconfigs can be used only by compositing visuals.
      For duplicated fbconfigs not paired with a compositing visual, construct
      new compositing visuals, making compositing clients able to choose visuals
      / fbconfig more adapted to their needs.
      This is in some sense equivalent to adding a new "TRUECOLOR_COMPOSITING"
      GLX visualtype.
      Fixes: 4486d199 ("glx: Fix visual fbconfig matching with respect to
                            swap method")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102806
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Tested-By: default avatarNick Sarnie <commendsarnex@gmail.com>
      Tested-by: Fredrik Höglund's avatarFredrik Höglund <fredrik@kde.org>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  11. 01 Nov, 2017 2 commits
    • Emma Anholt's avatar
      xkb: Print the xkbcomp path being executed when we fail to compile. · 30f4d440
      Emma Anholt authored
      I don't know how many times I've had a broken server due to a bad
      directory to xkbcomp, and only finding the whole path has shown me
      where I went wrong.
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
    • Emma Anholt's avatar
      test: Add a test for the overflow bug in bigreqs. · 14af8bee
      Emma Anholt authored
      The failing struct comes from the python test written by Michal Srb
      v2: Use a drawable (root window) and gc, so that PolyLines hopefully
          actually tries processing things.  However, the request seems to
          process successfully so the poll() just stalls out.  However, this
          does let us distinguish between detecting the bigrequests error
          and not, at least.
      v3: Clean up the description of what we expect the poll() call to do.
      v4: Use XI2 instead of PolyLine to trigger a predictable error. We know the
          server replies with BadValue for a zero num_masks argument. So if we send
          a bigreq with a num_masks 0 and a length 0, we can just check whether we
          get killed (good) or a BadValue (bad). It doesn't test for specific memory
          overflows or crashes, but based on the assumption that we shouldn't look
          at *any* BigReq of size 0, this seems to be sufficient.
      Signed-off-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  12. 31 Oct, 2017 1 commit
  13. 30 Oct, 2017 6 commits