1. 04 Sep, 2010 1 commit
  2. 28 Aug, 2010 1 commit
    • Gaetan Nadon's avatar
      config: remove man-pages configuration option · 09edc6de
      Gaetan Nadon authored
      This option was added in commit 6e752ea1 with no explanation.
      The section number is provoded by XORG_MANPAGE_SECTIONS
      There is no case where libX11 should be different than other libs
      The option was also used to disable building of the man pages,
      which build in 14 secs. No indication this is required.
      If there is a requirement from system builders to disable building
      of man pages, it could be done consistently for all modules.
      Signed-off-by: Gaetan Nadon's avatarGaetan Nadon <memsize@videotron.ca>
  3. 13 Aug, 2010 2 commits
  4. 07 Aug, 2010 1 commit
  5. 24 Jul, 2010 1 commit
  6. 24 Jun, 2010 1 commit
  7. 02 Jun, 2010 1 commit
  8. 09 Apr, 2010 6 commits
  9. 17 Jan, 2010 1 commit
  10. 15 Jan, 2010 1 commit
  11. 14 Jan, 2010 2 commits
  12. 06 Jan, 2010 1 commit
  13. 29 Oct, 2009 1 commit
  14. 23 Oct, 2009 1 commit
  15. 17 Oct, 2009 1 commit
  16. 08 Oct, 2009 1 commit
  17. 19 Sep, 2009 2 commits
  18. 03 Sep, 2009 2 commits
  19. 28 Aug, 2009 5 commits
  20. 05 Aug, 2009 3 commits
  21. 12 Jul, 2009 1 commit
    • Peter Hutterer's avatar
      Add generic event cookie handling to libX11. · 554f755e
      Peter Hutterer authored
      Generic events require more bytes than Xlib provides in the standard XEvent.
      Memory allocated by the extension and stored as pointers inside the event is
      prone to leak by simple 'while (1) { XNextEvent(...); }' loops.
      This patch adds cookie handling for generic events. Extensions may register
      a cookie handler in addition to the normal event vectors. If an extension
      has registered a cookie handler, _all_ generic events for this extensions
      must be handled through cookies. Otherwise, the default event handler is
      The cookie handler must return an XGenericEventCookie with a pointer to the
      data.The rest of the event (type, serialNumber, etc.) are to be filled as
      normal. When a client retrieves such a cookie event, the data is stored in
      an internal queue (the 'cookiejar'). This data is freed on the next call to
      New extension interfaces:
          XESetWireToEventCookie(display, extension_number, cookie_handler)
      Where cookie_handler must set cookie->data. The data pointer is of arbitray
      size and type but must be a single memory block. This memory block
      represents the actual extension's event.
      New client interfaces:
          XGetEventData(display, *cookie);
          XFreeEventData(display, *cookie);
      If the client needs the actual event data, it must call XGetEventData() with
      the cookie. This returns the data pointer (and removes it from the cookie
      jar) and the client is then responsible for freeing the event with
      XFreeEventData(). It is safe to call either function with a non-cookie
      event. Events unclaimed or not handled by the XGetEventData() are cleaned up
      Example client code:
          XEvent event;
          XGenericEventCookie *cookie = &ev;
          XNextEvent(display, &event);
          if (XGetEventData(display, cookie)) {
              XIEvent *xievent = cookie->data;
          } else if (cookie->type == GenericEvent) {
              /* handle generic event */
          } else {
              /* handle extension/core event */
          XFreeEventData(display, cookie);
      Cookies are not multi-threading safe. Clients that use XGetEventData() must
      lock between XNextEvent and XGetEventData to avoid other threads freeing
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  22. 21 May, 2009 1 commit
  23. 02 May, 2009 1 commit
  24. 16 Mar, 2009 1 commit
  25. 29 Jan, 2009 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      patches to avoid gcc warnings for libX11 (#2) · cce75c5d
      Paulo Cesar Pereira de Andrade authored
      Author is Peter Breitenlohner <peb@mppmu.mpg.de>
      Bug #17946, attachment #19440
      Avoid a preprocessor message
      	<stdin>:194: warning: no newline at end of file
      Two more such warnings (in XkbSAGroup.man and XkbSASetGroup.man)
      seem to be caused by a truncated (or otherwise incomplete)