1. 27 Jan, 2021 1 commit
    • Julien Cristau's avatar
      compiler.h: don't define inb/outb and friends on mips · 0148a15d
      Julien Cristau authored
      The definition relies on IOPortBase, which is only ever set in
      This caused build failures on linux/mips with GCC 10, due to this
      change (from https://gcc.gnu.org/gcc-10/changes.html#c):
      "GCC now defaults to -fno-common. As a result, global variable accesses
      are more efficient on various targets. In C, global variables with
      multiple tentative definitions now result in linker errors. With
      -fcommon such definitions are silently merged during linking."
      As a result anything including compiler.h would get its own definition
      of IOPortBase and the linker would error out.
  2. 22 Jan, 2021 3 commits
  3. 08 Jan, 2021 1 commit
  4. 06 Jan, 2021 1 commit
  5. 05 Jan, 2021 1 commit
    • Povilas Kanapickas's avatar
      xi: Don't deliver emulated motion when there's no owner for touch end · 3ab3083c
      Povilas Kanapickas authored
      Pointer-emulated touch events should only be delivered to the client
      that owns the sequence even if it's a core client that became the
      effective owner of the sequency by selecting for pointer press and
      Currently the emulated events are delivered like this already (see
      TouchResourceIsOwner() check in DeliverEmulatedMotionEvent()), except in
      the case of TouchEnd, in which case the generated motion event is still
      delivered to some client that's not necessarily the owner of the touch
      We already know whether a touch sequence that is about to emulate a
      pointer event has an owner, we just need to check that. This further
      allows to simplify DeliverEmulatedMotionEvent() as it won't ever be
      called for non-owned touch events.
      Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
  6. 18 Dec, 2020 2 commits
  7. 17 Dec, 2020 3 commits
  8. 15 Dec, 2020 2 commits
  9. 14 Dec, 2020 3 commits
  10. 10 Dec, 2020 3 commits
  11. 08 Dec, 2020 2 commits
  12. 04 Dec, 2020 1 commit
    • Michal Srb's avatar
      xkb: Fix heap overflow caused by optimized away min. · 74627d13
      Michal Srb authored
      Calling strlen on char[4] that does not need to contain '\0' is wrong and X
      server may end up running into uninitialized memory.
      In addition GCC 8 is clever enough that it knows that strlen on char[4] can
      return 0, 1, 2, 3 or cause undefined behavior. With this knowledge it can
      optimize away the min(..., 4). In reality it can cause the memcpy to be called
      with bigger size than 4 and overflow the destination buffer.
      Fixes: 83913de2 (xkb: Silence some compiler warnings)
      Closes: xorg/xserver#288
      Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
  13. 01 Dec, 2020 3 commits
  14. 30 Nov, 2020 1 commit
    • Michel Dänzer's avatar
      glx: Remove unused bswap_CARD64 · b0530fe4
      Michel Dänzer authored
      GCC warned about it:
      ../../../glx/indirect_dispatch_swap.c:85:1: warning: ‘bswap_CARD64’ defined but not used [-Wunused-function]
         85 | bswap_CARD64(const void *src)
            | ^~~~~~~~~~~~
  15. 26 Nov, 2020 2 commits
    • Olivier Fourdan's avatar
      modesetting: Fix build with DebugPresent() enabled · 3ce05a44
      Olivier Fourdan authored
      By default, the macro DebugPresent() is a no-op but it can be enabled
      at build time for debugging purpose.
      However, doing so prevents the code to build because one debug statement
      tries to make use of a non-existent variable:
        present.c: In function ‘ms_present_queue_vblank’:
        present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
          147 |                  vbl.request.sequence));
              |                  ^~~
        present.c:49:32: note: in definition of macro ‘DebugPresent’
          49 | #define DebugPresent(x) ErrorF x
             |                                ^
      Fix the build with DebugPresent() by removing the vbl variable from the
      debug message.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
    • Erik Kurzinger's avatar
      GLX: fix context render type queries · 95b79aa9
      Erik Kurzinger authored
      Querying the GLX_RENDER_TYPE of a GLX context via glXQueryContext will
      currently return the render type of the context's FB config, which is
      a bitmask of GLX_RGBA_BIT / GLX_COLOR_INDEX_BIT / ... values. However,
      this query should really return the render type that was specified
      when creating the context, which is one of GLX_RGBA_TYPE /
      GLX_COLOR_INDEX_TYPE / .... To enable this, save the render type when
      creating a new context (defaulting to GLX_RGBA_TYPE if unspecified),
      and then include this value in the context attributes sent to clients.
  16. 25 Nov, 2020 11 commits