The 'if' at the beginning of _XkbHandleSpecialSym() allows only symbols
from the numeric keypad and some control symbols to pass -- XK_hyphen
is not among them, so the check for XK_hyphen in the later 'if' will
always be false.
(The corresponding conversion in _XTranslateKeySym() in KeyBind.c was
removed in March 1994.)
(Also, several keyboard layouts nowadays contain the 'hyphen' symbol,
allowing the user to enter soft hyphens into a document. So we really
don't want to remap this symbol.)
Fixes issue #48.
Reported-by: Bhavi Dhingra
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The typo was only partially fixed in commit 22a5255b80 sixteen years ago,
and the internet shows that there was at least one user frustrated that
bg_BG.utf8 didn't work but bg_BG.UTF-8 did.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Using this KP_Space symbol as a stand-in for the symbol 2 doesn't make
sense. It looks like a mistake, or as if someone had a broken keyboard
and used KP_Space as a substitute for 2.
Also, no keyboard layout in the last fifteen years has contained the
KP_Space symbol, so I don't see how anyone could type it.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Also, align a few trailing comments more consistently, and change
some comments so they will be excluded from the installed file --
there is no need for those comments there.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The compose sequences with the valid Hebrew key symbols are right there.
Also, no keyboard layout in the past seventeen years has contained these
deprecated symbols on any key.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The key symbol 'underbar' is equivalent to 'underscore' -- the mirror
compose sequences with the latter symbol continue to exist.
Also, no keyboard layout in the past fifteen years has contained the
symbol 'underbar' on any key -- except a Telugu layout since a few
years, but that will be corrected soon.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
This makes the middle dot compose sequences consistent with others that
begin with <dead_circumflex> and <Multi_key> <asciicircum>, e.g.
superscripted 3 (³)
Signed-off-by: ArenaL5 <arenal5@protonmail.com>
It doesn't matter that these lines get wider than 80 columns, as it's
easy enough to make the pager scroll a bit to the right, or to have a
terminal that is a 100 or more columns wide. It looks better to not
hard-wrap these comments.
Also, fix the layout of two table elements.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The wrapped lines messed up the table. Also, add some blank lines
to make the table more readable.
Elsewhere, add spaces around an operator (for consistency),
and correct a copy-paste error.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When extending the range of changed virtual-modifier keys, one should
pass the two variables relevant to that range.
These two mistakes were found by grepping for 'modmap_key' and then
looking for asymmetries between the handling of the plain modmap thing
and the virtual modmap thing. Inspired by issue #76.
(I suspect these mistakes were at the base of some intractable bugs
reported against xkeyboard-config where virtual modifiers refused
to work and had to be worked around by making other changes too.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
When there is a break at the end of the while loop, it means that the
loop will finish the first time that _XlcGetCharSetWithSide() returns
a non-NULL result, which means that the first '(last_charset == NULL)'
will always be true and the else part is redundant.
Fixes issue #46.
Reported-by: Bhavi Dhingra
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
There was an "EXT" in the original text, but it seems to be missing.
See: 4e66da0783/specs/XIM/xim.ms (L693)
Signed-off-by: Hodong Kim <hodong@nimfsoft.com>
Assume event queue is empty if another thread is blocking waiting for event.
If one thread was blocking waiting for an event and another thread sent a
reply to the X server, both threads got blocked until an event was
received.
Signed-off-by: Tatu Frisk <tatu.frisk@ge.com>
Signed-off-by: Jose Alarcon <jose.alarcon@ge.com>
When _XGetRequest() detects that requested length exceeds remaining display
output buffer capacity it would return NULL. GetResReq() macro obtains "req"
pointer from a call to _XGetRequest() and then proceeds to assign request id
through "req" pointer which leads to NULL pointer dereference in this case.
Fix this by checking if "req" is valid before assigning request id.
Signed-off-by: Igor V. Kovalenko <igor.v.kovalenko@gmail.com>
These keys are all defined through a macro in the form:
#define XF86XK_BrightnessAuto _EVDEVK(0x0F4)
The _EVDEVK macro is simply an offset of 0x10081000.
Let's parse these lines correctly so those keysyms end up in our
hashtables.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Adding the offset between the realloc result and the old allocation to
update pointers into the new allocation is undefined behaviour: the
old pointers are no longer valid after realloc() according to the C
standard. While this works on almost all architectures and compilers,
it causes problems on architectures that track pointer bounds (e.g.
CHERI or Arm's Morello): the value_list pointers will still have the
bounds of the previous allocation and therefore any dereference will
result in a run-time trap.
I found this due to a crash (dereferencing an invalid capability) while
trying to run `xev` over SSH on a CHERI-RISC-V system. With these two
realloc changes, and https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/41
I am able to succesfully run `xev` compiled for CHERI-RISC-V.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
We can't use `LC_CTYPE=C sed` there since /usr/bin/sed is not compatible
with the expressions in nls/ (`sed: RE error: illegal byte sequence`).
To fix this use $(SED) instead which autotools will set to a GNU
version of sed (usually /usr/local/bin/gsed) on macOS.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
Checking against upper limit of USHRT_MAX must happen before truncating
size_t to int. On 64 bit systems with strings larger than 2 GB this
could otherwise lead to negative ints or ints smaller than USHRT_MAX.
In XParseColor this could lead to out of boundary access with strings
starting with a # (color sequence). A modulo 12 operation is performed
to validate the string length, but with an overflown length, the for
loop would eventually read behind terminating '\0' character.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Array `keysym_to_unicode_590_5fe` is only valid for range [0x590, 0x5fe] but current lower-bound is checked against 0x589.
So invalid values from 0x58a to 0x58f are being allowed by current check.
If any of these invalid value is passed as `keysym`, `keysym - 0x590` would underflow.
Signed-off-by: Gaurav Ujjwal <gujjwal00@gmail.com>
Commit 0bbc0d5e60 (from eight years ago) removed the lines that two
of these comments referred to. Without those lines, the comments don't
make sense any more. Reword and shorten them.
Also reword a comment about two sequences that don't work.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
The letters ă and ŭ can already be composed with "u a" and "u u", but
ĕ, ğ, ĭ, and ŏ can be composed only with an uppercase U. Emancipate
the latter four and understand also a lowercase "u" to mean 'breve'.
(Yesterday I needed ğ and was annoyed that "u g" did not work.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
this was found by checking man pages with
groff -t -mandoc -Z -wmac -Tutf8 $FILE >/dev/null
In most cases .hN could be replaced with .BR
Signed-off-by: Walter Harms <wharms@bfs.de>
