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>
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>
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
_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
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 f293659d5a
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)
When the format is `Pixmap` it calculates the size of the image data as:
ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
There is no validation on the `width` of the image, and so this
calculation exceeds the capacity of a 4-byte integer, causing an overflow.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The CreatePixmap request specifies height & width of the image as CARD16
(unsigned 16-bit integer), so if either is larger than that, set it to 0
so the X server returns a BadValue error as the protocol requires.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The PutImage request specifies height & width of the image as CARD16
(unsigned 16-bit integer), same as the maximum dimensions of an X11
Drawable, which the image is being copied to.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
When splitting a single line of pixels into chunks to send to the
X server, be sure to take into account the number of bits per pixel,
so we don't just loop forever trying to send more pixels than fit in
the given request size and not breaking them down into a small enough
chunk to fix.
Fixes: "almost complete rewrite" (Dec. 12, 1987) from X11R2
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Make sure we allocate enough memory in the first place, and
also handle error returns from _XkbReadBufferCopyKeySyms() when
it detects out-of-bounds issues.
Reported-by: Gregory James DUCK <gjduck@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Other code assumes this pointer cannot be NULL, so fail the connection
if a bug has caused the X server to give a non-existent visual ID for
the default visual of any screen.
Reported-by: Gregory James DUCK <gjduck@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The dagger symbol has several modern uses such as marking someone as
dead or something as extinct. Historically it has been used to indicate
a footnote.
When Ghana, Nigeria, Costa Rica and El Salvador have compose sequences
for their currency symbols (cedi: `₵`, naira: `₦`, colón: `₡`), then
Paraguay, Laos, and Mongolia deserve to have such sequences as well.
The sequences should be obvious: the relevant capital letter of the
name of the currency (G, K, T) plus a vertical bar, a minus sign,
and an equals sign, respectively.
Also add two sequences for `$` (the dollar sign), for consistency.
Drop the tentative comments for drachma, penny, and austral, as those
currencies have been obsolete for more than twenty years.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
As a cent is a small coin, it makes no sense to use an uppercase letter
to compose the `¢` symbol -- having four sequences with a lowercase `c`
plus a `bar` or a `slash` available for composing `¢` should be enough.
Use the sequence `<C> <bar` (with the uppercase `C`) for composing `₵`
(the CEDI SIGN) instead.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Only a few keyboard layouts contain the `dead_iota` keysym, and none
of those layouts contains the `acute` keysym, so compose sequences
that combine the two symbols cannot be typed and are thus useless.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Implementation had "Key" twice in these macro names,
but the docs had only listed it once.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
