diff options
Diffstat (limited to 'lib/libX11/ChangeLog')
| -rw-r--r-- | lib/libX11/ChangeLog | 559 |
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 |