libX11 issueshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues2023-11-02T03:55:34Zhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/9X does not allow input of Unicode characters using Ctrl+Shift followed by the...2023-11-02T03:55:34ZBugzilla Migration UserX does not allow input of Unicode characters using Ctrl+Shift followed by the character code## Submitted by Dotan Cohen
Assigned to **Xorg Project Team**
**[Link to original bug (#26747)](https://bugs.freedesktop.org/show_bug.cgi?id=26747)**
## Description
There is currently no way to enter Unicode character codes in X. ...## Submitted by Dotan Cohen
Assigned to **Xorg Project Team**
**[Link to original bug (#26747)](https://bugs.freedesktop.org/show_bug.cgi?id=26747)**
## Description
There is currently no way to enter Unicode character codes in X. Some downstream implementations, such as Gnome, have implemented this independently. However, others such as Qt and KDE are waiting for a native X implementation. Currently, X users must copy and paste non-letter unicode characters from application to application.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/62Add lacking compose sequences for some important characters2020-01-25T01:25:08ZBugzilla Migration UserAdd lacking compose sequences for some important characters## Submitted by Michał Górny
Assigned to **Xorg Project Team**
**[Link to original bug (#85623)](https://bugs.freedesktop.org/show_bug.cgi?id=85623)**
## Description
Created attachment 108661
adds lacking compose sequences for som...## Submitted by Michał Górny
Assigned to **Xorg Project Team**
**[Link to original bug (#85623)](https://bugs.freedesktop.org/show_bug.cgi?id=85623)**
## Description
Created attachment 108661
adds lacking compose sequences for some important characters
I created a patch adding several compose sequences that are lacking from current default compose file. Some of them are required in specific orthographies, the other are quite commonly used so I think they should be accessible through Compose key. None of the proposals conflicts with the existing sequences.
Lacking letters:
• EE : "Ə" (U+018F LATIN CAPITAL LETTER SCHWA) – very important, used in Azerbaijani language; analogous to already existing sequence ee : "ə"
• /B : "Ƀ" (U+0243 LATIN CAPITAL LETTER B WITH STROKE) – now only small b with stroke has compose sequence
• /P : "Ᵽ" (U+2C63 LATIN CAPITAL LETTER P WITH STROKE)
• /p : "ᵽ" (U+1D7D LATIN SMALL LETTER P WITH STROKE)
• /R : "Ɍ" (U+024C LATIN CAPITAL LETTER R WITH STROKE) – used in Kanuri language
• /r : "ɍ" (U+024D LATIN SMALL LETTER R WITH STROKE) – used in Kanuri language
Lacking punctuation marks:
• ^' : "′" (U+2032 PRIME) – correct way of denoting minutes, feets etc.
• ^" : "″" (U+2033 DOUBLE PRIME) – correct way of denoting seconds, inches etc.
Lacking modifier letters:
• ^^' : "ʹ" (U+02B9 MODIFIER LETTER PRIME) – used to sign palatalization in transliteration of Cyrillic
• ^^" : "ʺ" (U+02BA MODIFIER LETTER DOUBLE PRIME) – used to sign no palatalization in transliteration of Cyrillic
• ^_, : "ʻ" (U+02BB MODIFIER LETTER TURNED COMMA) – used in Uzbek and Polynesian (including Hawaiʻian) languages
• ^_' : "ʼ" (U+02BC MODIFIER LETTER APOSTROPHE) – used in ortographies of many languages
• ^_" : "ˮ" (U+02EE MODIFIER LETTER DOUBLE APOSTROPHE)
Some common mathematical symbols and arrows:
• ~~ : "≈" (U+2248 ALMOST EQUAL TO)
• Al : "∀" (U+2200 FOR ALL)
• Ex : "∃" (U+2203 THERE EXISTS)
• /\ : "∧" (U+2227 LOGICAL AND)
• \/ : "∨" (U+2228 LOGICAL OR)
• |v : "↓" (U+2193 DOWNWARDS ARROW)
• |^ : "↑" (U+2191 UPWARDS ARROW)
• >-< : "↔" (U+2194 LEFT RIGHT ARROW) – beacuse `<->` and `<>` are both conflicting
Other important lacking symbols:
• |- : "†" (U+2020 DAGGER)
• |= : "‡" (U+2021 DOUBLE DAGGER)
• o|- : "♀" (U+2640 FEMALE SIGN)
• o|^ : "♂" (U+2642 MALE SIGN)
• VV : "✓" (U+2713 CHECK MARK)
• XX : "✗" (U+2717 BALLOT X)
**Attachment 108661**, "adds lacking compose sequences for some important characters":
[Compose.pre.diff](/uploads/b846e2e81bcd33d7e318124e31006efc/Compose.pre.diff)
Version: githttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/43XCreateIC() leaks name and class strings2022-12-26T13:28:35ZBugzilla Migration UserXCreateIC() leaks name and class strings## Submitted by Andrew Church
Assigned to **Xorg Project Team**
**[Link to original bug (#89481)](https://bugs.freedesktop.org/show_bug.cgi?id=89481)**
## Description
In libX11-1.6.2, when creating an input context, the name and c...## Submitted by Andrew Church
Assigned to **Xorg Project Team**
**[Link to original bug (#89481)](https://bugs.freedesktop.org/show_bug.cgi?id=89481)**
## Description
In libX11-1.6.2, when creating an input context, the name and class strings passed with XNResourceName and XNResourceClass are copied, but the copies are not freed when XDestroyIC() is called on the resulting input context:
```
main() {
/* ... */
XIC ic = XCreateIC(x11_im,
XNClientWindow, window,
XNFocusWindow, window,
XNInputStyle, XIMPreeditNothing | XIMStatusNothing,
XNResourceName, "foobar", // Leaked.
XNResourceClass, "foobar", // Leaked.
NULL);
XDestroyIC(ic);
/* ... */
}
```
```
$ valgrind --leak-check=full ./test
[...]
==8402== 14 bytes in 2 blocks are definitely lost in loss record 13 of 94
==8402== at 0x4C2B960: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8402== by 0x79392D1: strdup (in /lib64/libc-2.20.so)
==8402== by 0x69F22E6: ??? (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69F3114: _XimSetICValueData (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69EE628: _XimLocalCreateIC (in /usr/lib64/libX11.so.6.3.0)
==8402== by 0x69D3AB4: XCreateIC (in /usr/lib64/libX11.so.6.3.0)
```
Set to severity "minor" since the leak size is small and most programs will probably not call XCreateIC() and XDestroyIC() over and over.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/36Use-after-free in XUnregisterIMInstantiateCallback causes wrong behavior or c...2021-06-03T23:35:36ZBugzilla Migration UserUse-after-free in XUnregisterIMInstantiateCallback causes wrong behavior or crash## Submitted by Dmitry Antipov
Assigned to **Xorg Project Team**
**[Link to original bug (#81338)](https://bugs.freedesktop.org/show_bug.cgi?id=81338)**
## Description
Created attachment 102761
proposal fix
I was unable to create...## Submitted by Dmitry Antipov
Assigned to **Xorg Project Team**
**[Link to original bug (#81338)](https://bugs.freedesktop.org/show_bug.cgi?id=81338)**
## Description
Created attachment 102761
proposal fix
I was unable to create small and isolated example, so the only way to reproduce this bug is to run GNU Emacs with multiple X servers (Xnest is OK too). So steps to reproduce are:
1. Compile Emacs with Lucid toolkit (--with-x-toolkit=lucid) and internal checking enabled (--enable-checking).
2. Run Xnest on :1
3. Run Emacs with:
emacs -Q --eval '(let ((f (selected-frame))) (make-frame-on-display ":1.0") (delete-frame f))'
4. See assertion failure at xterm.c:8006 while checking the value returned from XUnregisterIMInstantiateCallback.
Running under Valgrind (see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17975#17) shows a use-after-free error.
Proposal fix is attached.
**Attachment 102761**, "proposal fix":
[lcd-core-modifiers.patch](/uploads/317d032699a68aeaa0d5096c58878f39/lcd-core-modifiers.patch)
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/90Memory leak in XrmGetStringDatabase2019-03-10T04:54:20ZBugzilla Migration UserMemory leak in XrmGetStringDatabase## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94604)](https://bugs.freedesktop.org/show_bug.cgi?id=94604)**
## Description
Using XrmGetStringDatabase results in memory leaks, despite calling...## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94604)](https://bugs.freedesktop.org/show_bug.cgi?id=94604)**
## Description
Using XrmGetStringDatabase results in memory leaks, despite calling XrmDestroyDatabase. The following is an excerpt from running valgrind:
```
==21703== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 1,051 of 1,063
==21703== at 0x4C2CB1D: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21703== by 0x508CE40: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508D3B3: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508EC9E: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x508F4AB: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x50AC8AF: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5096D3D: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5096F4A: _XrmInitParseInfo (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x507E96F: ??? (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x5081F4D: XrmGetStringDatabase (in /usr/lib/libX11.so.6.3.0)
==21703== by 0x4020A2: check_get_resource_xlib (test.c:413)
==21703== by 0x402222: check_get_resource (test.c:457)
==21703== by 0x401AF2: test_get_resource (test.c:267)
==21703== by 0x401AF2: main (test.c:77)
```
Please let me know about further information you need.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/68Lacking sequences for generating polytonic greek vowels holding several diacr...2023-04-06T16:26:41ZBugzilla Migration UserLacking sequences for generating polytonic greek vowels holding several diacritics## Submitted by arbiel
Assigned to **Xorg Project Team**
**[Link to original bug (#103151)](https://bugs.freedesktop.org/show_bug.cgi?id=103151)**
## Description
Polytonic greek vowels may hold up to three diacritics. The standard...## Submitted by arbiel
Assigned to **Xorg Project Team**
**[Link to original bug (#103151)](https://bugs.freedesktop.org/show_bug.cgi?id=103151)**
## Description
Polytonic greek vowels may hold up to three diacritics. The standard compose file (/usr/share/X11/locale/en_US.UTF-8/Compose) contains mostly a unique sequence, when it should contains up to six of them, as the user may randomly use any of these sequences.
As a example, generating the letter alpha from the Greek_alpha keysym contains the single line
```
<dead_iota> <dead_acute> <dead_psili> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
```
when it should contain
```
<dead_iota> <dead_acute> <dead_psili> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<dead_acute> <dead_psili> <dead_iota> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<dead_acute> <dead_iota> <dead_psili> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<dead_iota> <dead_psili> <dead_acute> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<dead_psili> <dead_acute> <dead_iota> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
<dead_psili> <dead_iota> <dead_acute> <Greek_alpha> : "ᾄ" U1F84 # GREEK SMALL LETTER ALPHA WITH PSILI AND OXIA AND YPOGEGRAMMENI
```
or at least generate the composed letter for all six sequences, whatever sequence has been coded in the compose file (this would be much better indeed)
Arbielhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/63Annoying compose sequence: <C> <C> <C> <P>2022-06-16T09:04:24ZBugzilla Migration UserAnnoying compose sequence: <C> <C> <C> <P>## Submitted by Marc Mezzarobba
Assigned to **Xorg Project Team**
**[Link to original bug (#91821)](https://bugs.freedesktop.org/show_bug.cgi?id=91821)**
## Description
libX11/nls/en_US.UTF-8/Compose.pre contains the definition
`...## Submitted by Marc Mezzarobba
Assigned to **Xorg Project Team**
**[Link to original bug (#91821)](https://bugs.freedesktop.org/show_bug.cgi?id=91821)**
## Description
libX11/nls/en_US.UTF-8/Compose.pre contains the definition
`<Multi_key>` `<C>` `<C>` `<C>` `<P>` : "☭" U262D # HAMMER AND SICKLE
which seems of limited use to me but (as far as I understand) makes it impossible to map `<Multi_key>` `<C>` `<C>` to ℂ. Would it be conceivable to use a different compose sequence for ☭, or remove the definition altogether? Thanks.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/54addition of compose table support for the sequence "ė̄" and its majuscule2022-08-31T13:55:11ZBugzilla Migration Useraddition of compose table support for the sequence "ė̄" and its majuscule## Submitted by Arns Udovīčė
Assigned to **Xorg Project Team**
**[Link to original bug (#31151)](https://bugs.freedesktop.org/show_bug.cgi?id=31151)**
## Description
Created attachment 39801
Example of letters
Samogitian (http://...## Submitted by Arns Udovīčė
Assigned to **Xorg Project Team**
**[Link to original bug (#31151)](https://bugs.freedesktop.org/show_bug.cgi?id=31151)**
## Description
Created attachment 39801
Example of letters
Samogitian (http://www.sil.org/iso639-3/documentation.asp?id=sgs) use additional letter "E with dot above and macron". Our neighbours Livs use similar letter "Ǡ ǡ" and it uses a compose sequence: `<Compose> + <_> + <.> + <a>`.
Please add these two lines to the UTF-8 compose table:
```
<Multi_key> <underscore> <period> <e> : "ė̄"
<Multi_key> <underscore> <period> <E> : "Ė̄"
```
**Attachment 39801**, "Example of letters":
![Screenshot_1](/uploads/9293fd633324500f57035d4a8294ef5d/Screenshot_1.png)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/35Some programs (emacs,urxvt) hang at xcb_wait_for_event2018-08-10T20:10:41ZBugzilla Migration UserSome programs (emacs,urxvt) hang at xcb_wait_for_event## Submitted by Daniel Clemente
Assigned to **Xorg Project Team**
**[Link to original bug (#78081)](https://bugs.freedesktop.org/show_bug.cgi?id=78081)**
## Description
Hi, in last months (early 2014) I started seeing strange hang...## Submitted by Daniel Clemente
Assigned to **Xorg Project Team**
**[Link to original bug (#78081)](https://bugs.freedesktop.org/show_bug.cgi?id=78081)**
## Description
Hi, in last months (early 2014) I started seeing strange hangs in Emacs and urxvt which I think are due to XCB. I use GNU/Linux Debian with libxcb1==1.10-2, wmii==3.10~20120413+hg2813-6 window manager.
The program window becomes black and doesn't react to mouse/keyboard events or kill signals (I tried many numbers). I have to kill the process (or mess up gdb until it dies with SIGSEGV). Same for both programs.
*) Emacs hung. Version: GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-04-19
```
(gdb) bt
#0 0x00007f3e744de710 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f3e73fea232 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007f3e73febd0f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007f3e75aa3918 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007f3e75a8beb1 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f3e75ad2764 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007f3e75ad33c0 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007f3e75ad36b1 in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007f3e75ac2096 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007f3e75ab02fd in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x000000000050f099 in xic_set_preeditarea (w=0x5113858, x=768, y=56) at xfns.c:2106
#11 0x0000000000504c0a in x_draw_window_cursor (w=0x5113858, glyph_row=0x18039870, x=768, y=56, cursor_type=FILLED_BOX_CURSOR, cursor_width=1, on_p=true, active_p=true)
at xterm.c:7312
#12 0x0000000000477484 in display_and_set_cursor (w=0x5113858, on=true, hpos=96, vpos=4, x=768, y=56) at xdisp.c:27214
#13 0x00000000004f7070 in x_update_window_end (w=0x5113858, cursor_on_p=true, mouse_face_overwritten_p=false) at xterm.c:582
#14 0x00000000004133ae in update_window (w=0x5113858, force_p=true) at dispnew.c:3486
#15 0x00000000004129f8 in update_window_tree (w=0x5113858, force_p=true) at dispnew.c:3161
#16 0x00000000004129bd in update_window_tree (w=0x524ef10, force_p=true) at dispnew.c:3159
#17 0x00000000004126d1 in update_frame (f=0x5113640, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3059
#18 0x000000000044b5ee in redisplay_internal () at xdisp.c:13873
#19 0x00000000004495cd in redisplay () at xdisp.c:13056
#20 0x00000000005292ed in read_char (commandflag=1, map=375333574, prev_event=12839794, used_mouse_menu=0x7fff8cc0c69f, end_time=0x0) at keyboard.c:2751
#21 0x0000000000534c1a in read_key_sequence (keybuf=0x7fff8cc0c880, bufsize=30, prompt=12839794, dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9076
#22 0x0000000000526840 in command_loop_1 () at keyboard.c:1449
#23 0x00000000005b3a60 in internal_condition_case (bfun=0x526487 <command_loop_1>, handlers=12890850, hfun=0x525d99 <cmd_error>) at eval.c:1354
#24 0x00000000005261e1 in command_loop_2 (ignore=12839794) at keyboard.c:1174
#25 0x00000000005b3272 in internal_catch (tag=12886738, func=0x5261bb <command_loop_2>, arg=12839794) at eval.c:1118
#26 0x000000000052618f in command_loop () at keyboard.c:1153
#27 0x0000000000525994 in recursive_edit_1 () at keyboard.c:777
#28 0x0000000000525b01 in Frecursive_edit () at keyboard.c:845
#29 0x0000000000523acf in main (argc=2, argv=0x7fff8cc0cd08) at emacs.c:1654
```
* urxvt hung. rxvt-unicode==9.19-1. Started with daemon: urxvtcd
```
(gdb) bt
#0 0x00007f1b40226710 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007f1b3f481232 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007f1b3f482d0f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007f1b4166d918 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007f1b41655eb1 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007f1b4169c764 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007f1b4169d3c0 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007f1b4169d6b1 in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007f1b4168c096 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007f1b4167a2fd in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00000000004281bf in rxvt_term::im_send_spot() ()
#11 0x000000000041e6d9 in rxvt_term::flush() ()
#12 0x0000000000438640 in ev_invoke_pending() ()
#13 0x000000000043989e in ev_run ()
#14 0x0000000000418e87 in main ()
(gdb)
```
In addition I'm using scim (input method).
If there's some way in which I can advance the research of this bug, please tell me. It happens rarely, maybe once a week. I didn't see any pattern.
I tried as a workaround to go up the stack and then forcing „return“ in gdb but it only crashed or hung again. Tips to unblock apps are welcome.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/92cs_CZ.UTF-8 should interpret dead_caron + u as uring2022-01-11T15:58:21ZBugzilla Migration Usercs_CZ.UTF-8 should interpret dead_caron + u as uring## Submitted by vlm..@..lny.cz
Assigned to **Xorg Project Team**
**[Link to original bug (#81875)](https://bugs.freedesktop.org/show_bug.cgi?id=81875)**
## Description
Hi,
[ I'm making copy of https://bugzilla.novell.com/show_bug...## Submitted by vlm..@..lny.cz
Assigned to **Xorg Project Team**
**[Link to original bug (#81875)](https://bugs.freedesktop.org/show_bug.cgi?id=81875)**
## Description
Hi,
[ I'm making copy of https://bugzilla.novell.com/show_bug.cgi?id=888446 where I reported the bug previously ]
My .profile contains:
export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim
export LC_ALL=cs_CZ.UTF-8
Now if I press dead_caron + u, I get ǔ, but I should get ů. The same for
capital letters - I get Ǔ but I should get Ů.
The workaround I use is to set ~/.XCompose to
include "%S/en_US.UTF-8/Compose"
`<dead_caron>` `<u>` : "ů" U016F # LATIN SMALL LETTER U
WITH RING ABOVE
`<dead_caron>` `<U>` : "Ů" U016E # LATIN CAPITAL LETTER U
WITH RING ABOVE
This is already defined in /usr/share/X11/locale/iso8859-2/Compose , but one
would have to use iso8859-2 instead of UTF-8:
`<dead_caron>` `<U>` : "\331" Uring
`<dead_caron>` `<u>` : "\371" uring
(of course the binary value for Uring is different in iso8859-2 and UTF-8, so
it can't be fixed by straight copy/paste)
I don't understand the xkb too well, but I guess that there should be new
directory and file /usr/share/X11/locale/cs_CZ.UTF-8/Compose which would
contain something similar to what I have in ~/.XCompose
Please note that it does not seem to be logical to use dead_caron for ring
above u, but since we don't use ring above any other letter, and ǔ does not
exist in czech, it's very convenient to have it print ů. This way it works on
czech keyboards since ever.
It's interesting that I have hard time finding evidence that it should be set
this way.
For example
https://ufal.mff.cuni.cz/pdt/Support/czech-info.html
The ring accent can occur only above an "u" where, in contrary, no caron can
occur. That is why many keyboards use the sequence "dead caron" - "u"/"U" to
enter an "u" with ring above. However, other keyboards (including Microsoft
Windows, I guess) alocate a "dead ring" key elsewhere, often to shifted
semicolon, replacing the U.S. key for tilde.
https://lists.debian.org/debian-gtk-gnome/2003/11/msg00235.html
Thank you
__
Vlad
Reproducible: Always
Steps to Reproduce:
1. Enable XIM input method by putting this into your .profile:
export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim
export LC_ALL=cs_CZ.UTF-8
2. restart X so that the options take effect
2.5 start xterm
3. set czech keyboard map
setxkbmap "us,cz(qwerty)" -option grp:shifts_toggle -option ctrl:swapcaps
4. switch into czech map by pressing both shifts together
5. Press dead_caron (shift + key "=" which should normally produce character
"+")
6. Press letter "u"
7. ǔ appears, but I should see ů
Actual Results:
ǔ appears
Expected Results:
I should see ůhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/91compose key fails on some ligatures2023-03-07T10:51:56ZBugzilla Migration Usercompose key fails on some ligatures## Submitted by markp0
Assigned to **Xorg Project Team**
**[Link to original bug (#84341)](https://bugs.freedesktop.org/show_bug.cgi?id=84341)**
## Description
OVERVIEW:
As far as I can tell, the compose key works in every program...## Submitted by markp0
Assigned to **Xorg Project Team**
**[Link to original bug (#84341)](https://bugs.freedesktop.org/show_bug.cgi?id=84341)**
## Description
OVERVIEW:
As far as I can tell, the compose key works in every program for most characters. But in these Linux releases...
LinuxMint 17 64bit (Cinnamon, MATE, KDE, Xfce)
kubuntu and xubuntu 14.04.1 64bit
...some ligatures don't work.
For example, the compose key correctly produces these ligatures:
`<compose>` o e = œ
`<compose>` O E = Œ
`<compose>` a e = æ
`<compose>` A E = Æ
but the compose key fails to produce these ligatures:
`<compose>` f f = ff
`<compose>` f i = fi
`<compose>` f l = fl
`<compose>` F i = ffi
`<compose>` F l = ffl
`<compose>` I J = IJ
`<compose>` I j = IJ
`<compose>` i j = ij
It does not appear to be an issue of an incompatible font -- as far as I can see, the special characters will always appear if I copy them from a character map and paste them (into any program). I'm also able to successfully generate the ligatures in vim, e.g.:
`<Ctrl-k>` i j = ij
__________
STEPS TO REPRODUCE:
1) Assign a compose key:
a) LinuxMint 17 Cinnamon,
LinuxMint 17 MATE:
System Settings [or Control Center] > Keyboard
> Layouts [or Keyboard layouts] > Options
> Position of Compose key > [assign a key and close window]
b) LinuxMint 17 KDE,
Kubuntu 14.04.1:
System Settings > Input Devices > Keyboard > Advanced
> Position of Compose Key
> [assign a key, click Apply and close window]
c) LinuxMint 17 Xfce,
Xubuntu 14.04.1:
Settings [or Settings Manager] > Keyboard
> Layout > [uncheck "Use system defaults"]
> Compose key > [assign a key and close window]
2) Open a program that displays characters as you type (I get the same results with firefox, Konsole, gedit, Kate, LibreOffice Writer, LibreOffice Calc, etc.)
3) Type: `<compose>` a e
Type: `<compose>` f i
__________
ACTUAL RESULTS:
After the first 3-key sequence, the ae ligature (æ) is output to the screen.
After the second 3-key sequence, the cursor remains where it is and no new character appears.
__________
EXPECTED RESULTS:
After the second 3-key sequence, the fi ligature (fi) should be output to the screen.
__________
LINUX RELEASES AFFECTED BY THIS BUG:
Here are some Linux releases where the compose key *fails* to output the ligatures described above. I've included the output of `uname -a' for each release I tested.
LinuxMint 17 64bit Cinnamon
LinuxMint 17 64bit MATE
LinuxMint 17 64bit Xfce
uname -a: Linux mint 3.13.0-24-generic #46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
LinuxMint 17 64bit KDE:
uname -a: Linux mint 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
kubuntu 14.04.1 64bit
xubuntu 14.04.1 64bit
uname -a: Linux kubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
uname -a: Linux xubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
__________
LINUX RELEASES NOT AFFECTED BY THIS BUG:
Here are some Linux releases where the compose key *succeeds* in outputting the ligatures described above. I've included the output of `uname -a' for each release I tested.
Ubuntu 14.04.1 64bit (with Unity)
Ubuntu 14.04.1 64bit (with GNOME)
Lubuntu 14.04.1 64bit
uname -a: Linux ubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
uname -a: Linux ubuntu-gnome 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
uname -a: Linux lubuntu 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
__________
ADDITIONAL INFORMATION:
All the releases I tested were from official Live CDs except LinuxMint KDE, which is a more recent update than what's on the Live CD. All of them had a Compose file containing the ligatures in questions, and they all responded the same way to these commands:
$ echo $LANG
en_US.UTF-8
$ echo $TERM
xterm
$ grep fi /usr/share/X11/locale/en_US.UTF-8/Compose
`<Multi_key>` `<f>` `<i>` : "fi" Ufb01 # LATIN SMALL LIGATURE FI
I've also posted bug reports of this in these places:
https://forum.kde.org/viewtopic.php?f=225&t=122909
https://bugs.launchpad.net/linuxmint/+bug/1372041
Thanks.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/89XrmGetStringDatabase does not resolve include statements2019-03-10T04:53:24ZBugzilla Migration UserXrmGetStringDatabase does not resolve include statements## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94642)](https://bugs.freedesktop.org/show_bug.cgi?id=94642)**
## Description
The documentation for XrmGetStringDatabase states that it handles l...## Submitted by Ingo Bürk
Assigned to **Xorg Project Team**
**[Link to original bug (#94642)](https://bugs.freedesktop.org/show_bug.cgi?id=94642)**
## Description
The documentation for XrmGetStringDatabase states that it handles lines in valid ResourceLine format. However, the ResourceLine format includes "#include" statements, which don't seem to be resolved (but ignored instead).https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/88Reformatted version of XKB Extension Lib Spec2019-02-21T10:29:38ZBugzilla Migration UserReformatted version of XKB Extension Lib Spec## Submitted by Graham Wideman
Assigned to **Matt Dew `@marcoz`**
**[Link to original bug (#65749)](https://bugs.freedesktop.org/show_bug.cgi?id=65749)**
## Description
X Keyboard Extension: Library Specification
(http://www.x.or...## Submitted by Graham Wideman
Assigned to **Matt Dew `@marcoz`**
**[Link to original bug (#65749)](https://bugs.freedesktop.org/show_bug.cgi?id=65749)**
## Description
X Keyboard Extension: Library Specification
(http://www.x.org/releases/X11R7.7/doc/libX11/XKB/xkblib.html)
is an essential doc for XKB, yet its formatting makes both the html and PDF versions almost impossible to use. Problems include:
-- Crucial diagrams either too small (html), or so large that only a portion is shown (pdf).
-- "See also section xxx" appears frequently, yet doc has no section numbers. (And the html version TOC has no page numbers, of course.)
-- The many source code samples are very poorly formatted for readability
No doubt these are problems with the translation process from the source format to PDF and HTML, and that process should be fixed.
In lieu of that, I have created a replacement version in which I've fixed all of these problems, (and edited nothing else). Attached.
I suggest this be considered for addition to the doc page mentioned above.
If interested, my original is in Word format.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/87XSetWMName attempts to modify the property2019-02-23T19:51:48ZBugzilla Migration UserXSetWMName attempts to modify the property## Submitted by Christopher Yeleighton
Assigned to **Jim Gettys**
**[Link to original bug (#36328)](https://bugs.freedesktop.org/show_bug.cgi?id=36328)**
## Description
XSetWMName requires a pointer to a modifiable XTextProperty. ...## Submitted by Christopher Yeleighton
Assigned to **Jim Gettys**
**[Link to original bug (#36328)](https://bugs.freedesktop.org/show_bug.cgi?id=36328)**
## Description
XSetWMName requires a pointer to a modifiable XTextProperty. Data like XTextProperty are amenable to storing in ROM; the library specification requires the property to be copied first, for no reason.
At: section "Setting and Reading the WM_NAME Property"
Is:
```
void XSetWMName( *display,
w,
*text_prop);
Display *display;
Window w;
XTextProperty *text_prop;
```
Let:
```
void XSetWMName( *display,
w,
*text_prop);
Display *display;
Window w;
XTextProperty const *text_prop;
```
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/86There is a misprint in documentation of XkbFreeGeomOverlayKeys()2019-02-23T19:44:37ZBugzilla Migration UserThere is a misprint in documentation of XkbFreeGeomOverlayKeys()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23550)](https://bugs.freedesktop.org/show_bug.cgi?id=23550)**
## Description
The first argument for XkbFreeGeomOverlayKeys must be XkbOve...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23550)](https://bugs.freedesktop.org/show_bug.cgi?id=23550)**
## Description
The first argument for XkbFreeGeomOverlayKeys must be XkbOverlayRowPtr not XkbRowPtr.
To change the word XkbRowPtr with XkbOverlayRowPtr.
Version: X11R6.6Alan CoopersmithAlan Coopersmithhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/85There is a misprint in the description of XkbAllocGeomOverlayKeys()2019-02-23T19:44:37ZBugzilla Migration UserThere is a misprint in the description of XkbAllocGeomOverlayKeys()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23549)](https://bugs.freedesktop.org/show_bug.cgi?id=23549)**
## Description
The first parameter of the function XkbAllocGeomOverlayKeys(...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23549)](https://bugs.freedesktop.org/show_bug.cgi?id=23549)**
## Description
The first parameter of the function XkbAllocGeomOverlayKeys() is
XkbOverlayRowPtr, not XkbRowPtr.
Change the word XkbRowPtr with XkbOverlayRowPtr and the comment in the same sentence.
Version: X11R6.6Alan CoopersmithAlan Coopersmithhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/84There is a misprint in the documentation of XkbAllocGeomOverlayRows()2019-02-23T19:44:37ZBugzilla Migration UserThere is a misprint in the documentation of XkbAllocGeomOverlayRows()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23548)](https://bugs.freedesktop.org/show_bug.cgi?id=23548)**
## Description
The first argument of the function XkbAllocGeomOverlayRows()...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23548)](https://bugs.freedesktop.org/show_bug.cgi?id=23548)**
## Description
The first argument of the function XkbAllocGeomOverlayRows() is XkbOverlayPtr
not XkbSectionPtr.
Change XkbSectionPtr with XkbOverlayPtr and the comment in the same sentence.
Version: X11R6.6Alan CoopersmithAlan Coopersmithhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/83There is incompleteness in the documentation, XkbGetNamedGeometry()2019-02-21T16:18:23ZBugzilla Migration UserThere is incompleteness in the documentation, XkbGetNamedGeometry()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23547)](https://bugs.freedesktop.org/show_bug.cgi?id=23547)**
## Description
Standard says, the function XkbGetNamedGeometry can return B...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23547)](https://bugs.freedesktop.org/show_bug.cgi?id=23547)**
## Description
Standard says, the function XkbGetNamedGeometry can return BadName, but besides
it the function can also return BadImplementation and BadAccess.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/82There is a misprint in the documentation of XkbGetNamedGeometry()2019-02-23T19:44:37ZBugzilla Migration UserThere is a misprint in the documentation of XkbGetNamedGeometry()## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23520)](https://bugs.freedesktop.org/show_bug.cgi?id=23520)**
## Description
To change the word XkbAllocGeomRows with XkbAllocGeomOverlay...## Submitted by Eduard Bagrov
Assigned to **Paul Anderson `@pma`**
**[Link to original bug (#23520)](https://bugs.freedesktop.org/show_bug.cgi?id=23520)**
## Description
To change the word XkbAllocGeomRows with XkbAllocGeomOverlays in the sentence
"XkbAllocGeomRows allocates num_needed overlays and adds them to the section."
Version: X11R6.6Alan CoopersmithAlan Coopersmithhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/81XFree86 UTF8 additions to Xlib spec2019-02-21T10:29:13ZBugzilla Migration UserXFree86 UTF8 additions to Xlib spec## Submitted by Alan Coopersmith `@alanc`
Assigned to **Jim Gettys**
**[Link to original bug (#274)](https://bugs.freedesktop.org/show_bug.cgi?id=274)**
## Description
XFree86 has made several additions to the Xlib spec to handle ...## Submitted by Alan Coopersmith `@alanc`
Assigned to **Jim Gettys**
**[Link to original bug (#274)](https://bugs.freedesktop.org/show_bug.cgi?id=274)**
## Description
XFree86 has made several additions to the Xlib spec to handle UTF-8 text strings.
Version: X11R6.6