This causes issues when compiling code for C++17.
While here, make function prototype match the header with regards
to removal of another register keyword.
The check here guards the read below.
For `XimType_XIMStyles`, these are `num` of `CARD32` and for `XimType_XIMHotKeyTriggers`
these are `num` of `XIMTRIGGERKEY` ref[1] which is defined as 3 x `CARD32`.
(There are data after the `XIMTRIGGERKEY` according to the spec but they are not read by this
function and doesn't need to be checked.)
The old code here used the native datatype size instead of the wire protocol size causing
the check to always fail.
Also fix the size calculation for the header (size). It is 2 x CARD16 for both types
despite the unused `CARD16` for `XimType_XIMStyles`.
[1] https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html#Input_Method_Styles
This fixes a regression caused by 388b303c62 in 1.6.10.
Fix#116
It's coming from a length in the protocol (unsigned) and passed
to functions that expect unsigned int parameters (_XCopyToArg()
and memcpy()).
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Todd Carson <toc@daybefore.net>
It looks like uninitialized stack or heap memory can leak
out via padding bytes.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
The lengths are unsigned according to the specification. Passing
negative values can lead to data corruption.
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
U+23BA - U+23BD are meant to represent the scan lines, and U+2500 is
unified with scan line 5.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
cbb59d172 ('Braille: Fix typing quickly') broke the default lookup that
translates Braille keysym patterns to Braille Unicode patterns since it
rightfully clears brl_committing, but then we do not have it any more to
fill brl_committed.
This change saves the committed pattern so we can return it in the
default lookup.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
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 99a2cf1aa0
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 <tapani.palli@intel.com>
lowercase: GREEK SMALL LETTER FINAL SIGMA (U+03C2)
uppercase: GREEK CAPITAL LETTER SIGMA (U+03A3)
This mapping was correct in UCSConvertCase, but the "legacy" mapping
must also be correct for Caps Lock to work with the final sigma key.
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/5
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
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)
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/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.
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/110
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch is based on a suggestion made by Uli Schlachter in a comment
to the bug report https://gitlab.freedesktop.org/xorg/lib/libx11/issues/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: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/93
Suggested-by: Uli Schlachter <psychon@znc.in>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
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: #100
Signed-off-by: Ross Burton <ross.burton@intel.com>
to remove the fake quotes replace them with propper
predefined macros \*(lq and \*(rq. this will allow
nroff to choose the propper characters when using ps etc.
Signed-off-by: Walter Harms <wharms@bfs.de>
after converting everything to st. man page macros there is
no need to maintain X11 private nroff macros, so remove them.
Signed-off-by: Walter Harms <wharms@bfs.de>
Same pages use the man page .EX/.EE macro. Replace all occurences
of .De/.Ds with the std. macros to make the code better to maintain.
Signed-off-by: Walter Harms <wharms@bfs.de>
Replace the home grown macro .ZN with std. macros
from man macro paket. So we can get rid of the
definition an get a clean header.
Signed-off-by: Walter Harms <wharms@bfs.de>
Subsequent to a121b7b0c2 we are no longer
building makekeys with enough -I/foo/bar to find the X11 headers, so if
they're not in a system include path, things fail. Since this utility is
only needed at build time, there's no real reason to demand the X
headers be installed for both the build and target machines if cross-
compiling, we can just assume a vaguely ANSI environment instead.
Tested-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
... 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/616140
Signed-off-by: Matt Turner <mattst88@gmail.com>
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: Ran Benita <ran234@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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: Pavel Labath <pavelo@centrum.sk>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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
