Some XFree86 keysyms were in XKeysymDB as XF86_foo, despite really being
XF86foo. So, if we get to the bottom of XStringToKeysym and haven't
found our XF86_foo, try it again as XF86foo.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
AC_DEFINE_DIR is deprecated as it's squatting on the autoconf-builtin
namespace, so start using the more proper AX_DEFINE_DIR instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This makes the UTF-8 compose file consistent with the ISO 8859-2 compose file
as far as Polish is concerned. We only sacrifice one pair of characters,
e-cedilla, which is not used in any language.
Don't lose async replies. That's bad.
`xlsfonts -l`, which uses XListFontsWithInfo, worked fine, because the
_XReply path worked; that path waited for replies, rather than polling.
However, XRecordProcessReplies, which does nothing but call XPending,
relied on the event-handling path to process async replies, and that was
busted.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28595
Signed-off-by: Jamey Sharp <jamey@minilop.net>
This reverts commit 4a8b6528ff, because as
a matter of fact, if poll_for_response returns NULL when we know
dpy->xcb->next_event is non-NULL, there *is* guaranteed to be a pending
request.
Don't lose async replies. That's bad.
`xlsfonts -l`, which uses XListFontsWithInfo, worked fine, because the
_XReply path worked; that path waited for replies, rather than polling.
However, XRecordProcessReplies, which does nothing but call XPending,
relied on the event-handling path to process async replies, and that was
busted.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28595
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
This patch adds Annex 4 of SFS 5966 for Finland and fixes two typos in
Annex 3 (which were actually copied verbatim from the standard text).
The implementation of the standard is now complete.
X.Org bug#28498 <https://bugs.freedesktop.org/show_bug.cgi?id=28498>
Signed-off-by: Julien Cristau <jcristau@debian.org>
One of the malloc failure checks had a goto to the wrong spot in the
list of cleanup free() calls to unwind at the end, and was freeing
bits that hadn't been initialized/allocated yet, since they would be
stored in the struct that just failed to be allocated.
Error: Null pointer dereference (CWE 476)
Read from pointer that could be constant 'NULL'
at line 805 of /export/alanc/X.Org/sx86/lib/libX11/src/xcms/LRGB.c in function 'LINEAR_RGB_InitSCCData'.
Pointer checked against constant 'NULL' at line 754 but does not protect the dereference.
[ This bug was found by the Parfait bug checking tool.
For more information see http://research.sun.com/projects/parfait ]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
None of the functions in Xprivate.h should have any callers outside of
Xlib, by definition.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Suggested-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Commit a6d974dc59 made _XSeqSyncFunction
non-static, but we don't need to export it.
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
And there was much rejoicing.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Consensus on #xorg-devel agrees with removing --without-xcb; in
particular, acks from Adam Jackson, Daniel Stone, Kristian Høgsberg,
Julien Cristau, and Rémi Cardona.
At least with the groff 1.19.2 package I have installed, groff passes
on the -I flags for the include path to grohtml, which if they come
after the -P-I... flag we pass to grohtml to specify the image file
name pattern cause it to override that flag and put the images in
the wrong place, breaking "make distcheck" - changing the flag order
works around this.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Adaptation of patch submitted by Paul Bender in attachment 27301 to
https://bugs.freedesktop.org/show_bug.cgi?id=22584
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
The required common parent window is not specified in the arguments,
just implied as the parent of the first window in the list.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If we fail to connect to a UNIX socket and the transport isn't specified,
fallback on TCP. This matches behavior with the xtrans codepath and the
Xlib spec.
http://lists.x.org/archives/xorg-devel/2010-April/007915.html
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
ssh gets confused by this. XQuartz is the only DDX using this
functionality, and it doesn't support different screens, so
let's just not include this until most ssh know how to handle
this.
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
imLcIm.c: In function '_XimCachedFileName':
imLcIm.c:361: warning: format '%03x' expects type 'unsigned int', but argument 8 has type 'long unsigned int'
imLcIm.c:364: warning: format '%03x' expects type 'unsigned int', but argument 8 has type 'long unsigned int'
imRm.c: In function '_XimDefaultArea':
imRm.c:597: warning: cast from pointer to integer of different size
imRm.c: In function '_XimDefaultColormap':
imRm.c:626: warning: cast from pointer to integer of different size
lcFile.c:224: warning: no previous prototype for 'xlocaledir'
lcUTF8.c: In function 'iconv_cstombs':
lcUTF8.c:1841: warning: assignment discards qualifiers from pointer target type
lcUTF8.c:1869: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c:1873: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c: In function 'iconv_mbstocs':
lcUTF8.c:1935: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_mbtocs':
lcUTF8.c:2031: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_mbstostr':
lcUTF8.c:2121: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_strtombs':
lcUTF8.c:2180: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c: In function '_XlcAddGB18030LocaleConverters':
lcUTF8.c:2367: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2368: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2373: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2374: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2375: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2376: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2377: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
XlibInt.c: In function '_XGetHostname':
XlibInt.c:3441: warning: implicit declaration of function 'gethostname'
XlibInt.c:3441: warning: nested extern declaration of 'gethostname'
ConnDis.c: In function '_XDisconnectDisplay':
ConnDis.c:540: warning: old-style function definition
ConnDis.c: In function '_XSendClientPrefix':
ConnDis.c:554: warning: old-style function definition
ConnDis.c: In function 'XSetAuthorization':
ConnDis.c:677: warning: old-style function definition
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
I can easily compose the hammer and sickle (the symbol representative
of communism) by pressing the key sequence:
<Compose> <C> <C> <C> <P> -> ☭
But i can't easily make the circled A (the symbol representative of
anarchism).
I'd like to be able to use <Compose> <O> <A> (this is a
currently unused key sequence) to generate the symbol: Ⓐ
Debian bug#555938 <http://bugs.debian.org/555938>
Signed-off-by: Julien Cristau <jcristau@debian.org>
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.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
It's easier to reason about the code when we can't re-enter the
Xlib-private sync-handlers while they're already running.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
_XSend was off-by-one on both ends. It should not re-enqueue the last
request that was already flushed, but it should enqueue the last request
currently being flushed.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
Replace insert_pending_request, which did an in-order search of the
queue to find the right insertion point, with a simpler
append_pending_request, and use that in _XSend as well.
Includes assertions to check that the list of pending requests is in
order by sequence number and does not have duplicates.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
_XIDHandler and _XSeqSyncFunction originally ran from dpy->synchandler, and
thus had to return an int. Now, they only run from _XPrivSyncHandler or
LockDisplay, neither of which needs to check their return value since they
always returned 0. Make them both void.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
XID and sync handling happened via _XPrivSyncHandler, assigned to
dpy->synchandler and called from SyncHandle. _XPrivSyncHandler thus ran
without the Display lock, so manipulating the Display caused races, and
these races led to assertions in multithreaded code (demonstrated via
ico).
In the XTHREADS case, after you've called XInitThreads, we can hook
LockDisplay and UnlockDisplay. Use that to run _XIDHandler and
_XSeqSyncHandler from LockDisplay rather than SyncHandle; we then know
that we hold the lock, and thus we can avoid races. We think it makes
sense to do these both from LockDisplay rather than UnlockDisplay, so
that you know you have valid sync and a valid XID before you start
setting up the request you locked to prepare.
In the !XTHREADS case, or if you haven't called XInitThreads, you don't
get to use Xlib from multiple threads, so we can use the logic we have
now (with synchandler and savedsynchandler) without any concern about
races.
This approach gets a bit exciting when the XID and sequence sync
handlers drop and re-acquire the Display lock. Reacquisition will re-run
the handlers, but they return immediately unless they have work to do,
so they can't recurse more than once. In the worst case, if both of
them have work to do, we can nest the Display lock three deep. In the
case of the _XIDHandler, we drop the lock to call xcb_generate_id, which
takes the socket back if it needs to request more XIDs, and taking the
socket back will reacquire the lock; we take care to avoid letting
_XIDHandler run again and re-enter XCB from the return_socket callback
(which causes Very Bad Things, and is Not Allowed).
Tested with ico (with 1 and 20 threads), and with several test programs
for XID and sequence sync. Tested with and without XInitThreads(), and
with and without XCB.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=23192
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Under some circumstances, errors are picked up by calling
xcb_poll_for_reply, rather than xcb_poll_for_event, because Xlib issued
the requests with the XCB_REQUEST_CHECKED flag. That happens when either
an async handler is queued at the time the requests are flushed, or when
XSetEventQueueOwner has been used to prevent Xlib from processing XCB's
event queue.
This bugfix extends 405132dab6 to cover
those cases.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=26545
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Apparently I misread XlibInt.c:_XReply and thought that handlers set
with XESetError should be consulted only for the sequence number that
_XReply is currently looking for. In fact, the error handlers are also
consulted when an error arrives for a request that was not expected to
have a reply.
However, in an odd twist, the error handlers are *not* consulted outside
of _XReply--that is, when looking for events, or waiting to be able to
flush the output queue. So this patch takes some small pains to preserve
that behavior, though it seems likely to have been unintentional.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=26545
Signed-off-by: Jamey Sharp <jamey@minilop.net>
This mask has probably been renamed but not been updated in the manuals.
Signed-off-by: Dirk Wallenstein <dirkwallenstein@t-online.de>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
The XkbKeyActionEntry macro expands to a pointer.
Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
XKeycodeToKeysym keeps compatibility with pre-XKB and thus only sees 2
groups with 2 levels each. It wraps the index into the next group.
This behavior confuses the unaware user, and therefore this will add a
reference to XkbKeycodeToKeysym in the corresponding man paragraph.
Another bug had that issue, too. #5349
Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
I've rewritten the fi_FI.UTF-8 Compose file so that it
- includes en_US.UTF-8/Compose for base compose definitions (and thus gets any
possible additions to en_US.UTF-8/Compose automatically included)
- overrides any en_US.UTF-8/Compose definitions with fi_FI.UTF-8/Compose
definitions (thus making it safe to include en_US.UTF-8/Compose)
- lists all the definitions specified in the SFS 5966 standard (thus making it
easy to verify that the implementation is valid and complete)
- adds a header about the file itself as required by the standard
The rewritten version is ~320 lines compared to over 5000 lines of the previous
version.
https://bugs.freedesktop.org/show_bug.cgi?id=27465
