libX11-1.8.10

Signed-off-by: Alan Coopersmith <[email protected]>

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 174df0b8.

Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/261>

Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/259>

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/258>

This reverts commit 4ce3962b.
Requested by NetBSD which still has a supported VAX port.

Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/257>

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 <[email protected]>
Closes: https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/216
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/256>

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>

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 <[email protected]>
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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>

That commit 99a2cf1a 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 99a2cf1a.

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>

This change was to fix the next change that we are to revert as well.

This reverts commit 68c72a73.

Reviewed-by: Adam Jackson <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/254>

Reported-by: u32i <[email protected]>
Signed-off-by: Alan Coopersmith <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/251>

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>

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>

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>

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

`_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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

`_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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/250>

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>

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>

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>

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>

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>

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>

_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>

Signed-off-by: Alan Coopersmith <[email protected]>

This commit causes a regression, see #205, #206, #207, #208.

This reverts commit 024d229f.

This commit causes a regression, see #205, #206, #207, #208.

This reverts commit 041b5291.

Accidentally removed by __UNIXOS2__ cleanup
Closes: #204
Fixes: 225a4bbb ("unifdef __UNIXOS2__")

Signed-off-by: Alan Coopersmith <[email protected]>

Signed-off-by: Alan Coopersmith <[email protected]>

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 <[email protected]>

I can't find any history of this being set in the imake or autoconf builds

Signed-off-by: Alan Coopersmith <[email protected]>