Update to libX11 1.8.10. tested by and ok rsadowski@

1 files changed, 559 insertions, 0 deletions

diff --git a/lib/libX11/ChangeLog b/lib/libX11/ChangeLog
index c314f0a9a..49b87dec4 100644
--- a/lib/libX11/ChangeLog
+++ b/lib/libX11/ChangeLog
@@ -1,3 +1,562 @@
+commit ed9fb5535efe1e5278654b6b3994a34337b4bf1a
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date:   Sun Jul 28 10:37:55 2024 -0700
+
+    libX11 1.8.10
+    
+    Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
+
+commit 92014b39634e0b0aa52d4bff955a7aac3ed0a915
+Author: Kelly Roadkill <roadkell@pm.me>
+Date:   Tue Jul 23 08:12:01 2024 +0500
+
+    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>
+
+commit be137dffa6f0b7640ce80b4266539009544bb045
+Author: Kelly Roadkill <roadkell@pm.me>
+Date:   Fri Jul 19 16:47:40 2024 +0500
+
+    nls: add compose sequences for hryvnia currency
+    
+    Part-of: <https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/259>
+
+commit 39d57cbeda627115f7e8bd305b6cbd9df1daa007
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date:   Sat Jul 13 10:14:02 2024 -0700
+
+    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>
+
+commit 8abcaba1a7ee363a35ad8d869715095096995c76
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date:   Sat Jul 6 09:37:50 2024 -0700
+
+    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>
+
+commit 751fbc59c30604980fdd19cb4b333d3cf2eccb24
+Author: Olivier Fourdan <ofourdan@redhat.com>
+Date:   Fri Jun 21 14:37:24 2024 +0200
+
+    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>
+
+commit bc8c908ae8007d0bfe9b58c7752dd00fd282d999
+Author: Kelly Roadkill <roadkell@pm.me>
+Date:   Tue Jun 18 14:49:50 2024 +0500
+
+    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>
+
+commit 1472048b7a02d1b7fc25cfeda761db23fba21eac
+Author: Olivier Fourdan <ofourdan@redhat.com>
+Date:   Fri Jun 7 09:05:55 2024 +0200
+
+    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>
+
+commit 739fce4c12c7aa39112353d80c8a3bf25bdd5274
+Author: Olivier Fourdan <ofourdan@redhat.com>
+Date:   Fri Jun 7 09:07:39 2024 +0200
+
+    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>
+
+commit 5dfedaf4aa1a032ea6cb4e871abd2e065f798129
+Author: Olivier Fourdan <ofourdan@redhat.com>
+Date:   Thu Jun 6 16:25:26 2024 +0200
+
+    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>
+
+commit c099d0105f7a4f969cf922f333cb54c177aceacb
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date:   Sat May 18 11:41:36 2024 -0700
+
+    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>
+
+commit 0af3328dc330cbd8e097e2971b336b44466b1ab0
+Author: jmcwilliams403 <jmcwilliams403@gmail.com>
+Date:   Sun Jul 16 11:31:22 2023 -0400
+
+    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>
+
+commit 174df0b8b6ada7e1c741373c7d686e00f42d8bd5
+Author: Kelly Roadkill <roadkell@pm.me>
+Date:   Sun Dec 3 00:53:55 2023 +0500
+
+    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>
+
+commit 763f3f938c24993e9ceb1d6960d939b022fa8dfe
+Author: Mohamed Akram <mohd.akram@outlook.com>
+Date:   Fri May 24 18:18:43 2024 +0400
+
+    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>
+
+commit 97fb5bda3d0777380cd4b964f48771a82ef3f2a7
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 18:21:08 2024 +0200
+
+    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>
+
+commit f67a87dad40141f50f4da35b28a92a974bfdf7e1
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 18:04:35 2024 +0200
+
+    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>
+
+commit af1312d2873d2ce49b18708a5029895aed477392
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 17:37:39 2024 +0200
+
+    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>
+
+commit 836a8f2cf5e930c8a56b512273fdf9890282ba04
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 16:49:26 2024 +0200
+
+    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>
+
+commit eaad761e24722b1743d3edee3383294bfb4947d6
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 16:41:40 2024 +0200
+
+    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>
+
+commit 4f5541193dd5a004ed5ea44c12fc25e227113c9b
+Author: José Expósito <jexposit@redhat.com>
+Date:   Tue Apr 30 16:37:21 2024 +0200
+
+    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>
+
+commit 90b8fc65da1e773b0091a50be46b23609591e8b7
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 26 01:29:39 2024 +0900
+
+    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>
+
+commit 898746f9b1fb384d6d24ed827c836ec8a0b3da3b
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 26 01:29:34 2024 +0900
+
+    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>
+
+commit 5a1e62d77b65ba148b1c6d1d22a81dc2b07e7d9e
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 26 01:29:26 2024 +0900
+
+    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>
+
+commit 5a14178c7cc408f425fe298aeade3dee749b1ca1
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 26 00:49:14 2024 +0900
+
+    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>
+
+commit 1181abd6ffede3ac5663a3a3d4ee66aef1fa553b
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 12 10:50:33 2024 +0900
+
+    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>
+
+commit c7790072657f9fdbe8cda031776617088c5f11db
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 12 10:21:43 2024 +0900
+
+    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>
+
+commit 13e9ac4d458069c81d795f6b4842814d30431b4b
+Author: Takao Fujiwara <tfujiwar@redhat.com>
+Date:   Fri Apr 12 10:21:41 2024 +0900
+
+    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>
+
 commit a465588218c1643eedc35b3c24409cb775454eee
 Author: Alan Coopersmith <alan.coopersmith@oracle.com>
 Date:   Fri Apr 5 15:50:06 2024 -0700