-
1261802f
by Walter Harms at 2024-01-07T18:30:30+01:00
fix table width
the width of first column was to small and
caused a hyphenation. there is only one word,
fix for me.
-
e6310b52
by Walter Harms at 2024-01-08T13:06:03+01:00
_XimLocalDestroyIC: no need to check arg for Xfree()
Xfree() will happily ignore NULL, no need to check
-
e5b14e59
by Walter Harms at 2024-01-08T13:35:28+01:00
_XimLocalCreateIC:no need to check arg for Xfree()
Xfree() will happily ignore NULL, no need to check
-
59c9a89e
by Walter Harms at 2024-01-08T15:09:49+01:00
_XimLocalCreateIC: minor cleanup
minor cleanup, no code change
-
07978634
by Walter Harms at 2024-01-08T15:16:11+01:00
_XimLocalCreateIC: get rid of bzero
-
ed0b97e4
by Walter Harms at 2024-01-08T16:21:02+01:00
_XimLocalDestroyIC:fix possible mem leak
Adapted:
Fix XCreateIC() memory leak by Patrick Lerda <patrick9876@free.fr> Part 1
-
4f78b615
by Walter Harms at 2024-01-08T16:50:52+01:00
Fix XCreateIC() memory leak (Part 2)
Direct leak of 12 byte(s) in 2 object(s) allocated from:
#0 0x7f4f25c3f7a7 in strdup (/usr/lib64/libasan.so.6+0x5c7a7)
#1 0x7f4f252ce6a1 in _XimEncodeString libX11-1.8.3/modules/im/ximcp/imRm.c:818
#2 0x7f4f252ce6a1 in _XimEncodeString libX11-1.8.3/modules/im/ximcp/imRm.c:807
#3 0x7f4f252d2f0f in _XimSetICValueData libX11-1.8.3/modules/im/ximcp/imRm.c:2912
#4 0x7f4f252b536a in _XimLocalCreateIC libX11-1.8.3/modules/im/ximcp/imLcIc.c:176
#5
0x7f4f251f0105 in XCreateIC libX11-1.8.3/src/xlibi18n/ICWrap.c:251
detected and fix by Patrick Lerda <patrick9876@free.fr>
applied with adjustment, do changes when OOM (unlikely but good practise)
-
dce61462
by Walter Harms at 2024-01-08T17:01:44+01:00
_XimEncodeString:no need to check arg for Xfree()
Xfree() will happily ignore NULL, no need to check
-
0a951047
by Walter Harms at 2024-01-08T17:18:19+01:00
_XimProtoIMFree:no need to check arg for Xfree()
Xfree() will happily ignore NULL, no need to check
-
ae3eca18
by Peter Hutterer at 2024-01-18T00:07:04+00:00
Fix _XkbReadGetDeviceInfoReply for nButtons == dev->buttons
XkbGetDeviceInfo(dpy, XkbXI_ButtonActionsMask, 2, 0, 0) always returns
NULL because the number of buttons on the device equals (unsurpisingly)
the number of buttons requested (i.e. first + nBtns == dev->nbuttons).
This currently causes it to bail out and return NULL.
Fixes f293659d5a4024bda386305bb7ebeb4647c40934
-
024d229f
by Takao Fujiwara at 2024-01-31T20:26:40+09:00
ximcp: Unmark to fabricate key events with XKeyEvent serial
_XimProtoKeypressFilter() and _XimProtoKeyreleaseFilter() can
receive XKeyEvent from both the typing on the keyboard and the
callback of XIM_FORWARD_EVENT.
If the filter functions unmark to fabricate XKeyEvent from the typing
on the keyboard during receiving XKeyEvent from the callback of
XIM_FORWARD_EVENT with typing keys very quickly likes an bar code
scanner (or evemu-play), XIM server cannot receive some key events and
it causes the key typing order to get scrambled.
Now XIM client saves the serial in XKeyEvent and the filter functions
unmark to fabricate XKeyEvent from the callback of XIM_FORWARD_EVENT
only.
Fixes: #198
-
041b5291
by Takao Fujiwara at 2024-01-31T20:27:57+09:00
imDefLkup: Commit first info in XimCommitInfo
Xic.private.proto.commit_info can receive multiple XimCommitInfo
when typing keys very quickly like an bar code scanner (or evemu-play)
and the first info in XimCommitInfo should be committed to keep
the typing key order.
Fixes: #198
-
b35344c9
by Alan Coopersmith at 2024-02-11T14:47:31-08:00
unifdef __osf__
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
c3f3eb12
by Alan Coopersmith at 2024-02-11T14:49:13-08:00
unifdef AIXV3
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
0df284b4
by Alan Coopersmith at 2024-02-11T14:50:29-08:00
unifdef ultrix
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
225a4bbb
by Alan Coopersmith at 2024-02-11T14:56:22-08:00
unifdef __UNIXOS2__
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
613d3624
by Alan Coopersmith at 2024-02-20T17:05:42-08:00
unifdef hpux
Also removes shl_load() support, which was only buildable for HP-UX
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
4322fff7
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef sgi
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
3296d7b8
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef __sgi
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
65a6f162
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef __sgi_not_xconsortium
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
4ce3962b
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef __vax__
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
ab0a3014
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef __uxp__
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
1e56b274
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef __QNX__
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
4400a68b
by Alan Coopersmith at 2024-02-20T17:05:50-08:00
unifdef Lynx
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
7bb2a505
by Alan Coopersmith at 2024-02-21T18:18:46-08:00
unifdef USL_SHAREDLIB
I can't find any history of this being set in the imake or autoconf builds
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
4ab58f26
by Alan Coopersmith at 2024-02-21T18:23:36-08:00
unifdef NULL_NOT_ZERO
I can't find any evidence this was ever defined, should only have
been needed for odd-ball pre-C89 compilers.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
e4927d0c
by Alan Coopersmith at 2024-03-24T15:02:23-07:00
libX11 1.8.8
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
9afd55ad
by Alan Coopersmith at 2024-03-25T11:51:03-07:00
xlibi18n: restore parse_line1 for WIN32 builds
Accidentally removed by __UNIXOS2__ cleanup
Closes: #204
Fixes: 225a4bbb ("unifdef __UNIXOS2__")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
3ea9f4f7
by Peter Hutterer at 2024-04-05T13:17:07+10:00
Revert "imDefLkup: Commit first info in XimCommitInfo"
This commit causes a regression, see #205, #206, #207, #208.
This reverts commit 041b5291f0956c5cda5054be2981c0d02b009a4c.
-
52a191ee
by Peter Hutterer at 2024-04-05T13:18:48+10:00
Revert "ximcp: Unmark to fabricate key events with XKeyEvent serial"
This commit causes a regression, see #205, #206, #207, #208.
This reverts commit 024d229fdf88a7755577b01b46af6ef908d599e0.
-
a4655882
by Alan Coopersmith at 2024-04-05T15:50:06-07:00
libX11 1.8.9
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
-
13e9ac4d
by Takao Fujiwara at 2024-04-12T10:21:41+09:00
ximcp: Unmark to fabricate key events with XKeyEvent serial
_XimProtoKeypressFilter() and _XimProtoKeyreleaseFilter() can
receive XKeyEvent from both the typing on the keyboard and the
callback of XIM_FORWARD_EVENT.
If the filter functions unmark to fabricate XKeyEvent from the typing
on the keyboard during receiving XKeyEvent from the callback of
XIM_FORWARD_EVENT with typing keys very quickly likes an bar code
scanner (or evemu-play), XIM server cannot receive some key events and
it causes the key typing order to get scrambled.
Now XIM client saves the serial in XKeyEvent and the filter functions
unmark to fabricate XKeyEvent from the callback of XIM_FORWARD_EVENT
only.
This and 024d229f are same patches but the regression issues will be
fixed by the later patches.
Closes: #198
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
c7790072
by Takao Fujiwara at 2024-04-12T10:21:43+09:00
imDefLkup: Commit first info in XimCommitInfo
Xic.private.proto.commit_info can receive multiple XimCommitInfo
when typing keys very quickly like an bar code scanner (or evemu-play)
and the first info in XimCommitInfo should be committed to keep
the typing key order.
This and 041b5291 are same patches but the regression issues will be
fixed by the later patches.
Closes: #198
Fixes: 041b5291 ("imDefLkup: Commit first info in XimCommitInfo")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
1181abd6
by Takao Fujiwara at 2024-04-12T10:50:33+09:00
imDefLkup: Mark and unmark fabricated with serial 0
GTK2 applications with GTK_IM_MODULE=xim sets the serial number 0
to the XKeyEvent and the previous _XimFabricateSerial() logic did
not work for the applications.
Now the API marks to fabricate with the serial 0.
Closes: #205
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
5a14178c
by Takao Fujiwara at 2024-04-26T00:49:14+09:00
ximcp: Add fabricated_time in XimProtoPrivate for timeout
When users type keys quickly, some applications using Steam or Java
do not call XNextEvent() for a key event but _XimFilterKeypress()
and _XimFilterKeyrelease() expect to receive the key events
forwarded by input methods.
Now fabricated_time Time value is added to XimProtoPrivate to check
the timeout value.
Closes: #205
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
5a1e62d7
by Takao Fujiwara at 2024-04-26T01:29:26+09:00
Accept anon windows in XFilterEvent to update XIM state
When input focuses are switched quickly with shortcut keys in a Java
window, the focus is sometimes lost and the Window=0 is assigned in
XFilterEvent() but the XKeyEvent was forwarded by a XIM serer(IBus)
with XIM_FORWARD_EVENT -> XNextEvent() -> XFilterEvent() and the event
needs to be forwarded to the XIM XKeyEvent press and release filters
to update the XIM state with Window=0 likes _XimPendingFilter() and
_XimUnfabricateSerial().
Closes: #205, #206
Fixes: 024d229f ("ximcp: Unmark to fabricate key events with XKeyEvent serial")
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
898746f9
by Takao Fujiwara at 2024-04-26T01:29:34+09:00
ximcp: Unmark fabricated with serial 0 and Xic commit_info
GTK2 XIM resets the XKeyEvent serial to 0 even if _XimCommitRecv()
sets the serial so now checks if the events are sent with
Xic->private.proto.commit_info.
Closes: !246
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
90b8fc65
by Takao Fujiwara at 2024-04-26T01:29:39+09:00
imDefIm: Add LIBX11_ENABLE_FABRICATED_ORDER env
If an XIM application does not return the XKeyEvent from XNextEvent()
to XFilterEvent(), a timeout is reached and the behavior is fallen
back to the previous one with a warning messsage and we can ask
the application to send the XKeyEvent to XFilterEvent() but also
libX11 provides LIBX11_ENABLE_FABRICATED_ORDER environment variable.
If the application runs with LIBX11_ENABLE_FABRICATED_ORDER=0, the
previous behavior is available until the application is fixed.
Closes: !246
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/246>
-
4f554119
by José Expósito at 2024-05-07T08:54:50+00:00
Fix use of uninitialized variable in _XimTriggerNotify
`_XimRead()` is being called with `reply` as target buffer instead of
using `preply`, accessing uninitialized memory a few lines later.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:561: alloc_fn:
Calling "malloc" which returns uninitialized memory.
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:561: assign:
Assigning: "preply" = "malloc((size_t)((len == 0) ? 1 : len))",
which points to uninitialized data.
libX11-1.8.7/modules/im/ximcp/imDefLkup.c:573: uninit_use:
Using uninitialized value "*((CARD8 *)preply)".
# 571| }
# 572| buf_s = (CARD16 *)((char *)preply + XIM_HEADER_SIZE);
# 573|-> if (*((CARD8 *)preply) == XIM_ERROR) {
# 574| _XimProcError(im, 0, (XPointer)&buf_s[3]);
# 575| if(reply != preply)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
eaad761e
by José Expósito at 2024-05-07T08:54:50+00:00
Fix use of uninitialized variable in _XimExtension
`_XimRead()` is being called with `reply` as target buffer instead of
using `preply`, accessing uninitialized memory a few lines later.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imExten.c:468: alloc_fn:
Calling "malloc" which returns uninitialized memory.
libX11-1.8.7/modules/im/ximcp/imExten.c:468: assign:
Assigning: "preply" = "malloc((size_t)((buf_size == 0) ? 1 : buf_size))",
which points to uninitialized data.
libX11-1.8.7/modules/im/ximcp/imExten.c:479: uninit_use:
Using uninitialized value "*((CARD8 *)preply)".
# 477| return False;
# 478| buf_s = (CARD16 *)((char *)preply + XIM_HEADER_SIZE);
# 479|-> if (*((CARD8 *)preply) == XIM_ERROR) {
# 480| _XimProcError(im, 0, (XPointer)&buf_s[3]);
# 481| if(reply != preply)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
836a8f2c
by José Expósito at 2024-05-07T08:54:50+00:00
Fix use of uninitialized variable in _XimEncodeICATTRIBUTE
In the `res->resource_size == XimType_NEST` code path, if
`res->xrm_name != pre_quark` and `res->xrm_name != sts_quark`, `len` can
be used uninitialized.
This error has been found by a static analysis tool. This is the report:
Error: UNINIT (CWE-457):
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1106: var_decl:
Declaring variable "len" without initializer.
libX11-1.8.7/modules/im/ximcp/imRmAttr.c:1179: uninit_use:
Using uninitialized value "len".
# 1177| }
# 1178|
# 1179|-> if (len == 0) {
# 1180| continue;
# 1181| } else if (len < 0) {
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
af1312d2
by José Expósito at 2024-05-07T08:54:50+00:00
XKBMAlloc: Check that needed is >= 0 in XkbResizeKeyActions
Passing a negative value in `needed` to the `XkbResizeKeyActions()`
function can create a `newActs` array of an unespected size.
Check the value and return if it is invalid.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: cond_const:
Checking "xkb->server->size_acts == 0" implies that
"xkb->server->size_acts" is 0 on the true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: buffer_alloc:
"calloc" allocates 8 bytes dictated by parameters
"(size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts)"
and "8UL".
libX11-1.8.7/src/xkb/XKBMAlloc.c:811: var_assign:
Assigning: "newActs" = "calloc((size_t)((xkb->server->size_acts == 0) ? 1 : xkb->server->size_acts), 8UL)".
libX11-1.8.7/src/xkb/XKBMAlloc.c:815: assignment:
Assigning: "nActs" = "1".
libX11-1.8.7/src/xkb/XKBMAlloc.c:829: cond_at_least:
Checking "nCopy > 0" implies that "nCopy" is at least 1 on the
true branch.
libX11-1.8.7/src/xkb/XKBMAlloc.c:830: overrun-buffer-arg:
Overrunning buffer pointed to by "&newActs[nActs]" of 8 bytes by
passing it to a function which accesses it at byte offset 15
using argument "nCopy * 8UL" (which evaluates to 8).
# 828|
# 829| if (nCopy > 0)
# 830|-> memcpy(&newActs[nActs], XkbKeyActionsPtr(xkb, i),
# 831| nCopy * sizeof(XkbAction));
# 832| if (nCopy < nKeyActs)
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
f67a87da
by José Expósito at 2024-05-07T08:54:50+00:00
Fix memory leak in _XimProtoSetIMValues
This error has been found by a static analysis tool. This is the report:
Error: RESOURCE_LEAK (CWE-772):
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: alloc_fn:
Storage is returned from allocation function "calloc".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1316: var_assign:
Assigning: "tmp" = storage returned from
"calloc((size_t)((buf_size + data_len == 0) ? 1 : (buf_size + data_len)), 1UL)".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1319: noescape:
Resource "tmp" is not freed or pointed-to in "memcpy".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1320: var_assign:
Assigning: "buf" = "tmp".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1302: var_assign:
Assigning: "data" = "buf".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1303: noescape:
Resource "data" is not freed or pointed-to in
"_XimEncodeIMATTRIBUTE".
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "data" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "buf" going out of scope leaks the storage it points to.
libX11-1.8.7/modules/im/ximcp/imDefIm.c:1333: leaked_storage:
Variable "tmp" going out of scope leaks the storage it points to.
# 1331|
# 1332| if (!total)
# 1333|-> return (char *)NULL;
# 1334|
# 1335| buf_s = (CARD16 *)&buf[XIM_HEADER_SIZE];
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
97fb5bda
by José Expósito at 2024-05-07T08:54:50+00:00
Fix buffer overrun in parse_omit_name
When `num_fields == 12`, if the last character of the pattern is '-',
the `buf` array is overrun.
This error has been found by a static analysis tool. This is the report:
Error: OVERRUN (CWE-119):
libX11-1.8.7/modules/om/generic/omGeneric.c:691: cond_at_most:
Checking "length > 255" implies that "length" may be up to 255 on
the false branch.
libX11-1.8.7/modules/om/generic/omGeneric.c:695: alias:
Assigning: "last" = "buf + length - 1". "last" may now point to as
high as byte 254 of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:718: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 255
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: ptr_incr:
Incrementing "last". "last" may now point to as high as byte 256
of "buf" (which consists of 256 bytes).
libX11-1.8.7/modules/om/generic/omGeneric.c:720: overrun-local:
Overrunning array of 256 bytes at byte offset 256 by
dereferencing pointer "++last".
# 718| *++last = '*';
# 719|
# 720|-> *++last = '-';
# 721| break;
# 722| case 13:
Signed-off-by: José Expósito <jexposit@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>
-
763f3f93
by Mohamed Akram at 2024-05-24T18:18:43+04:00
nls: add Arabic hamza compose sequences
These sequences are intended for use in the ara(mac-phonetic) and
my(phonetic) layouts. They are based on the following layouts listed in
the CLDR:
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ar-t-k0-osx-qwerty.xml
- https://github.com/unicode-org/cldr/blob/release-43/keyboards/osx/ms-t-k0-osx.xml
The sequences are listed in the `<transforms>` section, and are
reproduced below:
```
<transforms type="simple">
<transform from="ء\u{64E}" to="آ"/> <!-- ءَ → آ -->
<transform from="ء\u{650}" to="إ"/> <!-- ءِ → إ -->
<transform from="ء " to="ء"/>
<transform from="ء\u{A0}" to="ء"/>
<transform from="ء!" to="إ"/>
<transform from="ء١" to="إ"/>
<transform from="ءا" to="أ"/>
<transform from="ءس" to="ئ"/>
<transform from="ءو" to="ؤ"/>
<transform from="ءي" to="ئ"/>
<transform from="ءى" to="ئ"/>
</transforms>
```
We limit ourselves to the sequences that strictly combine a character
and a hamza, and generate that character with a hamza on it, following
the behavior in sequences of other dead keys. Additional sequences,
potentially for other layouts as well, could be added later on as
necessary.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/218>
-
174df0b8
by Kelly Roadkill at 2024-06-02T18:20:36+00:00
nls: add compose seq's for symbols absent from Cyrillic layouts to ru_RU
JCUKEN (ЙЦУКЕН) - the default and de-facto standard layout for most Cyrillic scripts - lacks a number of ASCII symbols from QWERTY counterpart, forcing users to switch back-and-forth between layouts to type them.
This adds sequences for them to the ru_RU compose map in an intuitive and consistent manner.
Fixes #200 for ru_RU (but other Cyrillic layouts might benefit too)
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/238>
-
0af3328d
by jmcwilliams403 at 2024-06-02T18:22:55+00:00
NLS: Add 6 Multi_key sequences for Ezh
Ezh is a Latin-Script letter belonging to several Uralic, Caucasian,
and West-African languages. It is present on some Finnish keyboards,
but users of many other layouts cannot presently type it. This commit
adds Multi_key sequences for both Capital and lowercase Ezh, as well
as Multi_key + dead_caron sequences for Ezh with a caron, which is
used in Laz and Skolt Sámi.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/221>
-
c099d010
by Alan Coopersmith at 2024-06-07T18:12:29+00:00
Avoid buffer overflow in _XimLookupMBText & _XimLookupUTF8Text
Reported-by: u32i <u32i@proton.me>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/251>
-
5dfedaf4
by Olivier Fourdan at 2024-06-15T00:10:17+00:00
Revert "Fix XTS regression in XCopyColormapAndFree"
This change was to fix the next change that we are to revert as well.
This reverts commit 68c72a7341b114277ab232f2499ee3bd035af8a0.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>
-
739fce4c
by Olivier Fourdan at 2024-06-15T00:10:17+00:00
Revert "Protect colormap add/removal with display lock"
That commit 99a2cf1aa was moving the calls to the _Xcms*CmapRec*()
family of functions within a display lock to make the XCMS colormap
functions thread safe.
Unfortunately, that causes a deadlock in XCopyColormapAndFree(), because
_XcmsCopyCmapRecAndFree() calls CmapRecForColormap() which calls
XGetVisualInfo() which also tries to acquire the display lock.
So, instead of moving the entire functions within the display lock,
let's try to make the functions themselves thread safe in the following
commit, and revert this change which causes a deadlock.
This reverts commit 99a2cf1aa0b58391078d5d3edf0a7dab18c7745d.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/215
See-also: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/94
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>
-
1472048b
by Olivier Fourdan at 2024-06-15T00:10:17+00:00
Make colormap private interfaces thread safe.
Protect access to the dpy structure by a display lock, so that these can
be called outside of a global display lock.
That allows the XCMS colormap functions to be thread safe without having
the whole functions within a display lock, to avoid deadlocks.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
See-also: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/215
See-also: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/94
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>
-
bc8c908a
by Kelly Roadkill at 2024-06-18T14:49:50+05:00
nls: delete compose sequence with anomalous post-fixed cedilla
The only sequence with post-fixed cedilla in the
whole en_US.UTF-8 was introduced in cf040016 with
the merge of GTK+ compose sequences 12 years ago.
It goes against the established patterns.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/255>
-
751fbc59
by Olivier Fourdan at 2024-06-24T08:58:11+02:00
Fix deadlock in XRebindKeysym()
Xlib is now built with threading support enabled from the constructor
by default.
XRebindKeysym() acquires the display lock, then calls:
| XRebindKeysym()
| LockDisplay()
| ComputeMaskFromKeytrans()
| -> XkbKeysymToModifiers()
| -> _XkbLoadDpy()
| -> XkbGetMap()
| -> XkbGetUpdatedMap()
| LockDisplay()
And the dead lock:
| Xlib ERROR: XKBGetMap.c line 575 thread 1fc6e580: locking display already
| locked at KeyBind.c line 937
To avoid the issue, call ComputeMaskFromKeytrans() from outside the display
lock.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/216
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/256>
-
8abcaba1
by Alan Coopersmith at 2024-07-06T09:37:50-07:00
Revert "unifdef __vax__"
This reverts commit 4ce3962b701c502acc96b6eaf104a5ffc317c5d7.
Requested by NetBSD which still has a supported VAX port.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/257>
-
39d57cbe
by Alan Coopersmith at 2024-07-13T10:14:02-07:00
xlibi18n/lcFile.c: avoid use of possibly-NULL pointer with strcpy
Fixes gcc warnings:
lcFile.c: In function ‘_XlcLocaleLibDirName’:
lcFile.c:708:5: warning: use of possibly-NULL ‘last_dir_name’ where
non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
708 | strcpy (last_dir_name, dir_name);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/258>
-
be137dff
by Kelly Roadkill at 2024-07-20T16:33:10+00:00
nls: add compose sequences for hryvnia currency
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/259>
-
92014b39
by Kelly Roadkill at 2024-07-23T08:12:01+05:00
Revert "nls: add compose seq's for symbols absent from Cyrillic layouts to ru_RU"
Testing by multilingual typists revealed that the
proposed sequences are too complex for everyday
use. It seems that the inherent problems with
JCUKEN can only be fixed with better kbd layouts.
This reverts commit 174df0b8b6ada7e1c741373c7d686e00f42d8bd5.
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/261>
-
ed9fb553
by Alan Coopersmith at 2024-07-28T10:37:55-07:00
libX11 1.8.10
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>