libX11 issueshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues2023-03-15T22:54:49Zhttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/23Error when cross-compiling makekeys2023-03-15T22:54:49ZBugzilla Migration UserError when cross-compiling makekeys## Submitted by Ross Burton `@ross`
Assigned to **Xorg Project Team**
**[Link to original bug (#55424)](https://bugs.freedesktop.org/show_bug.cgi?id=55424)**
## Description
When cross-compiling makekeys on an older host (CentOS 5,...## Submitted by Ross Burton `@ross`
Assigned to **Xorg Project Team**
**[Link to original bug (#55424)](https://bugs.freedesktop.org/show_bug.cgi?id=55424)**
## Description
When cross-compiling makekeys on an older host (CentOS 5, for example):
makekeys-makekeys.o: In function `main':
makekeys.c:(.text+0x85): undefined reference to `__isoc99_sscanf'
makekeys.c:(.text+0xa7): undefined reference to `__isoc99_sscanf'
makekeys.c doesn't include config.h (as that has target information, not host) and this old libc doesn't expose these functions without _GNU_SOURCE.
We're working around this by passing -D_GNU_SOURCE when compiling makekeys, but Daniel Stone informed me that won't be acceptable upstream as it could potentially break/not work on Solaris.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/22Compiler warnings when cross-compiling2023-03-15T22:54:49ZBugzilla Migration UserCompiler warnings when cross-compiling## Submitted by Ross Burton `@ross`
Assigned to **Xorg Project Team**
**[Link to original bug (#55423)](https://bugs.freedesktop.org/show_bug.cgi?id=55423)**
## Description
When cross-compiling on a older host (CentOS 5, for examp...## Submitted by Ross Burton `@ross`
Assigned to **Xorg Project Team**
**[Link to original bug (#55423)](https://bugs.freedesktop.org/show_bug.cgi?id=55423)**
## Description
When cross-compiling on a older host (CentOS 5, for example):
| cc1: error: unrecognized command line option "-Werror=implicit"
| cc1: error: unrecognized command line option "-Werror=nonnull"
| cc1: error: unrecognized command line option "-Werror=init-self"
| cc1: error: unrecognized command line option "-Werror=main"
| cc1: error: unrecognized command line option "-Werror=missing-braces"
| cc1: error: unrecognized command line option "-Werror=sequence-point"
| cc1: error: unrecognized command line option "-Werror=return-type"
| cc1: error: unrecognized command line option "-Werror=trigraphs"
| cc1: error: unrecognized command line option "-Werror=array-bounds"
| cc1: error: unrecognized command line option "-Werror=write-strings"
| cc1: error: unrecognized command line option "-Werror=address"
| cc1: error: unrecognized command line option "-Werror=int-to-pointer-cast"
| cc1: error: unrecognized command line option "-Werror=pointer-to-int-cast"
Whilst the configure script checks the warning options it only does that for the cross compiler and not the host compiler (used when building makekeys).https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/21xcb errors are not handled at Xlib, gives fatal IO error 11 (Resource tempor...2023-03-15T22:54:49ZBugzilla Migration Userxcb errors are not handled at Xlib, gives fatal IO error 11 (Resource temporarily unavailable)## Submitted by Arvind Umrao
Assigned to **Arvind Umrao**
**[Link to original bug (#54109)](https://bugs.freedesktop.org/show_bug.cgi?id=54109)**
## Description
xcb errors are not handled at Xlib. It gives
XIO: fatal IO error 11...## Submitted by Arvind Umrao
Assigned to **Arvind Umrao**
**[Link to original bug (#54109)](https://bugs.freedesktop.org/show_bug.cgi?id=54109)**
## Description
xcb errors are not handled at Xlib. It gives
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0"
after 14 requests (13 known processed) with 0 events remaining.
Step to reproduce the problem
Compile following code with cc test.c -lX11
then run ./a.out
close it with Ctrl-C
```
#include <X11/Xlib.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void) {
Display *d;
Window w;
XEvent e;
char *msg = "Hello, World!";
int s;
d = XOpenDisplay(NULL);
if (d == NULL) {
fprintf(stderr, "Cannot open display\n");
exit(1);
}
s = DefaultScreen(d);
w = XCreateSimpleWindow(d, RootWindow(d, s), 10, 10, 200, 200, 1,
BlackPixel(d, s), WhitePixel(d, s));
/* select kind of events we are interested in */
XSelectInput(d, w, ExposureMask | KeyPressMask);
XMapWindow(d, w);
while (1) {
XNextEvent(d, &e);
/* draw or redraw the window */
if (e.type == Expose) {
XFillRectangle(d, w, DefaultGC(d, s), 20, 20, 10, 10);
XDrawString(d, w, DefaultGC(d, s), 50, 50, msg, strlen(msg));
}
/* exit on key press */
if (e.type == KeyPress)
break;
}
XCloseDisplay(d);
return 0;
}https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/20Parsing of 'Compose' files is so slow!2023-07-16T09:34:35ZBugzilla Migration UserParsing of 'Compose' files is so slow!## Submitted by Benoît Minisini
Assigned to **Xorg Project Team**
**[Link to original bug (#53540)](https://bugs.freedesktop.org/show_bug.cgi?id=53540)**
## Description
When profiling the start-up of my GUI program (the Gambas dev...## Submitted by Benoît Minisini
Assigned to **Xorg Project Team**
**[Link to original bug (#53540)](https://bugs.freedesktop.org/show_bug.cgi?id=53540)**
## Description
When profiling the start-up of my GUI program (the Gambas development environment, based on Qt4 and the Gambas interpreter), I noticed that almost 10% of the start-up time is spent inside a libX11.so function named "_XimParseString". As much time as what is spent by the interpreter itself!
This function is located in the modules/im/ximcp/imLcPrs.c XLib source file.
Half on that time is spent in the nextch() static function of the same source file, because getc() is used for reading each character of the "Compose" file, which is usually half a megabyte.
getc() is very slow. Implementing a buffer without using the libc would speed up things a lot.
I will try to rewrite the file and recompile the libX11 on my system. If I don't succeed, is there any X11 developer or tester there that could test the file for me?
Thanks in advance.
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/19Compcache not being created globally, only locally.2023-03-15T22:54:49ZBugzilla Migration UserCompcache not being created globally, only locally.## Submitted by mar..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#52070)](https://bugs.freedesktop.org/show_bug.cgi?id=52070)**
## Description
Hi,
I was profiling an application and saw a high usage of _X...## Submitted by mar..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#52070)](https://bugs.freedesktop.org/show_bug.cgi?id=52070)**
## Description
Hi,
I was profiling an application and saw a high usage of _XimParseStringFile. That made me wonder: "don't i have caching?"
After grabbing the package from my distribution (Archlinux) and recompiling it with some debug statements in the file: modules/im/ximcp/imLcIm.c i quickly found out that the define COMPOSECACHE was set and caching "should" be enabled.
So i took a deeper look and added a lot of logging in the function: Private int _XimCachedFileName" (same file). Turns out that that function only seems to be getting a dir path to my local cache "~/.compose-cache/" which also didn't exist. After making that folder the cache was created and this issue would be solved.
However, the local cache wasn't made! I never even saw a call to _XimCachedFileName where the dir is: "/var/cache/libx11/compose/" even though XIM_GLOBAL_CACHE_DIR is set and i did create the folder. It's just empty. So somehow it doesn't use the global cache folder.
Some details:
Archlinux (fully updated)
libX11 1.5.0
x64
Cheers,
Mark
Note: this bugzilla is REALLY SLOW! It even timed out when submitting this bug.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/17Fix for bug 9160 has changed XQueryColors behavior under xts52023-03-15T22:54:49ZBugzilla Migration UserFix for bug 9160 has changed XQueryColors behavior under xts5## Submitted by Stew Benedict
Assigned to **Xorg Project Team**
**[Link to original bug (#51313)](https://bugs.freedesktop.org/show_bug.cgi?id=51313)**
## Description
Since the fix for [bug 9160](https://bugs.freedesktop.org/show_...## Submitted by Stew Benedict
Assigned to **Xorg Project Team**
**[Link to original bug (#51313)](https://bugs.freedesktop.org/show_bug.cgi?id=51313)**
## Description
Since the fix for [bug 9160](https://bugs.freedesktop.org/show_bug.cgi?id=9160) has made it's way out to distributions, I've been seeing the xts5 test for XQueryColors fail on several distributions with the following output:
/tset/Xlib7/qryclrs/Test 2 failed Known Problem
Message from the test:
VSW5TESTSUITE PURPOSE 2
Assertion XQueryColors-2.(A)
When a colourmap argument does not name a valid colourmap,
then a BadColor error occurs.
METH: Create a bad colourmap by creating and freeing a colourmap.
METH: Call test function using bad colourmap as the colourmap argument.
METH: Verify that a BadColor error occurs.
REPORT: Got Success, Expecting BadColor
"Known Problem" comes from out own problem database and just indicates to a distribution tester that we (LSB) are aware of it/
Pulling libX11 out of git and making a patch reverting the [bug 1960](https://bugs.freedesktop.org/show_bug.cgi?id=1960) change, the test passes here (on Mageia Cauldron).
Should the [bug 1960](https://bugs.freedesktop.org/show_bug.cgi?id=1960) fix have changed the behavior being tested for in the xts5 test? Is the xts5 test still valid?
Thankshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/16Add support for disabling extensions through environment variables2023-03-15T22:54:49ZBugzilla Migration UserAdd support for disabling extensions through environment variables## Submitted by Vincent Untz `@vuntz`
Assigned to **Xorg Project Team**
**[Link to original bug (#48588)](https://bugs.freedesktop.org/show_bug.cgi?id=48588)**
## Description
Created attachment 59837
Add support for disabling exte...## Submitted by Vincent Untz `@vuntz`
Assigned to **Xorg Project Team**
**[Link to original bug (#48588)](https://bugs.freedesktop.org/show_bug.cgi?id=48588)**
## Description
Created attachment 59837
Add support for disabling extensions through environment variables
This is a patch we have in openSUSE for quite some time that makes it possible to disable an extension with an environment variable.
For instance: export XLIB_SKIP_EXT_MIT_SHM=1
This was apparently needed for some specific app crashing with some extension.
Patch was written by David Reveman.
~~**Patch 59837**~~, "Add support for disabling extensions through environment variables":
[p_xlib_skip_ext_env.diff](/uploads/2a59aa0e92624e47db0bd47ccff56ed5/p_xlib_skip_ext_env.diff)https://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/73Discrepancy between man/code and Xlib spec for XRegisterIMInstantiateCallback2018-08-10T21:37:08ZBugzilla Migration UserDiscrepancy between man/code and Xlib spec for XRegisterIMInstantiateCallback## Submitted by Denis Silakov
Assigned to **Xorg Project Team**
**[Link to original bug (#32802)](https://bugs.freedesktop.org/show_bug.cgi?id=32802)**
## Description
In libX11 code, XRegisterIMInstantiateCallback and XUnregisterI...## Submitted by Denis Silakov
Assigned to **Xorg Project Team**
**[Link to original bug (#32802)](https://bugs.freedesktop.org/show_bug.cgi?id=32802)**
## Description
In libX11 code, XRegisterIMInstantiateCallback and XUnregisterIMInstantiateCallback functions have XIDProc as fifth parameter and XPointer as the sixth one. However, Xlib specification (http://www.x.org/releases/X11R7.6/doc/libX11/specs/libX11/libX11.html) declares these parameters to be XIMProc and 'XPointer *' correspondingly.
This seems to be a long standing issue; man pages were fixed several years ago to correspond the existing implementation (bug #9695), but the specification is still broken.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/13Valgrind report a memory leak eg. in _XlcResolveLocaleName XSetLocaleModifiers2023-03-15T22:54:48ZBugzilla Migration UserValgrind report a memory leak eg. in _XlcResolveLocaleName XSetLocaleModifiers## Submitted by nom..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#31826)](https://bugs.freedesktop.org/show_bug.cgi?id=31826)**
## Description
Created attachment 40466
Valgrind log from my SDL application
...## Submitted by nom..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#31826)](https://bugs.freedesktop.org/show_bug.cgi?id=31826)**
## Description
Created attachment 40466
Valgrind log from my SDL application
I've been attached a valgrind log from my SDL application. It seems like a libX11 has memory leaks. I found a posts in SDL mailing list from 2008 with information similar to my information.
Thanks for reading and please take a look at log.
Best regards, cybek
**Attachment 40466**, "Valgrind log from my SDL application":
[valgrind.log](/uploads/ca09a17b2e87e41b190f54e7632a329c/valgrind.log)
Version: githttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/12[bisected] mesa xdemo/glthreads get some black windows2023-03-15T22:54:48ZBugzilla Migration User[bisected] mesa xdemo/glthreads get some black windows## Submitted by fangxun
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#30450)](https://bugs.freedesktop.org/show_bug.cgi?id=30450)**
## Description
Created attachment 39041
xorg log
System Environment:
-----------...## Submitted by fangxun
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#30450)](https://bugs.freedesktop.org/show_bug.cgi?id=30450)**
## Description
Created attachment 39041
xorg log
System Environment:
--------------------------
Platform: pineview
Libdrm: (master)2.4.21-21-g7ec9a1effa4f551897f91f3b017723a8adf011d9
Mesa: (master)9476efe77ff196993937c3aa2e5bca725ceb0b41
Xserver: (master)xorg-server-1.9.0-71-gc768cdda92696b636c10bb2df64167d5274b4b99
Xf86_video_intel: (master)2.12.0-87-g08c2caca48323d6d5701dcef3486f850619d7905
Kernel: (master)9fe6206f400646a2322096b56c59891d530e8d51
Bug detailed description:
-------------------------
Startx and run mesa xdemo glthreads, we get some black windows, not rotating cub. Sometimes get still cubes. Bisect shows it's caused by LibX11.
933aee1d5c53b0cc7d608011a29188b594c8d70b is the first bad commit.
commit 933aee1d5c53b0cc7d608011a29188b594c8d70b
Author: Jamey Sharp <jamey@minilop.net>
Date: Fri Apr 16 20:18:28 2010 -0700
Fix Xlib/XCB for multi-threaded applications (with caveats).
Rather than trying to group all response processing in one monolithic
process_responses function, let _XEventsQueued, _XReadEvents, and
_XReply each do their own thing with a minimum of code that can all be
reasoned about independently.
Tested with `ico -threads 20`, which seems to be able to make many
icosahedrons dance at once quite nicely now.
Caveats:
- Anything that was not thread-safe in Xlib before XCB probably still
isn't. XListFontsWithInfo, for instance.
- If one thread is waiting for events and another thread tries to read a
reply, both will hang until an event arrives. Previously, if this
happened it might work sometimes, but otherwise would trigger either
an assertion failure or a permanent hang.
- Versions of libxcb up to and including 1.6 have a bug that can cause
xcb_wait_for_event or xcb_wait_for_reply to hang if they run
concurrently with xcb_writev or other writers. So you'll want that fix
as well.
Reproduce steps:
----------------
1. xinit &
2. ./glthreads -n 6
**Attachment 39041**, "xorg log":
[Xorg.0.log](/uploads/a04f2e630d38459b103fcd25479ea665/Xorg.0.log)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/74Man pages should mention header files2018-08-10T21:37:14ZBugzilla Migration UserMan pages should mention header files## Submitted by dgatwood
Assigned to **Xorg Project Team**
**[Link to original bug (#29402)](https://bugs.freedesktop.org/show_bug.cgi?id=29402)**
## Description
I recently received a complaint from some folks downstream from me t...## Submitted by dgatwood
Assigned to **Xorg Project Team**
**[Link to original bug (#29402)](https://bugs.freedesktop.org/show_bug.cgi?id=29402)**
## Description
I recently received a complaint from some folks downstream from me that the Xlib man pages don't mention which headers various functions appear in. Although it is certainly possible for folks to grep for it (assuming they are reasonably command-line savvy), that's really not the best way to get things done, particularly in this day and age when there are GUI IDE users who wouldn't know a CLI from a CFL. :-)
So please consider adding the header information to the pages wherever possible. (The specific page this particular developer was complaining about was the XLoadQueryFont man page.)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/10Lots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != ...2023-03-15T22:54:48ZBugzilla Migration UserLots of processes crash in XCreatePixmap() with _XAllocID: Assertion `ret != inval_id' failed## Submitted by Martin Pitt
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#27552)](https://bugs.freedesktop.org/show_bug.cgi?id=27552)**
## Description
libx11, 1.3.2 (sorry, I didn't see a libX11 component)
We are...## Submitted by Martin Pitt
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#27552)](https://bugs.freedesktop.org/show_bug.cgi?id=27552)**
## Description
libx11, 1.3.2 (sorry, I didn't see a libX11 component)
We are getting tons of crash reports in Ubuntu (https://launchpad.net/bugs/507062) about programs crashing with
_XAllocID: Assertion `ret != inval_id' failed
At first we thought this would be the same problem that was recently discussed and fixed in libXext:
http://lists.freedesktop.org/archives/xcb/2009-October/005102.html
http://cgit.freedesktop.org/xorg/lib/libXext/commit/?id=956fd30e1046e5779ac0b6c07ec4f0e87250869a
However, we already have that fixed version, and the stack traces of above bug reports does not go through XShmAttach(), so it does seem to be a different cause.
They all have this piece in common:
```
#4 0xb74d7199 in _XAllocID (dpy=0x8116770) at ../../src/xcb_io.c:378
ret = 4294967295
__PRETTY_FUNCTION__ = "_XAllocID"
#5 0xb74ad048 in XCreatePixmap (dpy=0x8116770, d=265, width=24, height=24,
depth=32) at ../../src/CrPixmap.c:58
```
i. e. they all come through XCreatePixmap() (which is called from various functions in the duplicate bugs, like XcursorImageLoadCursor(), _cairo_xlib_surface_create_similar_with_format(), etc.)
I checked that the current libX11's XCreatePixmap() already calls _XAllocID() in a LockDisplay() block, so it's not the same cause as the recent libXext fix.
Beyond that I'm afraid I don't know enough about this API to be able to continue debugging on my own. Obviously nothing must call _XAllocID() two times in succession without an _XIDHandler() in between (the only other place where next_xid is set is _XConnectXCB(), but that's only called on program initialization through XOpenDisplay(), right?)
Do you have some further hints how to debug this, or what could go wrong here?
For reference, here are some links to the full stack traces:
http://launchpadlibrarian.net/23717282/Stacktrace.txt
http://launchpadlibrarian.net/35702381/Stacktrace.txt
http://launchpadlibrarian.net/39577843/Stacktrace.txt
http://launchpadlibrarian.net/37855566/Stacktrace.txt
Thanks!https://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/7Return value from xcb_generate_id() not checked2023-03-15T22:54:48ZBugzilla Migration UserReturn value from xcb_generate_id() not checked## Submitted by Alexey Feldgendler
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#23690)](https://bugs.freedesktop.org/show_bug.cgi?id=23690)**
## Description
xcb_generate_id() returns -1 (well, ~0) under some erro...## Submitted by Alexey Feldgendler
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#23690)](https://bugs.freedesktop.org/show_bug.cgi?id=23690)**
## Description
xcb_generate_id() returns -1 (well, ~0) under some error conditions. However, _XIDHandler() in Xlib doesn't check for it, and if this value is returned, it's saved in dpy->xcb->next_xid and causes an assertion failure in _XAllocID() at a later point.
This is my guess as to what happened here: https://bugs.kde.org/show_bug.cgi?id=192468 -- I mean, it's the only concievable codepath leading to that assertion being triggered.
The return value from xcb_generate_id() should be checked, and errors should be handled gracefully.
Version: 7.3 (2007.09)https://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/6Error in XGetWindowProperty() when it's called very often2023-03-15T22:54:48ZBugzilla Migration UserError in XGetWindowProperty() when it's called very often## Submitted by Vasily
Assigned to **Xorg Project Team**
**[Link to original bug (#22815)](https://bugs.freedesktop.org/show_bug.cgi?id=22815)**
## Description
I've got a problem with xlib when I call XGetWindowProperty after new ...## Submitted by Vasily
Assigned to **Xorg Project Team**
**[Link to original bug (#22815)](https://bugs.freedesktop.org/show_bug.cgi?id=22815)**
## Description
I've got a problem with xlib when I call XGetWindowProperty after new event has been received (with XNextEvent(m_display, &evt);). It seems to be an accidental bug and I can reproduce it only on my PC with Debian squeeze(testing state). (May be you need some info, so ask me please. I'm a newbie in it)
So, some application calls XConvertSelection and my app receives event with SelectionNotify type. And then I call XGetWindowProperty. XConvertSelection is called very fast and eventually I've got the following stack:
```
#0 0xb78ec806 in exit () from /lib/i686/cmov/libc.so.6
#1 0x08ce6ab1 in qt_xio_errhandler () at kernel/qapplication_x11.cpp:707
#2 0xb7bd88b6 in _XIOError () from /usr/lib/libX11.so.6
#3 0xb7be08f7 in _XReply () from /usr/lib/libX11.so.6
#4 0xb7bbddb3 in XGetWindowProperty () from /usr/lib/libX11.so.6
......
```
The first routine from GetProp.c:
XGetWindowProperty(...........
{
xGetPropertyReply reply;
register xGetPropertyReq *req;
xError error;
LockDisplay(dpy);
GetReq (GetProperty, req);
req->window = w;
req->property = property;
req->type = req_type;
req->delete = delete;
req->longOffset = offset;
req->longLength = length;
error.sequenceNumber = dpy->request;
if (!_XReply (dpy, (xReply *) &reply, 0, xFalse)) {
The second routine _XReplay from XlibInt.c:
We can get _XIOError only in one place if the following comparison is false:
if (extra <= rep->generic.length)
but extra is the third argument of _XReplay (number of 32-bit words expected after the reply) which is zero! We compare int extra with rep->generic.length which is unsigned (right?) and don't go to "if" block.
I don't understand the reason why can rep->generic.length be wrong(very large)? And why does xlib compare signed length with unsigned one?
PS
X -version gives
version number: 11.0
X.Org version: 1.4.2https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/53Add compose sequences from gtk+ to X.Org2018-08-10T20:11:46ZBugzilla Migration UserAdd compose sequences from gtk+ to X.Org## Submitted by Simos Xenitellis
Assigned to **Xorg Project Team**
**[Link to original bug (#18751)](https://bugs.freedesktop.org/show_bug.cgi?id=18751)**
## Description
Created attachment 20644
Compose sequences (originating from...## Submitted by Simos Xenitellis
Assigned to **Xorg Project Team**
**[Link to original bug (#18751)](https://bugs.freedesktop.org/show_bug.cgi?id=18751)**
## Description
Created attachment 20644
Compose sequences (originating from gtk+)
The compose sequences in the attachment used to exist in gtk+
but are not found in the current X.Org Compose (en_US.UTF-8) file.
A large group of these compose sequences are of the form
`<Multi_key>` `<A>` `<acute>` : "Á" U00C1
`<Multi_key>` `<a>` `<acute>` : "á" U00E1
which is 'letter' first, then 'punctuation'.
X.Org's Compose file does not have this type of sequence (has 'punctuation', then 'letter').
What I would like is a comment on which sequences are OK to add to X.Org's Compose.
I can file then individual reports, etc.
references: http://bugzilla.gnome.org/show_bug.cgi?id=557420
~~**Attachment 20644**~~, "Compose sequences (originating from gtk+)":
[gtk-compose-lookaside.txt](/uploads/337bbe5ce005214c3beb32dab4d4c6fb/gtk-compose-lookaside.txt)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/4x11proto/keysymdef.h and libX11/src/KeyBind.c have gotten out of sync2024-01-08T16:02:21ZBugzilla Migration Userx11proto/keysymdef.h and libX11/src/KeyBind.c have gotten out of sync## Submitted by James Cloos `@cloos`
Assigned to **Xorg Project Team**
**[Link to original bug (#12079)](https://bugs.freedesktop.org/show_bug.cgi?id=12079)**
## Description
A comment in x11proto/xkeysymdef.h says to keep it in sy...## Submitted by James Cloos `@cloos`
Assigned to **Xorg Project Team**
**[Link to original bug (#12079)](https://bugs.freedesktop.org/show_bug.cgi?id=12079)**
## Description
A comment in x11proto/xkeysymdef.h says to keep it in sync with xc/lib/X11/KeyBind.c (now libX11/src/KeyBind.c) and the protocol definition in xc/doc/specs/XProtocol/X11.keysyms (now xorg-docs/specs/XProtocol/X11.keysyms).
I’m preparing a patch for the latter.
As for KeyBind.c, I see two issues:
First, it #defines a subset of the #ifdefs in keysymdef.h before explicitly #including it. That could be cured by #including keysym.h instead, which already does that heavy lifting, and is more likely to be kept in sync with keysymdef.h.
Second, it has code to do case mapping, but that — according to the comments — has not been updated to reflect characters added to the UCS since Unicode version 4.0. That likely should be expanded to include the new characters.
Version: githttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/72XDrawArc man page maths come out bad on tty2018-08-10T21:36:57ZBugzilla Migration UserXDrawArc man page maths come out bad on tty## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#9946)](https://bugs.freedesktop.org/show_bug.cgi?id=9946)**
## Description
The following bug has been reported to the Debian BTS 2...## Submitted by Brice Goglin `@bgoglin`
Assigned to **Xorg Project Team**
**[Link to original bug (#9946)](https://bugs.freedesktop.org/show_bug.cgi?id=9946)**
## Description
The following bug has been reported to the Debian BTS 2 months ago by Kevin Ryde.
Brice
On a tty, the eqn math bits in "man XDrawArc" come out looking like
[x+wi2th,y+hei2ht]
or
2n for normal-angle in the range [32,2n]
which makes it pretty hard to understand.
Apparently gnu eqn and/or nroff aren't interested in trying to render
maths on a tty. It'd be nice if XDrawArc could have alternative bits
(".ie n" conditions) that come out better, "[x+width/2,y+height/2]"
and "[3*pi/2,2*pi]" etc.
Version: 7.1 (2006.05)