1. 17 Nov, 2021 1 commit
  2. 30 Sep, 2021 3 commits
  3. 20 Sep, 2021 1 commit
  4. 30 Jul, 2021 4 commits
  5. 04 Jun, 2021 2 commits
    • Peter Harris's avatar
      Fix writev emulation on Windows · 21414e7c
      Peter Harris authored
      There are at least two bugs in the previous implementation:
      
      - If an early iovec is partially written, there can be a gap of missing
        data (as a later iovec will be started before the early iovec is
        completed).
      - If a late iovec returns WSAEWOULDBLOCK, *vector and *count are not
        updated, leading to a re-send of the entire request.
      
      Move the *vector update into the send() loop to update piecemeal as
      individual iovecs are sent.
      
      Example program that demonstrates the issue (this program should run
      forever after these bugs have been fixed):
      
      #include <stdio.h>
      #include <stdlib.h>
      #include "xcb.h"
      
      // Non-cryptographic random number generator from http://burtleburtle.net/bob/rand/smallprng.html
      
      
      // because Microsoft's random number generators either have a too small RAND_MAX or are too slow
      typedef struct ranctx { uint32_t a; uint32_t b; uint32_t c; uint32_t d; } ranctx;
      
      static uint32_t ranval(ranctx *x);
      static void raninit(ranctx *x, uint32_t seed);
      
      
      #define MAX_PROP_LEN (128 * 1024)
      
      int main(int argc, char *argv[]) {
          uint32_t seed = 0x12345678;
          if (argc > 1) {
              seed = strtoul(argv[1], NULL, 0);
          }
          ranctx ran;
          raninit(&ran, seed);
      
          xcb_connection_t *c = xcb_connect(NULL, NULL);
          if (!c || xcb_connection_has_error(c)) {
              printf("Cannot connect to $DISPLAY\n");
              return 1;
          }
          const xcb_setup_t *setup = xcb_get_setup(c);
          char *buf = malloc(MAX_PROP_LEN + 8); // plus a bit of slack so we can run random values off the end
          if (!buf) {
              printf("oom\n");
              return 1;
          }
          for (uint32_t i=0; i < (MAX_PROP_LEN + 3) / 4; i++) {
              ((uint32_t *)buf)[i] = ranval(&ran);
          }
      
          xcb_window_t win = xcb_generate_id(c);
          xcb_create_window(c, 0, win, xcb_setup_roots_iterator(setup).data[0].root, 0, 0, 1, 1, 0,
                  XCB_WINDOW_CLASS_INPUT_ONLY, 0, 0, NULL);
          printf("Created window 0x%X\n", win);
      
          for (;;) {
              xcb_flush(c);
              xcb_generic_event_t *ev = xcb_poll_for_event(c);
              if (ev) {
                  if (ev->response_type == 0) {
                      xcb_generic_error_t *err = (xcb_generic_error_t *)ev;
                      printf("Unexpected X Error %d\n", err->error_code);
                      printf("   Sequence %d\n", err->sequence);
                      printf("   Resource ID 0x%X\n", err->resource_id);
                      printf("   Opcode: %d.%d\n", err->major_code, err->minor_code);
                      return 1;
                  }
                  printf("Unexpected X Event %d\n", ev->response_type);
                  return 1;
              }
      
              uint32_t siz = ranval(&ran) % MAX_PROP_LEN + 1;
              xcb_change_property(c, XCB_PROP_MODE_REPLACE, win, XCB_ATOM_STRING, XCB_ATOM_STRING, 8, siz, buf);
          }
      
          return 0;
      }
      
      
      #define rot(x,k) (((x)<<(k))|((x)>>(32-(k))))
      static uint32_t ranval(ranctx *x) {
          uint32_t e = x->a - rot(x->b, 27);
          x->a = x->b ^ rot(x->c, 17);
          x->b = x->c + x->d;
          x->c = x->d + e;
          x->d = e + x->a;
          return x->d;
      }
      
      static void raninit(ranctx *x, uint32_t seed) {
          uint32_t i;
          x->a = 0xf1ea5eed, x->b = x->c = x->d = seed;
          for (i = 0; i<20; ++i) {
              (void)ranval(x);
          }
      }
      Signed-off-by: Peter Harris's avatarPeter Harris <pharris@opentext.com>
      21414e7c
    • Peter Harris's avatar
      Fix build on Windows · 4b0d9d38
      Peter Harris authored
      
      
      Notable changes: Protect include of unistd.h (and other POSIX headers).
      Use SOCKET (which is larger than int) and closesocket (because close is
      not compatible) for sockets. Use <stdint.h>'s intptr_t instead of the
      non-portable ssize_t.
      Signed-off-by: Peter Harris's avatarPeter Harris <pharris@opentext.com>
      4b0d9d38
  6. 02 Jun, 2021 1 commit
  7. 02 Feb, 2021 1 commit
    • Julien Cristau's avatar
      Increment libtool version info for libxcb-dri3 · 2ef86559
      Julien Cristau authored
      Somewhat belatedly given the last update was in xcb-proto 1.13 in 2017...
      
      Quoting @smcv from https://bugs.debian.org/921069:
      
      > libxcb-dri3 version 1.13 appears to have added new symbols without increasing
      > the minor ABI version in its -version-info. This will break anything that
      > compares libraries by their version info to decide which one is newer.
      >
      > The Steam Runtime uses libraries' major/minor/micro ABI version info (in this
      > case 0.0.0) to decide whether to use the system copy of a library or the copy
      > in the Steam Runtime, depending on which one is newer (#921026). We can
      > work around this by adding a versioned dependency on libxcb-dri3-0 and
      > deleting the copy from the Steam Runtime, but this isn't a particularly
      > scalable solution.
      2ef86559
  8. 19 Nov, 2020 2 commits
  9. 02 Mar, 2020 1 commit
  10. 22 Feb, 2020 5 commits
  11. 19 May, 2019 1 commit
    • Martin Dørum's avatar
      Handle EINTR from recvmsg in _xcb_in_read · 21324989
      Martin Dørum authored
      
      
      I have a GTK application which occasionally crashes with an "interrupted
      system call" g_message from gdk. After a lot of debugging, I've found
      that the call to recvmsg in _xcb_in_read occasionally fails with EINTR,
      and instead of retrying the system call, xcb would just shut down the
      connection.
      
      This change makes _xcb_in_read treat EINTR the same as it would treat
      EAGAIN; it returns 1 and libX11 ends up calling xcb_poll_for_event
      again (from what I have understood).
      
      I have spoken with a few people who think recvmsg failing with EINTR in
      this case shouldn't ever happen, and I don't know enough to agree or
      disagree with that. In case anyone wants to dig further and try to
      figure out why the recvmsg call sometimes fails with EINTR, here's the
      backtrace from inside of _xcb_in_read where that happened:
      
      Thread 1 "beanbar" hit Breakpoint 1, _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
      1059                fprintf(stderr, "Hello World am %s:%i, errno is %s\n", __FILE__, __LINE__, strerror(errno));
      (gdb) bt
      0  0x00007fa48fa48639 in _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
      1  0x00007fa48fa489d8 in poll_for_next_event (c=0x55ecbe4aba80, queued=queued@entry=0) at xcb_in.c:352
      2  0x00007fa48fa48a3d in poll_for_next_event (queued=0, c=<optimized out>) at xcb_in.c:722
      3  0x00007fa48fa48a3d in xcb_poll_for_event (c=<optimized out>) at xcb_in.c:722
      4  0x00007fa4908d1b7e in poll_for_event (dpy=dpy@entry=0x55ecbe4a9730, queued_only=queued_only@entry=0) at xcb_io.c:245
      5  0x00007fa4908d1cf0 in poll_for_response (dpy=dpy@entry=0x55ecbe4a9730) at xcb_io.c:303
      6  0x00007fa4908d1fed in _XEventsQueued (mode=2, dpy=0x55ecbe4a9730) at xcb_io.c:363
      7  0x00007fa4908d1fed in _XEventsQueued (dpy=dpy@entry=0x55ecbe4a9730, mode=mode@entry=2) at xcb_io.c:344
      8  0x00007fa4908c3d47 in XPending (dpy=0x55ecbe4a9730) at Pending.c:55
      9  0x00007fa493cadbc7 in  () at /usr/lib/libgdk-3.so.0
      10 0x00007fa49234d08a in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0
      11 0x00007fa49234d6e6 in  () at /usr/lib/libglib-2.0.so.0
      12 0x00007fa49234d8ae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
      13 0x00007fa4938b920e in g_application_run () at /usr/lib/libgio-2.0.so.0
      14 0x000055ecbc820af4 in main (argc=1, argv=0x7ffd06238098) at src/main.c:190
      Signed-off-by: Martin Dørum's avatarMartin Dørum <martid0311@gmail.com>
      21324989
  12. 25 Apr, 2019 1 commit
  13. 17 Feb, 2019 2 commits
  14. 16 Feb, 2019 2 commits
  15. 07 Jan, 2019 1 commit
  16. 27 Sep, 2018 1 commit
  17. 21 Aug, 2018 1 commit
    • Erik Kurzinger's avatar
      don't flag extra reply in xcb_take_socket · bbda345a
      Erik Kurzinger authored and Uli Schlachter's avatar Uli Schlachter committed
      If any flags are specified in a call to xcb_take_socket,
      they should only be applied to replies for requests sent
      after that function returns (and until the socket is
      re-acquired by XCB).
      
      Previously, they would also be incorrectly applied to the
      reply for the last request sent before the socket was taken.
      For instance, in this example program the reply for the
      GetInputFocus request gets discarded, even though it was
      sent before the socket was taken. This results in the
      call to retrieve the reply hanging indefinitely.
      
      static void return_socket(void *closure) {}
      
      int main(void)
      {
          Display *dpy = XOpenDisplay(NULL);
          xcb_connection_t *c = XGetXCBConnection(dpy);
      
          xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c);
          xcb_flush(c);
      
          uint64_t seq;
          xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, &seq);
      
          xcb_generic_error_t *err;
          xcb_get_input_focus_reply(c, cookie, &err);
      }
      
      In practice, this has been causing intermittent KWin crashes when
      used in combination with the proprietary NVIDIA driver such as
      https://bugs.kde.org/show_bug.cgi?id=386370
      
       since when Xlib fails to
      retrieve one of these incorrectly discarded replies it triggers
      an IO error.
      Signed-off-by: Erik Kurzinger's avatarErik Kurzinger <ekurzinger@nvidia.com>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
      bbda345a
  18. 28 Feb, 2018 1 commit
  19. 05 Jun, 2017 2 commits
  20. 13 May, 2017 2 commits
  21. 01 Apr, 2017 1 commit
  22. 11 Mar, 2017 3 commits
    • Christian Linhart's avatar
      add support for eventstruct · ee9dfc9a
      Christian Linhart authored
      
      
      eventstruct allows to use events as part of requests.
      This is, e.g., needed by xcb_input_send_extension_event.
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
      ee9dfc9a
    • Christian Linhart's avatar
      optionally build the GE extension · 0c2c5d50
      Christian Linhart authored
      
      
      xcb contains an xml-definition for the GenericEvent extension
      but this extension was neither generated nor built.
      
      This patch enables optional building of the GenericEvent extension
      with configure option --enable-ge
      
      By default, the GenericEvent extension is not built.
      Normally this is not needed by application programs
      because there is implicit support for the GE-extension
      for the specific events built with this extension.
      
      But it may be useful for X-protocol analyzers and stuff like that.
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
      0c2c5d50
    • Christian Linhart's avatar
      move symbol lookup of sumof expr to the parser · 9bce1f72
      Christian Linhart authored
      
      
      replace the complicated symboltable lookup for sumof expr
      by accessing the lenfield of the expr-object.
      
      This requires the corresponding patch for xcb/proto
      which sets the lenfield accordingly.
      
      This should be OK because for official releases we define
      that dependency in the build system.
      
      For getting versions off the HEAD of the git repo, it should
      be obvious that xcb/proto and xcb/libxcb have to be updated together.
      
      I have tested this patch and it generates exactly the same code
      as before.
      Tested-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
      Signed-off-by: Christian Linhart's avatarChristian Linhart <chris@demorecorder.com>
      9bce1f72
  23. 29 May, 2016 1 commit
    • Alan Coopersmith's avatar
      Correct @param "e" to "error" in xcb_poll_for_reply*() · 65b298c7
      Alan Coopersmith authored and Uli Schlachter's avatar Uli Schlachter committed
      
      
      Found by clang -Wdocumentation:
      
      ./xcbext.h:271:11: warning: parameter 'e' not found in the function
            declaration [-Wdocumentation]
       * @param e Location to store errors in, or NULL. Ignored for un...
                ^
      ./xcbext.h:271:11: note: did you mean 'error'?
       * @param e Location to store errors in, or NULL. Ignored for un...
                ^
                error
      
      ./xcbext.h:283:11: warning: parameter 'e' not found in the function
            declaration [-Wdocumentation]
       * @param e Location to store errors in, or NULL. Ignored for un...
                ^
      ./xcbext.h:283:11: note: did you mean 'error'?
       * @param e Location to store errors in, or NULL. Ignored for un...
                ^
                error
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Signed-off-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
      65b298c7