Bug 236371 - We cannot run windows applications on Wine because of libX11
We cannot run windows applications on Wine because of libX11
Product: Fedora
Classification: Fedora
Component: libX11 (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
Depends On:
  Show dependency treegraph
Reported: 2007-04-13 10:17 EDT by thsacnc
Modified: 2014-06-18 05:09 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-15 09:38:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xorg.conf (1.99 KB, application/octet-stream)
2007-04-14 00:19 EDT, thsacnc
no flags Details
Xorg.93.log (64.62 KB, text/plain)
2007-04-14 00:19 EDT, thsacnc
no flags Details
Xgl.0.log (4.21 KB, text/plain)
2007-04-14 00:22 EDT, thsacnc
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 1182 None None None Never

  None (edit)
Description thsacnc 2007-04-13 10:17:53 EDT
Description of problem:
All attempts to create windows on Wine, including "Wine Configuration", fails(No
window apears or no window-content is shown) because of libX11. I'm using SCIM
in Japanese environment. According to the
site(http://bbs.fedora.jp/read.php?FID=10&TID=4828), we need to patch libX11
because it does not treate DisplayLock correctly.

the patch is:

--- libX11-1.0.3/src/FilterEv.c.org  2006-06-23 06:22:23.000000000 +0900
+++ libX11-1.0.3/src/FilterEv.c      2006-11-27 16:35:24.000000000 +0900
@@ -96,9 +96,9 @@
	if (win == p->window) {
	    if ((mask & p->event_mask) ||
		(ev->type >= p->start_type && ev->type <= p->end_type)) {
+		UnlockDisplay(ev->xany.display);
		ret = (*(p->filter))(ev->xany.display, p->window, ev,
-		UnlockDisplay(ev->xany.display);
--- libX11-1.0.3/modules/im/ximcp/imDefLkup.c.org	2006-11-29 10:50:44.000000000
+++ libX11-1.0.3/modules/im/ximcp/imDefLkup.c	2006-11-29 10:57:06.000000000 +0900
@@ -482,7 +482,7 @@
     Xim			im = (Xim )ic->core.im;
     XWindowAttributes	atr;
-    if (!_XGetWindowAttributes(im->core.display, ic->core.focus_window, &atr))
+    if (!XGetWindowAttributes(im->core.display, ic->core.focus_window, &atr))
 	return 0;
     return (EVENTMASK)atr.your_event_mask;
--- libX11-1.0.3/modules/im/ximcp/imLcFlt.c.org	2006-06-23 07:27:10.000000000 +0900
+++ libX11-1.0.3/modules/im/ximcp/imLcFlt.c	2006-11-29 10:57:10.000000000 +0900
@@ -104,7 +104,7 @@
 	    ic->private.local.brl_committed = 0;
 	    /* return back to client KeyPressEvent keycode == 0 */
 	    ev->xkey.keycode = 0;
-	    _XPutBackEvent(d, ev);
+	    XPutBackEvent(d, ev);
 	    /* initialize internal state for next key sequence */
 	    ic->private.local.context = ((Xim)ic->core.im)->private.local.top;

(quoted from above page.)
I strongly hope the patch is embedded officially because we must recompile
sources whenever libX11 is updated.

Version-Release number of selected component (if applicable):

all of libX11-1.0.3-X
Wine 0.9.23 or latter
Comment 1 Matěj Cepl 2007-04-13 17:56:54 EDT
How much have you personally tried and tested this patch on computers under your
own management?

Just to be sure, could you please attach to this bug as uncompressed separate
attachments /etc/X11/xorg.conf and /var/log/Xorg.*.log files?

Thank you.
Comment 2 thsacnc 2007-04-14 00:19:03 EDT
Created attachment 152603 [details]
Comment 3 thsacnc 2007-04-14 00:19:31 EDT
Created attachment 152604 [details]
Comment 4 thsacnc 2007-04-14 00:22:16 EDT
Created attachment 152605 [details]

I usually use Xgl instead of Xorg, so I also add the log. I'm sure this bug is
not related to Xgl but libX11 because same result can be seen even under Xorg.
Comment 5 thsacnc 2007-04-14 00:25:59 EDT
Oh, I'm sorry that I tested the patch only on 1 computer. But according to the
other homepages, many people resolved quite the same problem on Wine with this

I found original article at:

Best Regards,
Comment 6 Matěj Cepl 2007-12-10 04:23:33 EST
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]
Comment 7 Matěj Cepl 2008-01-15 09:38:33 EST
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional


{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}

Note You need to log in before you can comment on or make changes to this bug.