1. 25 Apr, 2020 4 commits
  2. 22 Apr, 2020 2 commits
  3. 29 Jan, 2020 1 commit
    • Adam Jackson's avatar
      Fix XTS regression in XCopyColormapAndFree · 68c72a73
      Adam Jackson authored
      XCopyColormapAndFree/5 threw an assertion:
      
          520|4 5 00014017 1 2|Assertion XCopyColormapAndFree-5.(A)
          520|4 5 00014017 1 3|When a colourmap argument does not name a valid colourmap,
          520|4 5 00014017 1 4|then a BadColor error occurs.
          520|4 5 00014017 1 5|METH: Create a bad colourmap by creating and freeing a colourmap.
          520|4 5 00014017 1 6|METH: Call test function using bad colourmap as the colourmap argument.
          520|4 5 00014017 1 7|METH: Verify that a BadColor error occurs.
          520|4 5 00014017 1 8|unexpected signal 6 (SIGABRT) received
          220|4 5 2 15:05:53|UNRESOLVED
          410|4 5 1 15:05:53|IC End
          510|4|system 0: Abandoning testset: caught unexpected signal 11 (SIGSEGV)
      
      More specifically:
      
          lt-XCopyColormapAndFree: xcb_io.c:533: _XAllocID: Assertion `ret != inval_id' failed.
      
      This bug was introduced (by following my advice, d'oh) in:
      
          commit 99a2cf1a
          Author: Tapani Pälli <tapani.palli@intel.com>
          Date:   Mon May 13 08:29:49 2019 +0300
      
              Protect colormap add/removal with display lock
      
      In that patch we moved the call to _XcmsCopyCmapRecAndFree inside the
      display lock. The problem is said routine has side effects, including
      trying to implicitly create a colormap in some cases. Since we don't run
      the XID handler until SyncHandle() we would see inconsistent internal
      xlib state, triggering the above assert.
      
      Fix this by dropping and re-taking the display lock before calling into
      XCMS.
      Reviewed-by: Tapani Pälli's avatarTapani Pälli <tapani.palli@intel.com>
      68c72a73
  4. 01 Jan, 2020 1 commit
  5. 22 Dec, 2019 1 commit
    • Peter Hutterer's avatar
      Handle ssharp in XConvertCase() · a48787d3
      Peter Hutterer authored
      lowercase: LATIN SMALL LETTER SHARP S (U+00DF)
      uppercase: LATIN CAPITAL LETTER SHARP S (U+1E9E)
      
      The uppercase sharp s (XK_ssharp) is a relatively recent addition to unicode
      but was added to the relevant keyboard layouts in xkeyboard-config-2.25
      (d1411e5e95c)
      xkeyboard-config/xkeyboard-config#144
      
      Alas, the CapsLock behavior was broken on the finnish layout (maybe others).
      This was due to xkbcomp using XConvertCase() to determine whether a key
      requires the type FOUR_LEVEL_ALPHABETIC or FOUR_LEVEL_SEMIALPHABETIC.
      
      Let's make this function return the right lower/upper symbols for the sharp s
      and hope that the world won't get any worse because of it.
      
      #110Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a48787d3
  6. 09 Oct, 2019 3 commits
    • Raul Fernandes's avatar
      Use memcmp and memcpy · b8766a43
      Raul Fernandes authored
      b8766a43
    • Adam Jackson's avatar
      libX11 1.6.9 · db7cca17
      Adam Jackson authored
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      db7cca17
    • Dmitry Osipenko's avatar
      Fix lockup in _XReply() caused by recursive synchronization · f5ba2c63
      Dmitry Osipenko authored
      This patch is based on a suggestion made by Uli Schlachter in a comment
      to the bug report #93.
      
      Explanation of the bug (given by Uli Schlachter as well):
      
      An error was received and handled. Since there was an error callback set,
      Xlib unlocks the display, runs the error callback, and then locks the display
      again. This goes through _XLockDisplay and then calls _XSeqSyncFunction.
      On this "lock the thing"-path, Xlib notices that sequence numbers are close to
      wrap-around and tries to send a GetInputFocus request. However, the earlier
      calls already registered themselves as "we are handling replies/errors, do
      not interfere!" and so the code here waits for "that other thread" to be done
      before it continues. Only that there is no other thread, but it is this thread
      itself and thus a deadlock follows.
      
      The bug is relatively easy to reproduce on any desktop environment by
      using actively a touchscreen input that supports multitouch, i.e. practically
      all mobile devices are affected.
      
      Fixes: #93Suggested-by: Uli Schlachter's avatarUli Schlachter <psychon@znc.in>
      Tested-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Reported-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: Dmitry Osipenko's avatarDmitry Osipenko <digetx@gmail.com>
      f5ba2c63
  7. 24 Sep, 2019 1 commit
  8. 06 Aug, 2019 1 commit
    • Ross Burton's avatar
      src/util/Makefile: explicitly reset LINK to not use libtool · edc7680e
      Ross Burton authored
      Simply looking at libtool redefines LINK globally to use libtool, which when
      you're trying to cross-compile to Windows can cause complications.
      
      As in src/util/ we're simply building a small binary for the build host, reset
      LINK to the automake default so that the traditional compile/link steps occur
      without libtool.
      
      Also remove -all-static from LDFLAGS as that is a libtool-specific argument
      intended to solve this problem.
      
      Closes: #100Signed-off-by: default avatarRoss Burton <ross.burton@intel.com>
      edc7680e
  9. 30 Jul, 2019 6 commits
  10. 29 Jul, 2019 4 commits
  11. 03 Jul, 2019 2 commits
  12. 22 Jun, 2019 1 commit
  13. 21 Jun, 2019 1 commit
  14. 17 Jun, 2019 2 commits
  15. 09 Jun, 2019 4 commits
    • Matt Turner's avatar
      Use AC_SYS_LARGEFILE · 5464b302
      Matt Turner authored
      ... and include config.h in makekeys.c to get the definition of
      _FILE_OFFSET_BITS. Without it, libX11 can fail to build on a file
      system with 64-bit inode numbers.
      
      Bug: https://bugs.gentoo.org/550502
      Bug: https://bugs.gentoo.org/616140Signed-off-by: Matt Turner's avatarMatt Turner <mattst88@gmail.com>
      5464b302
    • Ran Benita's avatar
      Compose.man: fix escaped hexadecimal char description · 33b9148a
      Ran Benita authored
      The man page says:
          Strings may be direct text encoded in the locale for which the
          compose file is to be used, or an escaped octal or hexadecimal
          character code.   Octal codes are specified as "\123" and
          hexadecimal codes as "\0x123a".
      
      But the grammar in the parser and the implementation say:
          ESCAPED_CHAR  ::= ('\\' | '\"' | OCTAL | HEX )
          HEX           ::= '\' (x|X) HEX_CHAR [HEX_CHAR]]
          HEX_CHAR      ::= (0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|a|b|c|d|e|f)
      
      So "\0x123a" -> "\x3a".
      Signed-off-by: default avatarRan Benita <ran234@gmail.com>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      33b9148a
    • ojab's avatar
      Compose sequences for rouble sign · d9b2cc35
      ojab authored
      Cyrillic combinations mirror the Qwerty-Jcuken keyboard layout.
      Signed-off-by: ojab's avatarSlava Kardakov <ojab@ojab.ru>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      d9b2cc35
    • Pavel Labath's avatar
      Fix a leak in XCreateFontSet · 3f211616
      Pavel Labath authored
      a simple snippet like XFreeFontSet(d, XCreateFontSet(d, ...)) will generate lots of memory leaks,
      as evidenced by the following valgrind output:
      ==983== HEAP SUMMARY:
      ==983==     in use at exit: 39,409 bytes in 341 blocks
      ==983==   total heap usage: 4,795 allocs, 4,454 frees, 489,086 bytes allocated
      ==983==
      ==983== 1,688 (136 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record
      40 of 46
      ==983==    at 0x4C2B042: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==983==    by 0x56D5A93: add_codeset.clone.9 (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D5FE0: load_generic (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D7612: initialize (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56D7E75: _XlcCreateLC (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56F9A5F: _XlcUtf8Loader (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56DF815: _XOpenLC (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56B255A: XOpenOM (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x56A665A: XCreateFontSet (in /usr/lib64/libX11.so.6.3.0)
      ==983==    by 0x4FCA80: conky::x11_output::create_gc() (x11.cc:746)
      ==983==    by 0x4FC3B4: conky::x11_output::use_own_window() (x11.cc:602)
      ==983==    by 0x4FAD42: conky::priv::own_window_setting::set(bool const&, bool) (x11.cc:92)
      ==983==
      ==983== LEAK SUMMARY:
      ==983==    definitely lost: 136 bytes in 1 blocks
      ==983==    indirectly lost: 1,552 bytes in 34 blocks
      ==983==      possibly lost: 0 bytes in 0 blocks
      ==983==    still reachable: 37,721 bytes in 306 blocks
      ==983==         suppressed: 0 bytes in 0 blocks
      
      This patch makes the leak dissappear (Well, at least the "definitely lost part". The "still
      reachable" thingy remains). After some analysis, I've discovered that the XLCd structure is
      destroyed improperly. The "constructor" is in lcGeneric.c, but the structure is destroyed using
      code from lcPublic.c. I've found that changing the destructor call to _XlcDestroyLC executes the
      correct code path, and I'm pretty sure this is correct (the object was constructed using
      _XlcCreateLC, it make sense to destroy it using its conterpart).
      
      So far I haven't observed any strange behaviour on my system caused by this change (although, I'm
      not sure, how many programs actually use this function).
      Signed-off-by: default avatarPavel Labath <pavelo@centrum.sk>
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      3f211616
  16. 08 Jun, 2019 3 commits
    • Jon Turney's avatar
      Avoid using libtool wrapper for makekeys · 4645e219
      Jon Turney authored
      For Windows targets, libtool uses a wrapper executable, not a wrapper
      script (see [1]), which it compiles with the host compiler.  This
      doesn't work when cross-compiling.
      
      Since we don't actually need to link with anything, use the libtool flag
      -all-static to tell it to stay completely out of this.
      
      [1] https://www.gnu.org/software/libtool/manual/html_node/Wrapper-executables.html
      4645e219
    • Jon Turney's avatar
      Use EXEEXT_FOR_BUILD for makekeys · 6886d9ba
      Jon Turney authored
      Use EXEXT_FOR_BUILD, to fix cross-compiling where EXEEXT differs from
      EXEEXT_FOR_BUILD, such as when building for Windows from unix.
      
      (Note: As written, this assumes EXEEXT_FOR_BUILD is always empty when
      cross-compiling.  There could be some elaborate autodetection for
      EXEXT_FOR_BUILD, but for the moment, if you are cross-compiling from
      Windows to Unix, you'll need to set EXEEXT_FOR_BUILD explicity...)
      6886d9ba
    • Jon Turney's avatar
      Remove makekeys dependency on X headers · a121b7b0
      Jon Turney authored
      This is the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6669
      by Pierre Ossman, reworked for master.
      
      Avoid using LIBS (which are for host, but we don't need) and rewrite
      makekeys slightly to avoid needing to include any X headers, which
      avoids potentially having -I with host paths in CFLAGS, which can cause
      standard headers e.g. stdio.h for the host to also be used, which can
      break things...
      a121b7b0
  17. 07 Jun, 2019 1 commit
  18. 14 May, 2019 1 commit
  19. 30 Apr, 2019 1 commit