libXt issueshttps://gitlab.freedesktop.org/xorg/lib/libxt/-/issues2023-04-28T15:44:01Zhttps://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/16XtTranslateKey not processing returned modifiers when compiled for Xkb2023-04-28T15:44:01ZAlex HajnalXtTranslateKey not processing returned modifiers when compiled for XkbFor some Xt/Xm programs[1] on some platforms[2] the numeric keypad is stuck in
navigation mode (irrespective of the NumLock state)[3]. I believe I've isolated
the source of the problem to `libXt`, specifically when it is compiled with...For some Xt/Xm programs[1] on some platforms[2] the numeric keypad is stuck in
navigation mode (irrespective of the NumLock state)[3]. I believe I've isolated
the source of the problem to `libXt`, specifically when it is compiled with Xkb
support.
The problem seems to lie in the `XtTranslateKey(...)` function (in
`src/TMkey.c`). When compiled with `Xkb` support this simply makes a call to
`XkbLookupKeySym(...)` and does no further processing. I believe that what it
should be doing is then processing the returned “list of modifiers that should
still be applied” (per the `XkbLookupKeySym(3)` manpage).[4]
To fix the issue I believe `XtTranslateKey(...)` should be doing additional
processing, similar to how it handles non-Xkb platforms or something like one
of the following functions:
* [`XLookupString(...)` in `libx11-1.7.5/src/xkb/XKBBind.c`](https://github.com/sulmone/X11/blob/master/libX11-1.5.0/src/xkb/XKBBind.c#L652)
* [`QKeyMapperPrivate::possibleKeysXKB`](https://dreamswork.github.io/qt4/qkeymapper__x11_8cpp_source.html#100273) (line 273)
---
Links to related bug reports:
* [nedit](https://sourceforge.net/p/nedit/bugs/692/)
* [xnedit](https://sourceforge.net/p/xnedit/bugs/27/)
* [nedit Debian](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807653)
---
[1] The programs I've seen affected are [nedit](https://sourceforge.net/projects/nedit/)
and [xnedit](https://github.com/unixwork/xnedit).
[2] This was first observed by myself on Ubuntu Linux 22.04 (`jammy`).
[3] Except for the `5` key which does follow `NumLock`.
[4] Manually editing that function to always use the first block of code (for
no Xkb support) instead of the latter (for Xkb support) makes the problem go
away for `nedit` (there is no change in `xnedit`'s behavior).https://gitlab.freedesktop.org/xorg/lib/libxt/-/issues/15Should XtCallbackReleaseCacheRefList free its argument?2023-01-02T21:53:42ZAlan CoopersmithShould XtCallbackReleaseCacheRefList free its argument?In the libXt spec, starting at https://gitlab.freedesktop.org/xorg/lib/libxt/-/blob/master/specs/CH09.xml#L2919 `XtCallbackReleaseCacheRefList()` is defined as a way to "explicitly decrement reference counts", but the current implementat...In the libXt spec, starting at https://gitlab.freedesktop.org/xorg/lib/libxt/-/blob/master/specs/CH09.xml#L2919 `XtCallbackReleaseCacheRefList()` is defined as a way to "explicitly decrement reference counts", but the current implementation also tries to free the list it's given:
https://gitlab.freedesktop.org/xorg/lib/libxt/-/blob/1aaf5d502027104ddd566090787780319f510278/src/Convert.c#L1106-1114
For nearly two decades now, we've been carrying around a change in the Solaris libXt that removes the free statement:
https://github.com/oracle/solaris-userland/blob/f82e11f/components/x11/lib/libXt/patches/05-15143893.patch
Unfortunately, the original author left the company long ago, but in our internal bug database, it appears this came up when submitting VSW5 results for certification to The Open Group, and getting a segfault in the `XtCallbackReleaseCacheRefList()` test because it had allocated the list on the stack, not with `malloc()`. It appears we were told then this was a bug in our implementation and that the function should not be freeing the list. (It's unclear why this change never got reported/fixed in the X.Org upstream code if this is the case, as the free has been there since the function was created: <https://gitlab.freedesktop.org/alanc/xc-historical/-/commit/540552e8f832f45392de7a2ef8e31433daeee295>)
After the VSW test suite was open sourced as XTS, the test was changed to workaround this issue:
https://gitlab.freedesktop.org/xorg/test/xts/-/commit/c3a401f84ce701e310efb9de6ab5c031451e01f3
I'm not clear on which view was correct - was the test wrong or is the current libXt code wrong?