Re: Excess MotionNotify events to a minimized window in multiwindow mode
On 10/12/2012 19:01, Heiko Bihr wrote: I think, there is a problem with mouse polling in multiwindow mode (XWin.exe :0 -multiwindow) in Cygwin/X 1.13. If a window gets maximized and then minimized, it will receive motion notify events, whenever the user moves the mouse cursor over the screen. To reproduce the problem, please follow these steps: 1) start XWin.exe in -multiwindow mode 2) start xev 3) maximize xev window 4) minimize xev window 5) move mouse cursor around and watch xev output You will see lots of MotionNotify events from all over the screen. X.org does not show this behaviour and I think, Cygwin/X should not either. I'm not sure I follow your reasoning. If you run 'xev -root', you can see that MotionNotify events are sent from everywhere. Is there some specific problem you are trying to fix? The problem is caused by the WIN_POLLING_MOUSE_TIMER_ID, which doesn't get stopped, when the user minimizes a window. I made a small patch against Cygwin/X 1.13.0-1 which will stop the WIN_POLLING_MOUSE_TIMER_ID, whenever the user minimizes a window. If the user changes the window's size again, and the timer was stopped, it will be started again. The patch introduces a new flag in s_pScreenPriv to remember the state of the timer. Thanks for the patch. There are definitely some things wrong with the way that this mouse pointer polling timer works, I noticed during testing that is was possible sometimes to move the pointer out of an xeyes without starting the polling timer. I'm not sure this patch is right though: With this patch applied, if you have 2 xeyes running, minimizing the first one stops the second one from tracking the mouse pointer. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Right control key creating window causes control state to be stuck
On 28/11/2012 13:56, Chad Gatesman wrote: I have been struggling with a problem in Cygwin/X for quite a while, now, and I'm surprised more people haven't been having issues with it. I will try to explain it with an example: If you are in Nedit, and hit Ctrl+F to do a Find, naturally, you would type RCtrl+F (not LCtrl). When you do this, the Find dialog comes up, but the Control state is stuck on, and anything you try to type in the Find dialog just types control characters. This problem does not occur if you type LCtrl+F to bring up the Find dialog, but that is not the natural typing Control key to press in conjunction with F. Doing some research, it looks like this problem has been discussed, before, and a patch was even put together. But for whatever reason, it was dismissed. See:http://cygwin.com/ml/cygwin-xfree/2012-03/msg1.html I am posting this issue again in hopes this defect is taken a second look to be considered more important than it has in the past. It's not correct to say that the patch was 'dismissed'. It had some technical issues and until someone worked on them, it wasn't going to get applied. Anyhow, as part of some other work, I recently looked over this patch again, and fixed those problems, so this fix should be included in the next cygwin Xserver release. I've uploaded a snapshot at [1]. Perhaps you could try that and see if it fixes the issue for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20121130-git-517ae9c3f7a77fe2.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: A Broken Link on Your Site About Virtual Network Computing
On 27/11/2012 00:00, Jacinda Frost wrote: I came across your website and wanted to notify you about a broken link on your page in case you weren't aware of it. The link on x.cygwin.com/links.html which links to http://www.uk.research.att.com/vnc/ is no longer working. I've included a link to a useful page on Virtual Network Computing that you could replace the broken link with if you're interested in updating your website. Thanks for providing a great resource! Thanks for pointing this out. Since that page isn't linked to by anything else on x.cygwin.com anymore, half the links were broken and none of them were very useful, I've just removed it. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cygwin/X X Server 1.12.3 Middle Click Problem
On 18/11/2012 20:57, Taylor Lilly wrote: I am running Windows 7 Enterprise SP1 on a Dell Latitude XT2 with an external Dell 3 button (scroll wheel) optical mouse. I have Cygwin package cygwin-1.7.16-1 installed with the packages in the user guide suggested for Xwin capability and SSH. My intention for use is to SSH to a Ubuntu boxes and mostly run Xemacs to program. My main problem is not being able to get the middle click to be recognized in the Xwindows, including xterm local, as a paste. I have tried a different combination of software, namely Xming and Putty, but with no greater success. I also tried an older version of Cygwin from 2010, again to no success. The mouse middle button is recognized by the windows operating system and is in the auto scroll mode under the mouse settings. I guess that the problem here isn't Windows 7, but that you have some extra mouse or touchpad software installed which tries to do something 'helpful' like scrolling the window, rather than sending button press/release events when the middle button is clicked. (I don't have anything mentioning auto scroll in the control panel mouse applet on W7) You need to turn off, uninstall or instruct that software to pass middle button clicks to the X server without meddling. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: How to disable focus stealing prevention in XWin Xorg Multi-Window
On 18/10/2012 17:26, Jim Steed wrote: I have an X windows program that uses multiple windows and has buttons to bring up the other windows to the top. These buttons don't work (have no effect) in the default settings of Cygwin's Xorg port due to focus stealing prevention. I'm afraid your diagnosis is incorrect. It's a long-standing defect in multiwindow mode that no attempt is made to synchronize changes in the X window Z-order (e.g. made by XRaiseWindow()) to the native Windows window Z-order. See, for example [1] for some discussion about why this isn't easy to fix. I have a little background with this in Linux as I know the magic in KDE to disable focus stealing prevention and get these buttons to work. Is there a similar setting I can make to XWin Server's startxwin.exe to disable this? I have noted that twm and WindowMaker do not prevent focus stealing, and my program works fine in those window managers. However, for look and feel, I would much prefer it to closer integrated into Microsoft Windows with the multi-window approach. [1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00034.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xserver compile err
On 27/09/2012 18:46, J. Offerman wrote: On Thu, Sep 27, 2012 at 5:38 AM, Jon TURNEY wrote: I'm slightly curious to know if there is something wrong with the X server binary package I produce, since you always seem to want to build your own? Nothing is wrong with your binaries and I'm grateful to you for maintaining this wonderful thing called Cygwin X server. I just have a few things about it that do not go well with my taste. But I'm not foolish enough to say that the rest of the world should adapt to my taste, so I keep them to myself and end up applying my own patch everytime I build it. I think I've been doing this since Tears For Fears tried to rule the world from your country. It used to be more files, now it's only one file, winwndproc.c. I'm delighted the world is catching up with me. :) All patches thoughtfully considered. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
On 16/10/2012 21:34, Tim Edwards wrote: The current implementation of GLX using WGL takes a few shortcuts, basically anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. I wouldn't want to sound too peevish, as I was quite happy to find that OpenGL hardware acceleration was even possible, as it was not on the previous version of Cygwin that I had downloaded. That it fails in obscure applications is sort of to be expected. This works well enough when the GLX window is a top-level window, or is non-top-level and has no occluding relatives and is drawn after anything it occludes, but mis-renders in more complex scenarios. This is discussed a bit more in [1] As mentioned there I have done a bit of work fix the mis-rendering in some cases. I can't quite tell from you description exactly what's going wrong, so I am not sure if those changes are going to help in this particular case. I have built a test release including the changes discussed there, available at [2], if you would like to test if it makes things better/worse/no difference. I downloaded the link, ran the X server, ran my application, and get no difference in the behavior. Ok. Thanks for testing, anyhow. The proper solution is probably something like rendering the OpenGL to an offscreen buffer, and then composing it into the un-occluded area of the window, but that is considerably more complex to implement. The two problems with this approach are that (1) I have found more buggy implementations in OpenGL servers by doing offscreen rendering; and (2) this particular tool is a VLSI layout editor and must be rendered directly on the front buffer. The general approach is to render everything as fast as possible and always be willing to break on key interrupt to start over. And I have misappropriated the back buffer for backing store purposes. . . Sorry, I wasn't clear here. I'm not suggesting that the application should be changed. I'm just describing a possible approach to fixing this problem in the X server. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Probable bug in WGL implementation (AIGLX) of GLX calls in XWin -wgl
On 01/10/2012 22:34, Tim Edwards wrote: I have a tool I maintain called magic, a VLSI layout editor. One of its nicer features is a graphics mode based on OpenGL. Occasionally I generate Cygwin versions of it, and was delighted to discover on my last update of Cygwin that there is a support for hardware-accelerated OpenGL using some translation between GLX and WGL calls at the level of the X server. I tried using this with my Cygwin version of magic, and for the most part it works. But it does have the strange effect of overwriting the OpenGL window with contents of other windows. My setup is very non-standard but works under Linux and OS-X. The application is built as an extension of Tcl/Tk. Because the application makes all the OpenGL calls from C routines, it generates a generic window using a call to Tk_CreateWindow(), and maps it using Tk_MapWindow(). The returned window is then passed to glXMakeCurrent(). All of this works fine. The window that is used for the OpenGL rendering is framed by scrollbars on the side and bottom that are canvas windows in Tk. What I am seeing is that any time the scrollbars are redrawn, the OpenGL window is over-drawn, looks like with the default Tk background gray color. A similar thing happens if I pop a window on top of the OpenGL window; when I pop it down, the image of the window remains in the OpenGL window. I presume that in the way GLX is supposed to work, X11 has reserved pixmap space somewhere for the window, but once the call to glXMakeCurrent() has been made, the contents of this pixmap should not show up on the screen. Yet that is what I am seeing. Any clue as to what might be going on? Yes, unfortunately. The current implementation of GLX using WGL takes a few shortcuts, basically anything that is drawn with OpenGL isn't composed into the screen, it's just drawn on top of it. This works well enough when the GLX window is a top-level window, or is non-top-level and has no occluding relatives and is drawn after anything it occludes, but mis-renders in more complex scenarios. This is discussed a bit more in [1] As mentioned there I have done a bit of work fix the mis-rendering in some cases. I can't quite tell from you description exactly what's going wrong, so I am not sure if those changes are going to help in this particular case. I have built a test release including the changes discussed there, available at [2], if you would like to test if it makes things better/worse/no difference. The proper solution is probably something like rendering the OpenGL to an offscreen buffer, and then composing it into the un-occluded area of the window, but that is considerably more complex to implement. One I tarball up this version of magic, I can send a pointer to where it can be obtained if anybody wants to download it and test for the bug. Thanks. This would be useful as a test case for any future work to improve this. [1] http://sourceware.org/bugzilla/show_bug.cgi?id=10472 [2] ftp://cygwin.com/pub/cygwinx/XWin.20121012-git-3807fe48a7282459.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Graphical glitch in all but multiwindow mode over remote desktop
On 04/10/2012 09:00, Erik Fonnesbeck wrote: This is on Windows Server 2008 R2 with desktop composition enabled over remote desktop and using Cygwin/X 1.12.4 (though I have not seen any release notes mentioning a fix for it, so I'm guessing it is still relevant in the current version). Windows 7 should be relevant for testing this bug as well. I do not recall testing without desktop composition enabled for the remote desktop session, and I do not know whether the issue is specific to Windows 7/Server 2008 R2. Multiwindow mode works fine, but all other modes draw on the taskbar instead of in the Cygwin/X window. I have tried various combinations of settings for the X server, but the behavior is the same in all cases. Did you try adding '-engine 1' option to the X server command line? All modes apart from multiwindow use DirectX drawing by default, and there have been reports that doesn't work correctly over RDP. (From my brief research, this may be related to the DirectX version which Xwin uses. DirectX over RDP, rendering on the host, is supposed to work since Vista, but only for DX9 or later clients, and XWin uses an older DX interface) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.13.0-1 (TEST)
On 01/10/12 17:38, Jim Reisert AD1C wrote: On Fri, Sep 7, 2012 at 10:15 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.13.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.13 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. Hi Jon, It's been three weeks, what's the status on this? Three is approximately two. These packages have been promoted from test to current. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xserver compile err
On 27/09/2012 01:13, J. Offerman wrote: I'm trying to compile 1.12.4 now. Last time I tried in April 2012 with 1.12.0, I (still) had to do this: http://cygwin.com/ml/cygwin-xfree/2011-10/msg00065.html This was for 1.11.1. Anyways, even with --disable-glx-tls, the build fails now. It complains about something similar, __glapi_Dispatch. What should I do now? Thanks. CCLD touch.exe ./.libs/libxservertest.a(glxcmds.o): In function `FlushContext': /usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:221: undefined reference to `__glapi_Dispatch' ./.libs/libxservertest.a(glxcmds.o): In function `DoMakeCurrent': /usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:610: undefined reference to `__glapi_Dispatch' ./.libs/libxservertest.a(glxcmds.o): In function `__glXDisp_WaitGL': /usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:789: undefined reference to `__glapi_Dispatch' ./.libs/libxservertest.a(glxcmds.o): In function `__glXDisp_CopyContext': /usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:887: undefined reference to `__glapi_Dispatch' ./.libs/libxservertest.a(glxcmds.o): In function `__glXDisp_SwapBuffers': /usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:1626: undefined reference to `__glapi_Dispatch' ./.libs/libxservertest.a(glxcmds.o):/usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/glx/glxcmds.c:1828: more undefined references to `__glapi_Dispatch' follow collect2: ld returned 1 exit status Makefile:717: recipe for target `touch.exe' failed make[2]: *** [touch.exe] Error 1 make[2]: Leaving directory `/usr/src/xorg-server-1.12.4-1/src/xserver-cygwin-1.12.4-1/test' This is a failure building the unit tests I'd guess you need to ./configure with --disable-unit-tests, or add a patch to link them with libglapi which provides that symbol. In general I would suggest always looking at the .cygport file in the source package to look at the configuration options used there I'm slightly curious to know if there is something wrong with the X server binary package I produce, since you always seem to want to build your own? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.13.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.13.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.13 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! Unfortunately, the upstream announce mail [1] does not contain a full changelog since 1.12, so you will need to consult the changelog or git for a list of upstream fixes and improvements. In addition, the following cygwin-specific changes have been made since 1.12.4-1: * Fix compilation of Xorg DDX on cygwin broken by upstream changes * Update .cygport for automatic setup .hint file generation * Fix compilation with mingw-w64 w32api headers * In multiwindow mode, stop spamming MotionNotify events when the mouse is outside an X window but not moving (Thanks to Colin Harrison for patch) * Fix a potential crash in multiwindow mode when an application (e.g. [2]) doesn't null terminate the WM_CLASS property class name (which is an ICCCM conformance bug in the application) (Thanks to Marc Haesen for patch) 27e61cc5c7b14773891e9878e3103f89 *xorg-server-1.13.0-1.tar.bz2 61dca0cca9334a333fd5a5f804e77f14 *xorg-server-common-1.13.0-1.tar.bz2 3d4e26d9830137d00ad19bac1d28bdcf *xorg-server-debuginfo-1.13.0-1.tar.bz2 7a8c09e48dd9e2d44643086dff372c3c *xorg-server-devel-1.13.0-1.tar.bz2 1a434fe5379d11f66ee871a459e3b394 *xorg-server-dmx-1.13.0-1.tar.bz2 629b3304b675d4ead00f191119781c0f *xorg-server-extra-1.13.0-1.tar.bz2 bd8980ddd1b5b373da24b39c81a6be8c *xorg-server-1.13.0-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-September/002068.html [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6961123 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.4-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.12.4-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.12.3-1: * Support for xfs fontpaths has been disabled, and trying to use them will generate an error. These have been broken upstream since X server 1.9 (see fd.o bug #31501 [2]), and may cause the X server to randomly crash. 00650a136965a3a2eba799c98ff16e40 *xorg-server-1.12.4-1.tar.bz2 4f77f090d66d866887b23213e5a8d64e *xorg-server-common-1.12.4-1.tar.bz2 c73183459ce7097cec2993cff5a5cef6 *xorg-server-debuginfo-1.12.4-1.tar.bz2 a86f0a44f8cebb8108a2058d5c8b9921 *xorg-server-devel-1.12.4-1.tar.bz2 f3462f48bc2ca852c3f3e1ce84c51c22 *xorg-server-dmx-1.12.4-1.tar.bz2 14265bcbb5a71525fff98a30f563d969 *xorg-server-extra-1.12.4-1.tar.bz2 974cf8744c48557103b6c713ed4cd249 *xorg-server-1.12.4-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-August/002062.html [2] https://bugs.freedesktop.org/show_bug.cgi?id=31501 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: Levovo trackpoint events come delayed (reproducable with xev)
You should then be able to see WM_MOUSEWHEEL messages being delivered in the debug output from XWin when you use the trackpoint scrolling. Are they being delivered on time? Description of my testing that produced that log: 1. with xterm - second 304: I press center button and try to scroll with Lenovo trackpoint. I don't release the center button for some seconds. xterm shows no scrolling - second 310: I release the center button. xterm jump scrolls a far distance all at once. 2. same with xev - second 360: I press center button and try to scroll with Lenovo trackpoint (ok, there is nothing to scroll in a xev, but I think you understand what I did). I don't release the center button for some seconds. - second 364: I release the center button. The rest is XWin startup or my kill -9 [XWin] or opening xterms or other irrelevant stuff. Regarding 'WIN_DEBUG_MESSAGES=1: Because I start XWin from a tcsh shell, I added a setenv WIN_DEBUG_MESSAGES 1 before the XWin call. Did that work out, i. e. was that setting active? Yes, these logs contain the required detail. Unfortunately, they don't seem to show that XWin is doing anything wrong. WM_MOUSEWHEEL [1] messages are only being sent to XWin at the point in time you mention the center button being released, but are then correctly converted into X events. e.g. [ 309.303] winWindowProc - WM_MOUSEWHEEL - 0x0780 0x0152030f is converted into a sequence of press/release events for the zaxis up button [ 309.303] winMouseButtonsSendEvent: iEventType: 4, iButton: 4 [ 309.303] winMouseButtonsSendEvent: iEventType: 5, iButton: 4 I have to say this really looks like some kind of issue with the trackpoint software or it's configuration. I also note that the 'configuration' of the trackpoint driver as described in [2] matches on the executable name, so that won't be doing anything useful in this case, as the executable is called 'XWin.20120806-git-25dd890818f3e308 .exe' and not 'XWin.exe' It would be interesting to compare with a similar log when 'ico' is also running, since apparently that makes things behave correctly. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms645617%28v=vs.85%29.aspx [2] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe segmentation fault on Windows 7
On 13/08/12 05:23, Chris LeBlanc wrote: I compiled xorg with debugging from the source packages, and that shows the same behaviour. I can step through the debugger, but the output is the same as what Jon found in the previous email, failing on the call to strcpy(). I've logged the gdb output to a file and can attach it if anyone is interested. Yes, please. Assuming for the moment this is a defect in the cygwin DLL, it would be interesting to see the output of 'mount'. You might also want to install the cygwin-debuginfo package and see if you can debug the problem in getmntent(). It might be worthwhile installing the latest cygwin snapshot [1] to see if the problem still exists. [1] http://cygwin.com/snapshots/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe segmentation fault on Windows 7
On 08/08/2012 05:51, Chris LeBlanc wrote:
I'm trying to help a coworker get Cygwin running on her Windows 7
(64b) machine, but we're seeing a segmentation fault with XWin.exe.
Previous versions of X11 worked fine on this machine, but recently it
has been unable to fork processes. It's been giving the error fork:
child -1 - forked process died unexpectedly ..., which is why I've
been trying to upgrade to the most recent version of Cygwin.
Thanks for the detailed bug report.
Given you were getting fork problems before this upgrade, this might well be a
problem with some other software interfering with cygwin's operation. So you
should take a look at [1], and probably try running XWin with CYGWIN including
detect_bloda [2]
Any advice on how to get more debug info? How hard is it to build
XWin from source? If it's a minor strcpy() issue it could be a pretty
easy fix. Any other advice?
Instructions on building the X server from source are in [3], but with the
debug info package installed you have source and symbols, so you should be
able to set a breakpoint on main and step through the code anyhow.
0 [main] XWin 6164 exception::handle: Exception: STATUS_ACCESS_VIOLATION
454 [main] XWin 6164 open_stackdumpfile: Dumping stack trace to
XWin.exe.stackdump
Program received signal SIGSEGV, Segmentation fault.
strcpy (dst0=0x40010006 Address 0x40010006 out of bounds, src0=0x0)
at /usr/src/debug/cygwin-1.7.16-1/newlib/libc/string/strcpy.c:86
86while (!DETECTNULL(*aligned_src))
(gdb) bt full
#0 strcpy (dst0=0x40010006 Address 0x40010006 out of bounds, src0=0x0)
at /usr/src/debug/cygwin-1.7.16-1/newlib/libc/string/strcpy.c:86
dst = 0x40010006 Address 0x40010006 out of bounds
src = 0x0
aligned_dst = 0x40010006
aligned_src = 0x28a026
#1 0x751d2ad6 in OutputDebugStringA () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
No symbol table info available.
#2 0x40010006 in ?? ()
No symbol table info available.
#3 0x in ?? ()
No symbol table info available.
(gdb)
This stack trace looks highly suspicious:
- The presence of the invalid address 0x40010006 as src for strcpy and in the
backtrace
- I think cygwin is supposed to notice it is being debugged and give control
to the debugger and not write a stackdump file
- I don't think OutputDebugStringA() should ever end up calling cygwin's
strcpy()
So all this suggests to me some kind of stack corruption has happened.
Output from XWin.exe.stackdump:
Exception: STATUS_ACCESS_VIOLATION at eip=61129F8B
eax=0028D624 ebx= ecx= edx= esi=0028D624 edi=0028AB5C
ebp=0028A968 esp=0028A95C program=C:\cygwin\bin\XWin.exe, pid 6164, thread
main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
0028A968 61129F8B (0028D624, , 0028FF14, 771170D5)
0028AA28 6108E2BA (0028AA58, 611DF23B, 60FE8510, 0068)
0028AB78 6108EB57 (60FE000C, 0005, 0028ABC4, 005C2DE9)
0028AB98 61091F56 (005C2DCE, 005C2DCC, , )
0028ABF8 610D5F05 (6C34, 0001, 0028FD24, 0002)
0028AC38 00528F43 (0002, 0028AC60, 800280E8, 8003A441)
0028ACF8 61007535 (, 0028CD78, 61006B20, )
End of stack trace
Processing this with awk '/^[0-9]/{print $2}' XWin.exe.stackdump | addr2line
-asf -e /usr/bin/cygwin1.dll, and cleaning up the output by hand a bit,
gives...
0x61129f8b strcpy strcpy.c:86
0x6108e2ba fillout_mntent mount.cc:1636
0x6108eb57 cygdrive_getmntent mount.cc:1720
0x61091f56 getmntent mount.cc:1900
0x610d5f05 ?? ??:0
0x00528f43 mainmain.c:145
0x61007535 _Z10dll_crt0_1Pvdcrt0.cc:982
... which looks a bit more reasonable, and suggests something in the cygwin
DLL is exploding when XWin uses getmntent() in winCheckMount() to check for
FAT and textmode mounts.
[1] http://cygwin.com/faq/faq.using.html#faq.using.bloda
[2] http://cygwin.com/ml/cygwin/2012-02/msg00797.html
[2] http://x.cygwin.com/docs/cg/
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: XWin on taskbar
On 03/08/2012 15:42, Eliot Moss wrote: The patched run.exe seems to work for me as well. Thanks for testing. I am still uncertain if you are seeing the same, similar or a different problem to me, though, so it would be helpful if you could confirm or deny if the extra taskbar button you see with the unpatched run behaves in the same way as I described. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: AW: 'de' keyboard layout issues
On 03/10/2011 12:27, Paul Maier wrote: In Windows, all blind keys followed by a space result in that character. Same in XWin, but with one exception: dead-´ plus space gives ' instead of ´. Please check out my patch for that. [...] for files /usr/share/x11/locale/iso8859-1/Compose and /usr/share/x11/locale/iso8859-15/Compose. This patch makes sense to me, but doesn't seem to go far enough. Since the compose sequences are selected by the locale, this fixes things if LANG=de_DE.iso8859-1 or LANG=de_DE.iso8859-15, but not if LANG=de_DE.UTF-8. I'll try to take another look when I'm back from my holiday :-) Sorry, I lost track of this issue. agreed, my patch is a partial solution. Is there an issue tracker in use, where we can put my patch and the idea behind it? I would suggest you mail a patch to libX11 to the xorg-devel list [1],[2]. agreed. But isn't a partial fix better than no fix? 8-) I can't really evaluate if this change is correct or not, which is why I suggest you take it to the xorg-devel list. For example, after reading [3], I'm wondering if the reason for this behaviour is that typists had the habit of pressing the acute key for an apostrophe. On the one hand, it's been this way for at least 5 years, so people may be used to this behaviour. On the other hand, it's inconsistent with the rule that dead_foo space produces foo, and inconsistent across locales what this sequence produces: jon@byron /jhbuild/checkout/xorg/lib/libX11/nls master $ grep -r ^dead_acute space * el_GR.UTF-8/Compose.pre:dead_acute space: ΄ U0384 en_US.UTF-8/Compose.pre:dead_acute space: ' apostrophe # APOSTROPHE fi_FI.UTF-8/Compose.pre:dead_acute space: ´ # ACUTE ACCENT iso8859-1/Compose.pre:dead_acute space : ' apostrophe iso8859-14/Compose.pre:dead_acute space : ' apostrophe iso8859-15/Compose.pre:dead_acute space : ' apostrophe iso8859-2/Compose.pre:dead_acute space : \264 acute iso8859-3/Compose.pre:dead_acute space : ' apostrophe iso8859-7/Compose.pre:dead_acute space : \264 acute iso8859-9/Compose.pre:dead_acute space : ' apostrophe iso8859-9e/Compose.pre:dead_acute space : ' apostrophe pt_BR.UTF-8/Compose.pre:dead_acute space: ' apostrophe vi_VN.tcvn/Compose.pre:dead_acute space : ' apostrophe vi_VN.viscii/Compose.pre:dead_acute space : ' apostrophe [1] http://lists.x.org/mailman/listinfo/xorg-devel [2] http://www.x.org/wiki/DeveloperStart [3] http://www.cl.cam.ac.uk/~mgk25/ucs/apostrophe.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: AW: possible to run XWin as windows service?
On 28/07/2012 14:08, Paul Maier wrote: The cygwin program run.exe is designed to do just that. It's what I use for this purpose :-) ... thank you for your input. 8-) I was using run.exe too. run.exe used to hide the window and the task bar entry. But since my upgrade from Cygwin 1.7.9 to 1.7.15, run.exe only hides the window but not the task bar entry, when invoked from the Startup menu in some cases. This seems buggy, see my thread: http://cygwin.com/ml/cygwin/2012-07/msg00473.html But I don't have the impression that a developer accepted this as bug. Do you have a suggestion how to avoid this situation? You might try the patched run from [1] and see if that improves matters. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Levovo trackpoint events come delayed (reproducable with xev)
On 22/07/2012 01:39, Paul Maier wrote: this problem still exists, it makes the Lenovo trackpoint unusable with xterm. Some months ago you provided me XWin.20120129-git-45e67e363e19a481.exe, but it didn't run on my computer. Yesterday I have upgraded my Cygwin, all packages to current (Cygwin 1.7.15). Maybe a debugging .exe would run now on my machine. If you want me to try again, please let me know. Yes, I think there were some unrelated issues which prevented that snapshot from working for you. I've produced an updated snapshot [1], if you could try that in the same way as before, that would be helpful. Download the latest snapshot built with debugging enabled from [1] Run it using 'WIN_DEBUG_MESSAGES=1 ./XWin -logverbose 3 your usual XWin options, -multiwindow for example' Open up an xterm You should then be able to see WM_MOUSEWHEEL messages being delivered in the debug output from XWin when you use the trackpoint scrolling. Are they being delivered on time? Please send me the full XWin.0.log [1] ftp://cygwin.com/pub/cygwinx/XWin.20120806-git-25dd890818f3e308.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin on taskbar
On 01/08/2012 04:10, Eliot Moss wrote:
On 7/31/2012 10:16 PM, Ross Boulet wrote:
I have a desktop running Windows 7 Professional and a laptop running Windows
7 Home Premium. I have updated Cygwin on both to make sure everything is
current. I start X on both the same way using the shortcut installed by
Cygwin. On both machines, I have a .startxwinrc that starts two rxvt
windows. The difference is, on the desktop, items appear in the Windows
taskbar for the two rxvt windows only - as I expect. But on the laptop,
another taskbar item for the XWin server appears.
It's not a huge deal, but it adds a little clutter to the taskbar I would
rather not see. Any thoughts as to why this is happening?
I am not sure the reason is known; a race condition has been
mentioned as a possibility. I solved this by using xlaunch,
and starting that with cygwin's run program.
I strongly suspect this is a problem which only manifests itself on W7, as the
mechanisms which cygwin and run use to keep these console windows invisible
have to be different for W7.
I finally had a bit of time to try to reproduce this on W7, and succeeded in
seeing a problem, but I'm not sure if it's the same one as you are seeing:
If I have a non-empty ~/.startxwinrc, or no ~/.startxwinrc so startxwin starts
a default xterm, then I was seeing an additional taskbar item labelled XWin
Server, but this taskbar item has no associated window, the only option in
the right-click menu is close window. When you close all the X programs
which have been started by startxwin, this taskbar item disappears.
Poking around a bit more, this taskbar item does seem be owned by the conhost
process which is associated with the xterm process started by startxwin.
Of course, if you try to debug this problem, it disappears, so this does look
like some kind of timing problem with the way we hide the console window.
I was able to get things to work properly by applying the attached patch to
run, although it's unclear to me that this is the correct fix or if this just
moves the problem around.
I've uploaded a build of run.exe at [1], perhaps you could try replacing
/usr/bin/run.exe with it and see if it improves things for you?
[1] ftp://cygwin.com/pub/cygwinx/run.exe
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--- run.c.old 2012-08-02 13:11:52.90625 +0100
+++ run.c 2012-08-02 13:12:03.56250 +0100
@@ -499,7 +499,7 @@
{
AllocConsole ();
bHaveConsole = TRUE;
- SetParent ((*GetConsoleWindowFP) (), HWND_MESSAGE);
+ ShowWindowAsync((*GetConsoleWindowFP) (), SW_HIDE);
}
}
else if (!bHaveConsole)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: possible to run XWin as windows service?
On 26/07/2012 23:30, Paul Maier wrote: I would like to start XWin automatically on Windows startup (Windows user login). I couldn't find any hint in the manual. Is it possible to run (and automatically start) XWin as windows service? Possible? Yes. You can't run an arbitrary executable as a service, you need to use the cygwin service wrapper cygrunsrv to make it respond to service control messages. However, this is not the way to achieve what you want to do. Google Allow service to interact with desktop to learn why... Running it from the Startup program group is the correct approach. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.3-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.12.3-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.12.2-2: * Add the possibility to configure dpi and keyboard in XWinrc(Thanks to Yaakov Selkowitz for patches) * Fix a bug which led to the XINERAMA extension being listed twice by XListExtensions(), in multiwindow mode. 539c7d94d90e34d1633ef37c6ddbe769 *xorg-server-1.12.3-1.tar.bz2 09931145264b3202c0d163acc2f7a33a *xorg-server-common-1.12.3-1.tar.bz2 ae3e09b36b4c5bc2a98cbb9ce69d9bf0 *xorg-server-debuginfo-1.12.3-1.tar.bz2 f93619e4312786a766f408c7d1ed7f9b *xorg-server-devel-1.12.3-1.tar.bz2 1f73af8f5aaab34d4feccf404c057005 *xorg-server-dmx-1.12.3-1.tar.bz2 be38e684466cb30b2dac9d3cc5b596f5 *xorg-server-extra-1.12.3-1.tar.bz2 76cded2191de5a024daff04314a064cb *xorg-server-1.12.3-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-July/001999.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.2-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.12.2-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.12.2-1: * Only log all fbConfigs and GL/WGL extensions with verbose logging * Add '-notrapsignals' option to disable running crash analysis tool * Report cygwin version as well as native OS version in log * Do not bogusly report the GLX_INTEL_swap_event extension as supported by indirect swrast (This helps various clutter applications work better) * The xorg-backtrace script will report if debug symbols for the X server aren't installed b36d2ae52f069e05aa1ba42fea99daea *xorg-server-1.12.2-2.tar.bz2 6afb23bcb4ff87d010d753bca37c10d5 *xorg-server-common-1.12.2-2.tar.bz2 3ae971d969e59dda065f5bdf644efb69 *xorg-server-debuginfo-1.12.2-2.tar.bz2 b2b85aacac88035e77df41fd2479cee4 *xorg-server-devel-1.12.2-2.tar.bz2 d3abff8f4b9905aeb1f6656124c5706c *xorg-server-dmx-1.12.2-2.tar.bz2 b0b0c1531f38a6f6f426c3b46976cb7a *xorg-server-extra-1.12.2-2.tar.bz2 d320c86c182df1bf0ecea31a72b13a3e *xorg-server-1.12.2-2-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.1.0 seg faults on startup?
On 27/06/2012 16:33, Nick Vasilatos wrote: You might try creating an empty ~/.startxwinrc (so the default xterm is not started by startxwin) and see if that makes a difference? Would seem not/seems to fail as before. See below and log attached. Okay. thanks for trying anyhow. This is going to be somewhat problematic to debug since the debugger seems unable to attach to the faulted process. I'm not sure what might cause that, if it's some software you have installed which is interfering with Cygwin or some security policy you have set? Are you running XWin under a local Administrator account? I've uploaded a new snapshot at [1], can you try running that, adding the -notrapsignals option to your usual command line. This should generate a XWin.exe.stackdump file when it crashes. Can you attach that to an email, please. [1] ftp://cygwin.com/pub/cygwinx/XWin.20120628-git-59d15f68d4fd9bb8.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?
On 25/06/2012 16:53, David Karr wrote: On Mon, Jun 25, 2012 at 6:22 AM, Jon TURNEY wrote: On 23/06/2012 00:33, David Karr wrote: I run Eclipse on win7, and also Eclipse on Ubuntu, displaying the window on my Win7 box, using Cygwin. One annoyance I have with the latter is that when I select a region of text, it appears to automatically copy that region to the clipboard, instead of waiting for me to press Ctrl-C. I asked about this on the eclipse forums, and they said Ubuntu Eclipse doesn't do this, and it's likely being done by my X server. Yes, the X server is copying the selected text to the Windows clipboard. Let me try to explain why: X supports an arbitrary number of 'selections', the two of interest here are the PRIMARY selection (which conventionally contains some data which the user has selected) and the CLIPBOARD selection (which conventionally contains some data that the user has explicitly requested to be 'copied' to the clipboard) The Cygwin X server monitors these selections for changes, and makes text in the most recently changed one available for pasting from the Windows clipboard. It seems like you've just explained to me by using the word conventionally that the behaviour of the Cygwin X server doesn't behave conventionally. Sorry, no. I am using conventionally here in the sense of for an application which conforms to the X 'Inter-Client Communication Conventions Manual' [1] The Cygwin X server (or rather, it's built-in clipboard client which integrates with the native Windows clipboard) conforms to these conventions. It would be a bug in that client if it was altering the X CLIPBOARD selection when the PRIMARY selection is changed. I don't think that is happening, but you don't have to take my word for the contents of these selections, you can examine them for yourself using 'xsel -p' and 'xsel -b'. The question you are asking (Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?) doesn't distinguish between the Windows clipboard and the X clipboard. I assume that the problem you are reporting is with pasting to a Windows application. To reiterate, the clipboard integration client adopts a simple heuristic to determine which of the PRIMARY or CLIPBOARD X selections to place in the Windows clipboard: it uses the most recently changed one [2] I agree it would be nice if this behaved more in line with user expectations in this specific case. Ideally this would be achieved by improving this heuristic somehow, rather than adding another command line option. So, again, this is acknowledged as something which could be improved, the problem is understood, but someone has to do it. So, if you select some text in eclipse after copying some text to the clipboard, you will get the selected text, not the copied text, when you paste in Windows. I can understand this behaviour is confusing to people who are expecting the X clipboard to behave like the Windows one. It has been suggested a few times that we should not monitor the PRIMARY selection, but some very popular X applications (such as xterm and emacs) only use the PRIMARY selection by default. It's also been suggested that monitoring the PRIMARY selection should be configurable somehow, but I'm not sure that a global configuration option would lead to very useful behaviour. I just verified that I can easily configure Emacs to not copy to the clipboard on selection, and to replace the selection on yank. It's unfortunate that I can't directly configure Eclipse to do this, but I would be surprised if they would have thought to implement this, as Eclipse normally works the way you expect on both Ubuntu and Windows. It's only when displaying the Ubuntu window on Windows through Cygwin that it behaves unconventionally. I'm not sure what you are suggesting here, but changing the default behaviour of the Cygwin X server so it requires everyone who uses it to reconfigure their emacs is not an acceptable solution. [1] http://www.x.org/releases/current/doc/xorg-docs/icccm/icccm.html [2] I slightly simplify here. The XFIXES extension only allows monitoring for changes of selection ownership, only the application owning a selection knows when it changes. This can cause other problems, see https://bugs.freedesktop.org/show_bug.cgi?id=5735 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Is Cygwin X server causing ubuntu eclipse to copy to the clipboard on selection?
On 23/06/2012 00:33, David Karr wrote: I run Eclipse on win7, and also Eclipse on Ubuntu, displaying the window on my Win7 box, using Cygwin. One annoyance I have with the latter is that when I select a region of text, it appears to automatically copy that region to the clipboard, instead of waiting for me to press Ctrl-C. I asked about this on the eclipse forums, and they said Ubuntu Eclipse doesn't do this, and it's likely being done by my X server. Yes, the X server is copying the selected text to the Windows clipboard. Let me try to explain why: X supports an arbitrary number of 'selections', the two of interest here are the PRIMARY selection (which conventionally contains some data which the user has selected) and the CLIPBOARD selection (which conventionally contains some data that the user has explicitly requested to be 'copied' to the clipboard) The Cygwin X server monitors these selections for changes, and makes text in the most recently changed one available for pasting from the Windows clipboard. So, if you select some text in eclipse after copying some text to the clipboard, you will get the selected text, not the copied text, when you paste in Windows. I can understand this behaviour is confusing to people who are expecting the X clipboard to behave like the Windows one. It has been suggested a few times that we should not monitor the PRIMARY selection, but some very popular X applications (such as xterm and emacs) only use the PRIMARY selection by default. It's also been suggested that monitoring the PRIMARY selection should be configurable somehow, but I'm not sure that a global configuration option would lead to very useful behaviour. As always, patches welcome :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.1.0 seg faults on startup?
On 21/06/2012 04:39, Nick Vasilatos wrote: Well... the new server (i1.12.2.0) also seg faults at 0x0 on startup. Debugger says ``No Stack''? The log file is attached. [Inferior 1 (process 17136) exited with code 01] (gdb) bt full No stack. (gdb) This says that the XWin process exited, so either gdb somehow failed to catch it when it segfaulted. Or did it not segfault at all? On 6/17/2012 10:09 AM, Jon TURNEY wrote: On 09/06/2012 17:32, Nick Vasilatos wrote: XWin doesn't want to start for me. This is a new install of Cygwin/new install of Win7 on an AMD x64 system with an Nvidia gtx-570 GPU; I've reinstalled the X components a couple of times; rebasedall a couple of times. The log (I installed an XWin.exe w/symbols) says: [ 5306.810] winPositionWindowMultiWindow: (x, y) = (0, 0) [ 5306.810] immediately return since hWnd is NULL [ 5306.810] winMapWindowMultiWindow - pWin: 80062268 [ 5306.810] winUpdateWindowsWindow [ 5306.810] winReshape () [ 5306.826] Segmentation fault at address 0x0 So, this looks like maybe it's failing while trying to create a window, so this might be a timing condition at startup. You might try creating an empty ~/.startxwinrc (so the default xterm is not started by startxwin) and see if that makes a difference? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: no display specified
On 17/05/2012 21:14, Chillosaurus wrote: some more data ? Is the remote machine a Unix one ? If so the you can look at http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Yes it is a Unix cluster. A2 worked, but Matlab is approx. 60 times slower than normal - or even worse. Can this be solved? If the slowdown is in drawing, it might be due to the fact you are not getting hardware accelerated OpenGL. To get this with the Cygwin X server currently (1) You must be using multiwindow mode, and (2) you must 'export LIBGL_ALWAYS_INDIRECT=1' on the remote machine. See [1]. [1] http://x.cygwin.com/docs/ug/using-aiglx.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.2-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.2-1 *** xorg-server-common-1.12.2-1 *** xorg-server-dmx-1.12.2-1 *** xorg-server-extra-1.12.2-1 *** xorg-server-devel-1.12.2-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.12.1-2: * Fix a merge error with 1.12.1, which made OpenGL non-functional in non-toplevel windows in WGL mode * Ensure styling is properly applied when a window is first shown (Reported by David Thompson) 60480681590ae006018ed53686594115 *xorg-server-1.12.2-1.tar.bz2 8b2e916f7864ad09829adcf557337bdf *xorg-server-common-1.12.2-1.tar.bz2 b9da947f703cfd192caedc5c84c705fd *xorg-server-devel-1.12.2-1.tar.bz2 92ab998241c8652e91e95688b732fa81 *xorg-server-dmx-1.12.2-1.tar.bz2 0935496de1d078503112b68a4d8ee624 *xorg-server-extra-1.12.2-1.tar.bz2 b752cb8fc8e458fa399f881789ae4ec0 *xorg-server-1.12.2-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-May/001963.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xserver crash
On 20/05/2012 20:48, marco atzeri wrote: I just noticed that latest xorg-server-1.12.1-1 is crashing when using octave with fltk interface. Reverting to xorg-server-1.12.0-5 solves the issue $ uname -a CYGWIN_NT-6.1-WOW64 MARCOATZERI 1.7.16s(0.261/5/3) 20120517 02:19:46 i686 Cygwin attached Xwin log. To replicate run octave and at prompt just digit: graphics_toolkit(fltk) x=1:10 plot(x,x) Thanks for reporting this. This (and the other OpenGL related crashes reported) should be fixed since 1.12.1-2, and with another OpenGL regression fixed in 1.12.2-1 today, this should be back to working as well as it ever did :-) -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar buttons for remote xterms do not appear
On 05/06/2012 05:35, David Thompson wrote: I upgraded Cygwin/X to XWin 1.12.1-1 built 2012-05-02 and now I'm seeing an annoying problem when starting remote xterm windows: the taskbar button for the xterm window does not appear until I give it focus. Thanks for the detailed bug report. FWIW, I've searched the mailing lists and found this: [ANNOUNCEMENT] Updated: xorg-server-1.12.0-2 * The _NET_WM_STATE_SKIP_TASKBAR hint is now implemented in multiwindow mode Since I'm using multi-window mode and since these are network based xterms coming into XWin.exe, and the taskbar button is not automatically showing with the xterm window, could this be my problem? Indeed, it seems that this change introduced a timing window where the skip-taskbar state of a window might not be applied correctly when the window was first shown, and I guess remote xterms fall into this window. I've uploaded 1.12.2-1 which hopefully contains a fix which closes this timing window. When it reaches the mirrors, perhaps you could try it and see if it fixes things for you? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fwd: XServer crashes on startup: Caught signal 11 (Segmentation fault). Server aborting.
On 13/06/2012 01:16, Aaron Beaulieu wrote: On a fresh install of cygwin/X on a Windows 7 machine, attempting to start xwin -multiwindow (Package: version 1.12.1-1 built 2012-05-02) or startxwin.exe results in an immediate crash. I could not fins a solution online and just cannot figure out what is happening. The output log reports many no symbol table info available notes, ie: No symbol table info available. #1 0x776df896 in ntdll!RtlQueryTimeZoneInformation () from /cygdrive/c/Windows/SysWOW64/ntdll.dll No symbol table info available. #24 0x042c5317 in atioglxx!DrvGetProcAddress () from /cygdrive/c/Windows/system32/atioglxx.dll It ends with: Segmentation fault at address 0x13c Fatal server error: Caught signal 11 (Segmentation fault). Server aborting Server terminated with error (1). Closing log file. Segmentation fault at address 0x13c Fatal server error: Caught signal 11 (Segmentation fault). Server aborting winDeinitMultiWindowWM - Noting shutdown in progress winMsgWindowProc - pthread_mutex_unlock () failed: 1 Please help. Thanks for reporting this problem. If this crash still occurs with the latest Cygwin X server version, please can you follow the instructions at [1] to install debug symbols and use gdb to get a backtrace for the X server when it crashes. [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.1.0 seg faults on startup?
On 09/06/2012 17:32, Nick Vasilatos wrote: XWin doesn't want to start for me. This is a new install of Cygwin/new install of Win7 on an AMD x64 system with an Nvidia gtx-570 GPU; I've reinstalled the X components a couple of times; rebasedall a couple of times. The log (I installed an XWin.exe w/symbols) says: [ 5306.810] winPositionWindowMultiWindow: (x, y) = (0, 0) [ 5306.810] immediately return since hWnd is NULL [ 5306.810] winMapWindowMultiWindow - pWin: 80062268 [ 5306.810] winUpdateWindowsWindow [ 5306.810] winReshape () [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Segmentation fault at address 0x0 [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Fatal server error: [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] Caught signal 11 (Segmentation fault). Server aborting [ 5306.826] [ 5306.826] [ 5306.826] [ 5306.826] Server terminated with error (1). Closing log file. Any ideas/what am I doing wrong? Thanks for reporting this problem. If this crash still occurs with the latest Cygwin X server version, please can you follow the instructions at [1] to install debug symbols and use gdb to get a backtrace for the X server when it crashes. [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XKeysymDB missing ?
On 15/06/2012 02:46, Scott Merrilees wrote: package libX11_6/libX11_6-1.3.3-1 /usr/share/X11/XKeysymDB present package libX11_6/libX11_6-1.4.4-1 /usr/share/X11/XKeysymDB missing The XKeysymDB file has been removed upstream since libX11 1.3.6, see [1] The data which would have been read from it is now built into libX11. The FAQ has some references to XKeysymDB which are confusing given it's omission from 1.4.4-1, and had me wondering is the Xterm input issues I was seeing were related to the lack of this file. If XKeysymDB is missing by design, then probably the FAQ should note this where it talks about XKeysymDB Yes, the FAQ probably needs some updating. It's still possible to set the XKEYSYMDB environment variable, although this is probably of extremely limited usefulness. [1] http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=50b4b07073bd46cbef3627c160a240bd2a2b99d5 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.1-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.1-2 *** xorg-server-common-1.12.1-2 *** xorg-server-dmx-1.12.1-2 *** xorg-server-extra-1.12.1-2 *** xorg-server-devel-1.12.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.12.1-1: * Fix an X server crash caused by running any OpenGL program (in the default, WGL mode) * Increase the timeout in the xorg-backtrace script for gdb to generate backtrace information from 5 to 60 seconds ca47eba223d8c5b44b57787fb38762aa *xorg-server-1.12.1-2.tar.bz2 8cdc421e0dab10e4df2f32bbf72aba9c *xorg-server-common-1.12.1-2.tar.bz2 7760010315604d9e7984b969ad31743d *xorg-server-devel-1.12.1-2.tar.bz2 c2d4178cc80a27e13887a1894f132931 *xorg-server-dmx-1.12.1-2.tar.bz2 781775ee3aec91d3cd763a4e547361f3 *xorg-server-extra-1.12.1-2.tar.bz2 974815d3437c885e5bc9ed9e62760401 *xorg-server-1.12.1-2-src.tar.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.1-1
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.1-1 *** xorg-server-common-1.12.1-1 *** xorg-server-dmx-1.12.1-1 *** xorg-server-extra-1.12.1-1 *** xorg-server-devel-1.12.1-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], the following cygwin-specific changes have been made since 1.12.0-5: * Enable upstream code to run an external crash analysis or reporting tool and capture output to log * Include a simple crash analysis script, xorg-backtrace, which tries to use gdb, if installed, to generate a backtrace bf45c84bdd7f13cdec799f736d73e820 *xorg-server-1.12.1-1.tar.bz2 f8e6fdaed297cb06314cf93325e28553 *xorg-server-common-1.12.1-1.tar.bz2 a89c7436446e71baec31ca4742b22875 *xorg-server-devel-1.12.1-1.tar.bz2 261edbc4a573e83b1bdd9118183f3242 *xorg-server-dmx-1.12.1-1.tar.bz2 58ba1f07d107b99064df689660276feb *xorg-server-extra-1.12.1-1.tar.bz2 c1996be768ccb8d5ab3381ada8199b72 *xorg-server-1.12.1-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-April/001930.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fatal Error (Segmentation Fault) only while viewing the LVM GUI
On 25/04/2012 19:25, Carlo.DiCocco wrote: I think I may have found a bug. I am connecting to a remote Linux server from my Windows desktop and attempting to use some of the GUI tools on the remote server. The xclock GUI displays fine. The Oracle dbca GUI displays fine. The LVM system-config-lvm GUI displays and works fine, but cygwin generates a fatal error window due to a segmentation fault. The following command displays the GUI, but reports a fatal error: [root@aorahdev ~]# system-config-lvm [ 64144.546] Segmentation fault at address 0x44 [ 64144.546] Fatal server error: [ 64144.546] Caught signal 11 (Segmentation fault). Server aborting [ 64144.546] Server terminated with error (1). Closing log file. Thanks for reporting this problem. I was not able to reproduce this crash using system-config-lvm 1.1.16, on Fedora 15. Perhaps you can provide details on the remote server and system-config-lvm version you are using? It would be very helpful if you could follow the instructions at [1] to use gdb to get a backtrace for the X server when it crashes. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.0-4 crash
On 23/04/2012 14:03, Michel Bardiaux wrote: Yes, it is a crash at startup. I could not find XWin.exe.stackdump anywhere on my hard drive. I have attached the bat script (renamed into .txt) used to start cygwin/X, maybe I need to modify it. Would it work to add CYGWIN='error_start=c:\cygwin\bin\dumper.exe' in the system environment (meaning, via the control panel), to have a core file that I could then open with gdb? No, I don't think that would work (for various uninteresting reasons) Start the X server from a terminal using 'gdb --args XWin -multiwindow', type 'r' to start the X server running, and 'bt full' after it crashes. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fatal Error (Segmentation Fault) only while viewing the LVM GUI
On 26/04/2012 14:18, Jon TURNEY wrote: On 25/04/2012 19:25, Carlo.DiCocco wrote: I think I may have found a bug. I am connecting to a remote Linux server from my Windows desktop and attempting to use some of the GUI tools on the remote server. The xclock GUI displays fine. The Oracle dbca GUI displays fine. The LVM system-config-lvm GUI displays and works fine, but cygwin generates a fatal error window due to a segmentation fault. The following command displays the GUI, but reports a fatal error: [root@aorahdev ~]# system-config-lvm [ 64144.546] Segmentation fault at address 0x44 [ 64144.546] Fatal server error: [ 64144.546] Caught signal 11 (Segmentation fault). Server aborting [ 64144.546] Server terminated with error (1). Closing log file. Thanks for reporting this problem. I was not able to reproduce this crash using system-config-lvm 1.1.16, on Fedora 15. Perhaps you can provide details on the remote server and system-config-lvm version you are using? It would be very helpful if you could follow the instructions at [1] to use gdb to get a backtrace for the X server when it crashes. Oops [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X segmentation fault when particular application attempts to open a window
On 25/04/2012 22:45, Keith Lindsay wrote: On 4/25/2012 2:20 PM, Keith Lindsay wrote: I'm running a data analysis program called ferret on a remote machine that I've logged on to with ssh -X. When the program attempts to create a window, the Cygwin/X server crashes with a segmentation fault. The seg fault is reproducible. xclock works fine from the same remote machine. This is with version 1.12.0-4 of xorg-server. ferret has worked with some previous versions of the Cygwin/X server, but I'm not certain about the precise version where the breakage occurred. I backed up one version and encountered the same problem. I've attached the output of cygcheck -c, the file /var/log/xwin/XWin.0.log, and the output of a gdb that is attached to the XWin process when it crashes. I realized that I can back up to other versions of xorg-server by installing from the local directory that contains previous version downloads. I have discovered that ferret works fine with version 1.12.0-1 of xorg-server (built 2012-03-12) and generates the segmentation violation with version 1.12.0-2 (built 2012-04-04). Thanks for the excellent bug report. I've uploaded 1.12.0-5 which hopefully contains a fix for this crash. This crash was caused by the server being unable to find the bitmap which the application wants to use for it's icon, it's not clear why this is happening, so I would be interested to know if the application icon is correct or not. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.0-4 crash
On 23/04/2012 12:55, Michel Bardiaux wrote: Nothing much to add to the 2 attached files - except that my X worked fine until the last update. Will try reverting to previous version. Mentioning the name of the application which caused the crash (multi-gnome-terminal) would have helped. On 23/04/2012 14:03, Michel Bardiaux wrote: Yes, it is a crash at startup. So, in fact, it's not a crash when the X server is started, but when you try to run the application multi-gnome-terminal? On 26/04/2012 15:54, Michel Bardiaux wrote: Start the X server from a terminal using 'gdb --args XWin -multiwindow', type 'r' to start the X server running, Did exactly that in a minty. Then in another one: export DISPLAY=localhost:0.0 ssh -X -Y michel@besdev01 multi-gnome-terminal It looks like this is the same crash as reported at [1], and should be fixed in X server 1.12.0-5. [1] http://cygwin.com/ml/cygwin-xfree/2012-04/msg00097.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Fatal Error (Segmentation Fault) only while viewing the LVM GUI
On 26/04/2012 14:23, Jon TURNEY wrote: On 26/04/2012 14:18, Jon TURNEY wrote: On 25/04/2012 19:25, Carlo.DiCocco wrote: I think I may have found a bug. I am connecting to a remote Linux server from my Windows desktop and attempting to use some of the GUI tools on the remote server. The xclock GUI displays fine. The Oracle dbca GUI displays fine. The LVM system-config-lvm GUI displays and works fine, but cygwin generates a fatal error window due to a segmentation fault. The following command displays the GUI, but reports a fatal error: [root@aorahdev ~]# system-config-lvm [ 64144.546] Segmentation fault at address 0x44 [ 64144.546] Fatal server error: [ 64144.546] Caught signal 11 (Segmentation fault). Server aborting [ 64144.546] Server terminated with error (1). Closing log file. Thanks for reporting this problem. I was not able to reproduce this crash using system-config-lvm 1.1.16, on Fedora 15. Perhaps you can provide details on the remote server and system-config-lvm version you are using? It would be very helpful if you could follow the instructions at [1] to use gdb to get a backtrace for the X server when it crashes. Oops [1] http://x.cygwin.com/devel/backtrace.html It seems quite likely this is the same crash as reported at [1], so it's probably worth testing X server 1.12.0-5 to see if it's fixed there, first. [1] http://cygwin.com/ml/cygwin-xfree/2012-04/msg00097.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.0-5
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-5 *** xorg-server-common-1.12.0-5 *** xorg-server-dmx-1.12.0-5 *** xorg-server-extra-1.12.0-5 *** xorg-server-devel-1.12.0-5 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.12.0-4: * Fix a crash which could occur in WM_HINTS bitmap icon conversion (Reported by Keith Lindsay, Yusuke Tamura and others) * stdout and stderr for processes started from the notification area icon are now written to the X server log * Remove the llvmpipe/softpipe testing facility using the GALLIUM_DRIVER environment variable 696546cad78a343467ddf4dafbdb8ebb *xorg-server-1.12.0-5.tar.bz2 a4e2688aac776d4857b585af1c30e3bd *xorg-server-common-1.12.0-5.tar.bz2 96e6cd66404a1a3f0f12fe7a5663ae48 *xorg-server-devel-1.12.0-5.tar.bz2 aa008cd283e392eb50f5a33d706fb249 *xorg-server-dmx-1.12.0-5.tar.bz2 b54a699855c844dd536e848195c50a61 *xorg-server-extra-1.12.0-5.tar.bz2 2ffceecd814981724ce6ec6470ea9da9 *xorg-server-1.12.0-5-src.tar.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: dbus-launch --exit-with-session fails when run from .startxwinrc
On 24/04/2012 14:50, Ken Brown wrote: On 4/16/2012 9:50 AM, Ken Brown wrote: On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove --exit-with-session from the command line in my .startxwinrc, then a dbus-daemon process does start. I tried modifying the X server shortcut to read C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' as suggested in a different thread, but that provides no information. The resulting startxwin.log is virtually identical (with minor differences) to XWin.0.log. In particular, there's no indication of what's happening when .startxwinrc is processed. There's no output because ~/.startxwinrc generates no output. For starters, it would really be helpful if someone could try to reproduce my problem on a 64-bit Windows 7 system. At the moment, I don't even know if there is a bug somewhere or simply a problem with my own system. Here's the recipe: 1. Create a .startxwinrc file with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm 2. Start the X server using the Start Menu shortcut. 3. In the resulting xterm window, give the ps command. If things are working right, the output from ps should show a dbus-launch process and a dbus-daemon process. These processes do appear on my XP system but not on my Windows 7 system. FWIW, it works on XP for me as well. I tried with the following ~/.startxwinrc: eval `dbus-launch --sh-syntax --exit-with-session | tee /dev/stderr` xterm ... which at least lets you see the pid of the dbus-daemon that is started. I'm not sure if --exit-with-session is correct with startxwin, since the startxwin process will not linger after it has started ~/.startxwinrc, and I don't know if stdin will remain open after it (and the process tree above it waiting for it) exits. I have this vague recollection that 'run' has to do different things on XP and W7, which might account for the different behaviour? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Issue with XWin under xlaunch
On 23/04/2012 17:41, Eliot Moss wrote: Ok -- by perusing the log I figured it out ... [727848.279] executing 'xterm -display :0.0 -ls -title swarm -bg rgbi:.0/.20/.0 -geometry 120x47+0+0 -e /usr/bin/ssh m...@swarm.cs.umass.edu', pid 13748 [727848.311] (pid 13748 stderr) /bin/sh: xterm: command not found In the past, .XWinrc names of files such as xterm worked just fine. Apparently something changed about the PATH used, and xterm was not being found. When I write /usr/bin/xterm, it starts up. You can see the first case and the second in the attached log file. So, I think xlaunch is ok, but this was a surprising difference :-) ... This is not intentional. I can't reproduce this, so I'm not quite sure what is causing this. What I am expecting to happen is that xlaunch is invoked via the start menu shortcut which it's package creates, which runs bash -l -c xlaunch, which reads /etc/profile, which sets PATH to include /usr/bin, which should be inherited by XWin and used when it execs /bin/sh -c 'your xterm command'. We try to create the login environment as far up the process hierarchy as possible, rather than starting the processes from the notification area menu with bash -l -c, as creating the login environment can be expensive. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Issue with XWin under xlaunch
On 23/04/2012 16:04, Ken Brown wrote: I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Would it be possible for you to also add some code for diagnosing problems with processes started from .startxwinrc? I'm hoping it might help with the problem I reported in http://cygwin.com/ml/cygwin-xfree/2012-04/msg00050.html Hmm.. not sure code is really needed. You can see the output from startxwin by running it from a terminal, or capture it by changing the shortcut which runs it to something like the following (perhaps we should do that by default) C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin 1.12.0-4 crash
On 23/04/2012 12:55, Michel Bardiaux wrote: Nothing much to add to the 2 attached files - except that my X worked fine until the last update. Will try reverting to previous version. From the log timestamps, this looks like a crash at startup. Is that correct? Thanks very much for reporting this problem. There should be an XWin.exe.stackdump file produced by the crash, if you could attach that, that would be helpful. Even more helpful would be following the instructions at [1] to use gdb to get a backtrace for the X server when it crashes. If your crash is at startup, you will need to modify the instruction slightly, start X using 'gdb --args XWin -multiwindow' rather than trying to attach to a running XWin. [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [PATCH] Fix command line arguments for multiple monitors
On 18/04/2012 19:48, Jörg Mensmann wrote: I've now completed some additional tests, and it seems that the return value of EnumDisplayMonitors() really depends on the return value of its callback on my system. Here is the minimal test case: Thanks for the test case. Yes, you are quite correct. I wasn't testing what I thought I was testing, so, in fact, I do see the same behaviour as you. Mystery solved :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Issue with XWin under xlaunch
On 11/04/2012 11:23, Eliot Moss wrote: When I start XWin using xlaunch, trying to the start programs from the .XWinrc popup menu (right-click on the X icon, left-click on the program's entry in the menu), programs do not start. I get only those programs started by my script that I told xlaunch to run. I would like to use xlaunch, since it solves the issue I had with the startxwin taskbar icon being visible (when I claim it should not be, and it didn't use to be), but not being able to start additional programs makes this approach less useable. Looking at this from outside, it is hard to say whether the real issue is in xlaunch, in XWin, or the result of some misunderstanding between them. At the moment, the output from processes started from the notification area icon doesn't go anywhere useful, which can make it hard to debug problems with processes started this way. I've added some code to capture stdout and stderr from these subprocesses to the X server log, and to more clearly diagnose problems which could occur while fork/exec-ing them. Perhaps you could try the snapshot at [1] and see if this gives a bit more information about why these processes are failing? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120423-git-638383315ef51e46.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: ssh -X : connect /tmp/.X11-unix/X0: No such file or directory
On 20/04/2012 11:43, Ronald Fischer wrote: My setup so far (which is working well), was to use Xming as X-Server and putty for logging into our Solaris hosts via ssh. Since I have Cygwin installed, I thought I could use its ssh equally well, so I exported the ssh key from putty to the format understood by ssh, and used the following bash command to login to the Solaris host: DISPLAY=:0.0 TERM=xterm ssh -p 22 -K -X -i MyPrivateKeyFile MyUserName@SolarisHost When I now try to start an X application, I get an error message like this connect /tmp/.X11-unix/X0: No such file or directory XIO: fatal IO error 131 (Connection reset by peer) on X server SolarisHost:239.0 after 0 requests (0 known processed) with 0 events remaining. I think I know what's going on here. cygwin ssh understands DISPLAY=:0.0 to mean to connect to the X server for display 0 via a local (UNIX domain) socket, named /tmp/.X11-unix/X0 The Xming X server, not being a cygwin application, cannot listen on that socket. The solution should be to use DISPLAY=localhost:0.0 instead, which means to connect to the X server for display 0 via TCP/IP, which the Xming X server should be listening on. See FAQ 1.6 [1] for more details. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#display-and-screen -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [PATCH] Fix command line arguments for multiple monitors
On 14/04/2012 16:28, Jörg Mensmann wrote: placing the X server on a specific monitor using something like -screen 0 @2 is broken since November. The attached patch restores the old behaviour. Thanks very much for investigating this issue and for the patch. I'll include this in the next X server build. This happened since commit 3ead1d810b0e157078db39712e02ea6dc85216d8, because EnumDisplayMonitor() returns FALSE if its callback function returns FALSE (which is not clearly documented), and QueryMonitor() would then also return FALSE. I don't observe this behaviour on my test machine, EnumDisplayMonitor() returns TRUE, so I'd be interested to know what version of Windows you are using. I am a little concerned that I can't find any evidence using google of anyone else reporting having the MonitorEnumProc callback function return FALSE to terminate the enumeration causes EnumDisplayMonitor() to return 0, indicating failure, so maybe there is something else going on here... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Workaround Possible Cause - Failed to activate core device - Could not invoke xkbcomp on Failed X Server Launch
On 13/04/2012 03:30, Charles Sheridan wrote: This week, after upgrading my Cygwin installation for the first time since ~April of 2011, X server startup failed, with the below oft-reported entries at the end of /cywin/var/log/xwin/Xwin.0.log -- ... [ 10092.016] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [ 10092.235] (EE) Couldn't open compiled keymap file /var/lib/xkb/server-0.xkm [ 10092.235] (EE) XKB: Failed to load keymap. Loading default keymap instead. [ 10092.313] (EE) Couldn't open compiled keymap file /var/lib/xkb/server-0.xkm [ 10092.313] XKB: Failed to compile keymap [ 10092.313] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [ 10092.313] Fatal server error: [ 10092.313] Failed to activate core devices. [ 10092.313] Server terminated with error (1). Closing log file. This occurs on startup attempts from Xwin, startx, startxwin. I have not previously seen X server startup failure, over 10 years of Cygwin-X use on several different mswin machines. X server startup failure persists after Cygwin re-installation following an HP Vista Enterprise laptop reboot, without any Cygwin processes running, and despite post-install run of several recommended variations on `rebaseall` -- `rebaseall -b 0x7700` under both ash dash, and without the -b arg. = WORKAROUND: The new Xlaunch in the All Programs/Cygwin-X dir off the Windows Start Button starts X without issue. = POSSIBLE CAUSE: The same Xwin.0.log errors are reported in several X windows fora for platforms other than Cygwin. The first link below is a long entry in a Debian forum concluding that the issue relates to a problematic memory module, that can be bypassed via the nopat option to XWin. I couldn't get the Cygwin XWin cmd to recognize this option. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646987 Read more carefully. nopat is a linux kernel option, which is being used there to work-around a kernel bug. So all that bug tells you is when running the xkbcomp program at xserver startup fails, you get these error messages. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: FW: RE: Cut and Paste between X and WindowsXP sometimes fails
On 09/04/2012 16:53, Bennett, Tony wrote: The fix continues to work well... ...will this fix be integrated into X soon...??? Thanks for testing. Unfortunately, this fix seems to break other clipboard uses (In my testing, copying from a native Firefox to cygwin X emacs didn't work anymore), so I need to find the time to look at it some more before I can include it. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series (more)
On 11/04/2012 11:39, Eliot Moss wrote: When playing around with xlaunch configurations and such, I ran startxwin several times this morning. ONCE, X came up without the iconized StartXWin window (i.e., things displayed as they used to before I upgraded xorg-server). This makes me suspect that there may be some kind of timing-related behavior. Perhaps the relevant code did not change between releases, but other changes affected relative timing of various actions, exposing a latent bug or race condition. I'm still not entirely sure what process in running in this window you complain of. Can you be say what the title and contents of this window are? I'm also not sure if this problem is related to he X server at all. Can you try creating a shortcut which runs the following command, for example, and see if the bash window is always successfully hidden? C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c sleep 10 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.0-4
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-4 *** xorg-server-common-1.12.0-4 *** xorg-server-dmx-1.12.0-4 *** xorg-server-extra-1.12.0-4 *** xorg-server-devel-1.12.0-4 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.12.0-3: * Fix a problem which could prevent multiple monitor support from working on some systems (Thanks to Jörg Mensmann for patch) * If a window has had its taskbar button removed (e.g. by the _NET_WM_STATE_SKIP_TASKBAR hint), disable its minimize button to prevent it becoming lost (Thanks to Colin Harrison for patch) 134fcc78f06512dac97ba3ff8b601b52 *xorg-server-1.12.0-4.tar.bz2 6639dda222775a2046246cfa5c6f1aaf *xorg-server-common-1.12.0-4.tar.bz2 71aff2a88b9860269da2899910a69740 *xorg-server-devel-1.12.0-4.tar.bz2 677e7b631aca77cf1ce14d5de571679e *xorg-server-dmx-1.12.0-4.tar.bz2 224d9f4af8d68d556f91853e8e6cfcc5 *xorg-server-extra-1.12.0-4.tar.bz2 6fcb163089f7b78530ee1e145725ffc5 *xorg-server-1.12.0-4-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 07/04/2012 05:00, Eliot Moss wrote:
On 4/6/2012 1:01 PM, Jon TURNEY wrote:
On 05/04/2012 16:54, Eliot Moss wrote:
Something seems to have changed between the last 1.11 release and
the 1.12.0 (up through the 1.12.0-2 release made yesterday).
The window for StartXWin, which is minimized, did not previously
result in an X icon in the taskbar, but now does, and it is
distinct from the stack of X icons for my several launched
xterms. I feel it is clutter and want to suppress it, but I
don't know how at this point.
I guess the window you are seeing is the terminal window in which bash is
being run? It's the job of the run command to hide that window, and why it
should suddenly stop doing so when the XWin at the bottom of the process tree
changes, I have no idea.
Yes, which is why I, too, was surprised.
This might perhaps be related to a bug in cygwin 1.7.12 where cygwin
executables were wrongly handled as native, non-cygwin executables?
I just installed 1.7.13, and the behavior is still there.
It goes away when something completes, which happens when
all the windows started by .startxwinrc are gone. If I kill
it, then all those initial windows die. Perhaps this is all
normal, *except* that the run window is displayed.
All I can really say is that it works for me. If run isn't doing it's job for
you, I don't know why.
You might like to take a look at using the xlaunch package to start your
Xserver and see if that behaves any better.
These various commands / files all seem to be seen and used. And by the
way,
the xemacs1 MINIMIZE does not seem to work -- it always starts maximized
and I
have to minimize it manually. Hints on that?
Using -name to set the xemacs resource name does not set the window class
name, apparently by design [1], so this style directive will not match the
window title or window class name of your xemacs window.
Fortunately, you could probably achieve the same effect by adding the
'-iconic' command line option to the xemacs invocation.
Actually, -iconic does not work; neither does it work to set the iconic
resource to true. Seems to be an xemacs thing. In fact, here is a quote
from the FAQ:
Ugh, this stuff is such an incredible mess that I've about given up getting
it to work. The principal problem is numerous window-manager bugs...
:-)
However, I find that the .XWinrc MINIMIZE style *does* work ... but of course
only for windows I create later. And the class name is emacs, not xemacs,
hence a STYLE entry of: emacs MINIMIZE ...
Does this suggest to you any other way that might work to get an iconified
xemacs from the .startxwinrc file?
We seem to be talking past each other here. The .XWinrc you attached does not
specify a style for the 'emacs' class.
STYLES {
console MINIMIZE
Eliot MINIMIZE
xemacs1 MINIMIZE
}
Adding 'emacs MINIMIZE' seems to work for me (although it does appear that the
window is created normal and then minimized, which a bit ugly, but that's a
consequence of the order we do things at window creation time)
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.0-3 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-3 *** xorg-server-common-1.12.0-3 *** xorg-server-dmx-1.12.0-3 *** xorg-server-extra-1.12.0-3 *** xorg-server-devel-1.12.0-3 These packages contain XWin and the other X.Org X11 servers. This package is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. The following cygwin-specific changes have been made since 1.12.0-2: * Fix WM_HINTS bitmap icon conversion (Reported by Eliot Moss) * Fix a crash in icon regeneration on XWinrc reload (Reported by Eliot Moss) ac3e4e1d7b759b638330b2cebddc58d6 *xorg-server-1.12.0-3.tar.bz2 50ca03394b4740410359052307e7f3e0 *xorg-server-common-1.12.0-3.tar.bz2 3a5b860bbeea10cb753190f073ebb378 *xorg-server-devel-1.12.0-3.tar.bz2 36b39a094485836eef8de5b99b53a2d8 *xorg-server-dmx-1.12.0-3.tar.bz2 f41c5ad483013ac22f44652ed20d0197 *xorg-server-extra-1.12.0-3.tar.bz2 79f8452f1cb5b4983c6d49b058e8d243 *xorg-server-1.12.0-3-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 07/04/2012 17:45, Eliot Moss wrote: Does this suggest to you any other way that might work to get an iconified xemacs from the .startxwinrc file? We seem to be talking past each other here. The .XWinrc you attached does not specify a style for the 'emacs' class. Yes; I changed it, and was reporting on the changed .XWinrc. Adding 'emacs MINIMIZE' seems to work for me (although it does appear that the window is created normal and then minimized, which a bit ugly, but that's a consequence of the order we do things at window creation time) Right, but this affects only windows launched manually from the XWin menu, not ones launched from .startxwinrc. I'm not sure if you are labouring under a misapprehension due to poor documentation, or reporting a bug here. The STYLE directive adjusts the window styling of all windows which match the specified class or window name, it shouldn't matter how the application which created that window was started, be it from the XWin menu, from ~/.startxwinrc or from a terminal. If it does matter how the application was started, then that is a bug. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Taskbar appearance changes between xorg-server 11 series and 12.0 series
On 05/04/2012 16:54, Eliot Moss wrote:
Something seems to have changed between the last 1.11 release and
the 1.12.0 (up through the 1.12.0-2 release made yesterday).
Thanks for testing!
The window for StartXWin, which is minimized, did not previously
result in an X icon in the taskbar, but now does, and it is
distinct from the stack of X icons for my several launched
xterms. I feel it is clutter and want to suppress it, but I
don't know how at this point.
I guess the window you are seeing is the terminal window in which bash is
being run? It's the job of the run command to hide that window, and why it
should suddenly stop doing so when the XWin at the bottom of the process tree
changes, I have no idea.
This might perhaps be related to a bug in cygwin 1.7.12 where cygwin
executables were wrongly handled as native, non-cygwin executables?
Separately, going from 1.12.0-1 to 1.12.0-2 changed my xemacs
icon, to one that is nearly transparent (there's something
there, but very hard to discern). In the past xemacs gave
its own icon (which I could never find or override).
Thanks for pointing this out. I'd introduced a couple of bugs into the
fallback icon conversion code for a bitmap pointed to by WM_HINTS (which is
only used when a NET_WM_ICON property isn't present)
I've applied a couple of fixes, so hopefully this works better now. I've
uploaded a snapshot at [2]. Perhaps you could try that out and see if that
improves things for you?
I suspect that the 'XE' icon from
/usr/share/xemacs-21.4.22/etc/xemacs-icon.xpm is baked into the Xemacs
executable. If Xemacs itself doesn't provide a way to change it, you could
override it for multiwindow mode by using the ICONS directive in XWinrc.
xemacs -T xemacs-n xemacs-name xemacs1
STYLES {
console MINIMIZE
Eliot MINIMIZE
xemacs1 MINIMIZE
}
These various commands / files all seem to be seen and used. And by the way,
the xemacs1 MINIMIZE does not seem to work -- it always starts maximized and I
have to minimize it manually. Hints on that?
Using -name to set the xemacs resource name does not set the window class
name, apparently by design [1], so this style directive will not match the
window title or window class name of your xemacs window.
Fortunately, you could probably achieve the same effect by adding the
'-iconic' command line option to the xemacs invocation.
On 05/04/2012 17:11, Eliot Moss wrote:
On xorg-server 1.12.0-2, doing
a reload of .XWinrc via the .XWinrc menu cases an
exception that kills the X server. I does put up
an error window saying what happened (a
segmentation fault).
This was also related to the icon conversion changes and should be fixed in
the latest snapshot.
[1] http://www.nada.kth.se/cgi-bin/info?%28xemacs-faq.info%29Q3.1.7
[2] ftp://cygwin.com/pub/cygwinx/XWin.20120406-git-b309f093d6e90201.exe.bz2
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.0-2 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-2 *** xorg-server-common-1.12.0-2 *** xorg-server-dmx-1.12.0-2 *** xorg-server-extra-1.12.0-2 *** xorg-server-devel-1.12.0-2 These packages contain XWin and the other X.Org X11 servers. Upstream is considering the removal of the Xephyr, Xfake, Xnest and Xvfb servers sometime after X11R7.7, to be replaced by invoking the Xorg server with the xf86-video-dummy or xf86-video-nested drivers [1]. To prepare for this transition, some packaging changes have been made: PACKAGING CHANGES: 1) The Xephyr, Xfake, Xnest and Xvfb servers have been moved to a separate xorg-server-extra package. 2) A new xorg-server-common package contains X server common files. This allows xorg-server-extra to be installed (e.g. for Xvfb) without installing xorg-server. 3) The xorg-server package now also contains the Xorg server, which can be used with the xf86-video-dummy and xf86-video-nested drivers to provide dummy and nested X servers. 4) The new xorg-server-devel package contains the SDK for building drivers and extensions for the Xorg server. Given setup limitations, some of the dependencies between these packages may not be correct until they are promoted from test to current. Also, I've made an effort to finish off a lot of my half-completed patches, so this package contains numerous changes to cygwin-specific code. This package is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. The following cygwin-specific changes have been made since 1.12.0-1: * In multiwindow mode, the native window icon now updates if the X window _NEW_WM_ICON icon hint changes * In multiwindow mode, the native window styling now updates if the X window styling hints change * The _NET_WM_STATE_SKIP_TASKBAR hint is now implemented in multiwindow mode * A crash caused by a race condition in the conversion of the window icon from an X property to a Windows icon has been fixed (Reported by Ken Brown) * In multiwindow mode, the native window now flashes on the taskbar if the X window's urgency hint is set * A bug which could cause the X server to use 100% of a core while waiting for the X clipboard contents to be converted has been fixed [2] * Fake XINERAMA data is now generated describing the native monitors when multiplemonitor mode is enabled, allowing XINERAMA-aware X applications to correctly place their windows so they don't get split between monitors. * A couple of timing-sensitive failures in clipboard handling have been fixed. * Lots of debugging improvements, correctness changes and obsolete cruft removed. * Make it possible to build the Xorg server for Cygwin (Thanks to Yaakov Selkowitz for patches) 11cb1f55368dfeb7a8cc51e4662b9a5c *xorg-server-1.12.0-2.tar.bz2 1a28579b4a5aa98b1cccb9c835f683c5 *xorg-server-common-1.12.0-2.tar.bz2 bb8c7f768ecd0710d149e248e19e9ffa *xorg-server-devel-1.12.0-2.tar.bz2 898b2b6eb92b74e5932c2863b97f4562 *xorg-server-dmx-1.12.0-2.tar.bz2 017d3fbb83b29536b2981260cd4a16c9 *xorg-server-extra-1.12.0-2.tar.bz2 920a7aad32e70cc3615a931346cc76de *xorg-server-1.12.0-2-src.tar.bz2 [1] http://lists.x.org/archives/xorg-devel/2012-March/030059.html [2] This one was just terrible, see http://cgit.freedesktop.org/~jturney/xserver/commitid=475d248cef2c84e56458f9faa4d95157ed904f8b -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.12.0-1 (TEST)
On 14/03/2012 14:25, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-1 *** xorg-server-dmx-1.12.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.12 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. These packages have been promoted from test to current. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 01/04/2012 07:07, Jim Reisert AD1C wrote: On Sat, Mar 31, 2012 at 9:26 AM, Ken Brown wrote: I wanted to do some further tests, but I thought I should install the latest Cygwin snapshot (2012-03-30) first. With that Cygwin snapshot, the XWin snapshot of 20120329 won't start. It's not quite right here either. Xwin starts up OK, but I can't get an xterm going from the menu (stack dump). But if I open a CMD window and type xterm -display localhost:0 then the xterm starts up OK. If the cygwin 1.7.12 snapshot breaks the package XWin, you probably want to report that in the 1.7.12 snapshot call for testing thread, so the people who can fix problems with that will notice. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 31/03/2012 11:28, Jon TURNEY wrote: On 30/03/2012 12:36, Jon TURNEY wrote: For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll I'm not sure how the X server changes could directly cause that to happen. I can reproduce that same problem with the same backtrace with X server 1.11.4-5, so I don't think this can be called a regression in 1.12.0-1. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 30/03/2012 12:36, Jon TURNEY wrote: On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). Attaching to the texworks process, I get a backtrace like this: (gdb) bt #0 0x7c90e514 in ntdll!LdrAccessResource () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c90df4a in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x7c809590 in KERNEL32!CreateFileMappingA () from /cygdrive/c/WINDOWS/system32/kernel32.dll #3 0x7c80a115 in WaitForMultipleObjects () from /cygdrive/c/WINDOWS/system32/kernel32.dll #4 0x610ce614 in select_stuff::wait(_types_fd_set*, _types_fd_set*, _types_fd_set*, unsigned long) () from /usr/bin/cygwin1.dll #5 0x610cf02b in cygwin_select () from /usr/bin/cygwin1.dll #6 0x610d33d5 in _sigfe () from /usr/bin/cygwin1.dll #7 0x0022b87c in ?? () #8 0x6d445820 in cygQtCore-4!_ZN15QProcessManager11qt_metacastEPKc () from /usr/bin/cygQtCore-4.dll #9 0x6d446e97 in cygQtCore-4!_ZN15QProcessPrivate15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #10 0x6d40fb85 in cygQtCore-4!_ZN8QProcess15waitForFinishedEi () from /usr/bin/cygQtCore-4.dll #11 0x6d41286c in cygQtCore-4!_ZN8QProcess7executeERK7QStringRK11QStringList () from /usr/bin/cygQtCore-4.dll #12 0x0043a350 in ?? () #13 0x0047b8c5 in ?? () #14 0x6d46e733 in cygQtCore-4!_ZN11QMetaObject8activateEP7QObjectPKS_iPPv () from /usr/bin/cygQtCore-4.dll #15 0x6bc8b99b in cygQtGui-4!_ZN7QAction9triggeredEb () from /usr/bin/cygQtGui-4.dll #16 0x6bc8bb9a in cygQtGui-4!_ZN7QAction8activateENS_11ActionEventE () from /usr/bin/cygQtGui-4.dll #17 0x6c08dd06 in cygQtGui-4!_ZN11QToolButton14nextCheckStateEv () from /usr/bin/cygQtGui-4.dll #18 0x6bfe0185 in cygQtGui-4!_ZN22QAbstractButtonPrivate5clickEv () from /usr/bin/cygQtGui-4.dll #19 0x6bfe0426 in cygQtGui-4!_ZN15QAbstractButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #20 0x6c08ddac in cygQtGui-4!_ZN11QToolButton17mouseReleaseEventEP11QMouseEvent () from /usr/bin/cygQtGui-4.dll #21 0x6bcd8769 in cygQtGui-4!_ZN7QWidget5eventEP6QEvent () from /usr/bin/cygQtGui-4.dll #22 0x6bc90fec in cygQtGui-4!_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #23 0x6bc95e45 in cygQtGui-4!_ZN12QApplication6notifyEP7QObjectP6QEvent () from /usr/bin/cygQtGui-4.dll #24 0x6d45cefd in cygQtCore-4!_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent () from /usr/bin/cygQtCore-4.dll #25 0x6bc91d98 in cygQtGui-4!_ZN19QApplicationPrivate14sendMouseEventEP7QWidgetP11QMouseEventS1_S1_PS1_R8QPointerIS0_Eb () from /usr/bin/cygQtGui-4.dll #26 0x6bd007ed in cygQtGui-4!_ZN9QETWidget19translateMouseEventEPK7_XEvent () from /usr/bin/cygQtGui-4.dll #27 0x6bcff421 in cygQtGui-4!_ZN12QApplication15x11ProcessEventEP7_XEvent () from /usr/bin/cygQtGui-4.dll #28 0x6bd21f82 in cygQtGui-4!_ZN23QGuiEventDispatcherGlibC2EP7QObject () from /usr/bin/cygQtGui-4.dll #29 0x5efecb08 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #30 0x5efed208 in g_main_context_dispatch () from /usr/bin/cygglib-2.0-0.dll #31 0x5efed3cf in g_main_context_iteration () from /usr/bin/cygglib-2.0-0.dll #32 0x6d480671 in cygQtCore-4!_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtCore-4.dll #33 0x6bd21cb7 in cygQtGui-4!_ZN23QGuiEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE () from /usr/bin/cygQtGui-4.dll #34 0x6d45c587 in cygQtCore-4
Re: X server crash when running texworks
On 29/03/2012 20:59, Ken Brown wrote: On 3/29/2012 8:14 AM, Jon TURNEY wrote: Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. OK, I'm running it now and have attached gdb to it. The good news is that I've been running it for a couple hours with no crash, and I've used texworks and have opened many tex files and pdf files in it without a problem. The bad news is that texworks becomes unresponsive and has to be killed whenever I try to compile a tex file. I have no idea whether this is due to an X server problem or something completely different. Anyway, I'll post a backtrace if the server crashes. In case you want to try to reproduce the current problem, start texworks, open a tex file (such as the file test1.tex whose contents I listed at the beginning of this thread), and click on the icon at the left end of the toolbar (brown triangle on a green background). This is supposed to cause test1.tex to get compiled, but for me it just causes texworks to become unresponsive. This was working properly with the previous version of the X server (until the server crashed). Thanks for testing this X server snapshot. For me, the problem of texworks hanging only occurs very intermittently. It seems to be blocked deep in QtCore, waiting for the spawned process to terminate (which has already happened). I'm not sure how the X server changes could directly cause that to happen. For me, it usually completes running the spawned pdftext, but that reports the error ! I can't find file `test1.tex'. A word about why the icons look so bad: The _NET_WM_ICON icons that texworks has are only provided in 128x128 and 512x512 sizes, which we then have to scale down to 32x32. I'm not sure if these icons aren't too large to be useful anywhere! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cannot launch ssh from X11 system tray icon
On 23/03/2012 17:56, Craig wrote: debug1: Sending command: xterm 0 [main] ssh 2184 select_stuff::wait: WaitForMultipleObjects failed debug1: channel 0: free: client-session, nchannels 1 select: Permission denied So can anyone tell me why I get the select / waitForMultipleObjects error? This error is coming from inside the select() emulation in the cygwin DLL itself. I've no idea why this is failing, and apparently only when an ancestor is the X server. You might want to ask about this on the main cygwin list, it might get the attention of someone with more insight. One thing to consider trying is that it might be something to do with the environment inherited by processes started directly from the start menu, rather than something specific to the X server, i.e. try starting your test script directly from a start menu shortcut in a similar way to the X server is started... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 28/03/2012 13:44, Ken Brown wrote: On 3/28/2012 8:28 AM, Ken Brown wrote: On 3/28/2012 7:16 AM, Jon TURNEY wrote: I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 Yes, that seems to fix it. I just started texworks and compiled 6 or 7 tex documents without a crash. I've never been able to do more than 1 or 2 before. Good. I spoke too soon. I closed texworks and was doing other things (not even involving X to my knowledge), and the X server just crashed. I'm attaching XWin.0.log. Not so good :-(. Thanks for testing it, anyway. I found a rather bad crash bug I'd introduced and fixed that, so you might want to try today's snapshot [1], but I'm not confident that I fixed the problem you saw, so a backtrace would be helpful if you still get crashes. [1] ftp://cygwin.com/pub/cygwinx/XWin.20120329-git-6d4583d53c249549.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 26/03/2012 21:32, Ken Brown wrote: On 3/26/2012 4:06 PM, Jon TURNEY wrote: On 26/03/2012 20:47, Ken Brown wrote: On 3/24/2012 3:47 PM, Ken Brown wrote: One further detail for anyone trying to reproduce this: I just tried it on a second computer, and my recipe didn't immediately produce the crash. But I simply started trying to use texworks (loading and compiling various tex documents), and the X server crashed within a few minutes. Thanks very much for the detailed report. On the off chance this is a known issue, would you mind downloading the X server symbols and getting a backtrace using the instruction on [1], before I try to reproduce it. OK, the backtrace is attached. Thanks very much. I'm afraid I can't reproduce your issue, but looking at the backtrace and the somewhat intermittent nature of the fault, I think perhaps this crash is caused by a race condition which exists in the conversion of the window icon from an X property to a Windows icon. I've uploaded a snapshot with some fixes for that at [1], perhaps you could try that out and see if it helps? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120328-git-ab32650607c59327.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] New package: xlaunch (experimental)
xlaunch is a simple Windows GUI tool for starting XWin. At this stage, this package will only be of interest to people who are willing to test it and report problems and bugs, and ideally write patches to fix those issues. It needs more work to be truly useful. Some of the more obvious issues: * xlaunch does not report it's version number anywhere * The htmlhelp is not complete. In particular, some GUI options are not documented * It needs to play nicely with Xming and VcXsrv versions of itself: (i) it should not fight over who owns .xlaunch files, (ii) it should ignore attributes in the .xlaunch XML it doesn't understand * It should base the list of local Xsessions it displays on what is actually installed, rather than a fixed list * It should support the -displayfd option to dynamically allocate display numbers * The ability to add extra options to the ssh command line (e.g. -C) might be useful * The window title should mention xlaunch, otherwise it could be hard to identify the xlaunch window on the taskbar or when alt-tabbing * It should maintain history lists of remote hosts and commands run in a dot file. * When it is useful to do so, the Cygwin/X User Guide documentation needs to be updated to mention xlaunch The source is available from git://people.freedesktop.org/~jturney/xlaunch cbccdf05329edb9590af66dad8ff7f36 *xlaunch-20120316-1.tar.bz2 0ad1d006c8d29e8100d5dc419f42bbc6 *xlaunch-20120316-1-src.tar.bz2 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X server crash when running texworks
On 26/03/2012 20:47, Ken Brown wrote:
On 3/24/2012 3:47 PM, Ken Brown wrote:
To reproduce:
1. Install texworks-0.4.3-1 from Cygwin Ports.
2. Create two tex files in your home directory, say test1.tex and
test2.tex. I don't know if the contents matter, but in my case both
files contain the following:
\documentclass{article}
\begin{document}
Hello
\end{document}
3. Start the X server by using the Start Menu shortcut.
4. Start texworks by typing texworks in an xterm window.
5. Click on the Open icon to open one of the tex files. Then do the
same to open the second.
At this point the X server crashes and gives the message Caught signal
11 (segmentation fault). Server aborting.
Before the crash I get the following warning in the xterm window when I
open a file:
QFileSystemWatcher: failed to add paths: /home/kbrown
I don't know if this is significant.su
I'm attaching cygcheck output and XWin.0.log.
Ken
P.S. I'm currently using the test version of xorg-server (1.12.0-1), but
I can reproduce the crash with 1.11.4-5 also. Also, I'm currently
testing the latest Cygwin snapshot. I just tried reverting to 1.7.11,
and the X server still crashed, but not just from opening two files. I
had to open and compile several tex documents before it happened.
One further detail for anyone trying to reproduce this: I just tried it on a
second computer, and my recipe didn't immediately produce the crash. But I
simply started trying to use texworks (loading and compiling various tex
documents), and the X server crashed within a few minutes.
Thanks very much for the detailed report.
On the off chance this is a known issue, would you mind downloading the X
server symbols and getting a backtrace using the instruction on [1], before I
try to reproduce it.
[1] http://x.cygwin.com/devel/backtrace.html
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.12.0-1 (TEST)
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.12.0-1 *** xorg-server-dmx-1.12.0-1 These packages contain XWin and the other X.Org X11 servers. This is the first release of the xserver 1.12 series. It is currently available as a test release, and will be made stable in approximately two weeks if no major regressions are reported. Please try test releases and report problems to the Cygwin/X mailing list. Testing helps ensure good releases! Unfortunately, the upstream announce mail [1] does not contain a full changelog since 1.11, so you will need to consult the changelog or git for a list of upstream fixes and improvements. There are no (intentional) cygwin-specific changes since 1.11.4-5. 0525de11211e7983d3a7f348bae505b3 *xorg-server-1.12.0-1.tar.bz2 d3847fd1a1e688dbd5d177dff4c2e28b *xorg-server-dmx-1.12.0-1.tar.bz2 85ce42f082bb79bcd9a093b9f55d70dd *xorg-server-1.12.0-1-src.tar.bz2 [1] http://lists.x.org/archives/xorg-announce/2012-March/001846.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xwin.exe always take about 50% CPU load on Windows 7 with XDCMP connection
On 02/03/2012 09:24, Kees Dekker wrote: I’m using Xwin.exe (version 5. Feb 2012, X.org servers – 1.11.4-3) on my Windows 7 system. When connecting with XDCMP (using startxdcmp.bat, with %RUN% XWin -query %REMOTE_HOST% -once -lesspointer -clipboard -emulate3buttons), after connect, the CPU load is about 50%. Even when nothing is done (only the CDE desktop is running, nothing else). On another Windows 7 system, also connecting with XDCMP to the same server, same CDE, the CPU load is not that high. The version of XWin is one of 5. Feb 2009. The XCDMP server is a Solaris 10 system, using Solaris classic CDE (not the Java Desktop environment). The high CPU load did not happen when the CDE waits for the logon screen, but happens as soon as login was completed. BTW. Just when I was writing this email I decided to check (again) for a newer version, and there was one… Moving to X.org servers 1.11.4-5 seems to solve this issue ☺. However, I did not find any release note telling that this problem was solved…. I'm not sure where you were looking if you didn't find [1]. 'On Cygwin 1.7.10 this caused XWin to spin, when started from a non-cygwin process, spamming the log with _XSERVTransSocketUNIXAccept: accept() failed messages.' [1] http://cygwin.com/ml/cygwin-xfree-announce/2012-02/msg4.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Updated: xorg-server-1.11.4-4
On 24/02/2012 02:10, marco atzeri wrote: On Fri, Feb 24, 2012 at 2:47 AM, Jim Reisert AD1C wrote: On Wed, Feb 22, 2012 at 1:13 PM, Jon TURNEY wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.4-4 *** xorg-server-dmx-1.11.4-4 Did this release get pulled? It's over 24 hours later, I've tried two different servers, and setup is not finding it. I've never had this problem in the past. it seems not yet present, the last on http://cygwin.com/packages/xorg-server/ is xorg-server-1.11.4-3 Thanks for pointing this out. I'd failed to run the part of my upload script which moves the files into place. This was serendipitous, as it looks like the clipboard change I made in 1.11.4-4 has some bad side effects. I've uploaded a 1.11.4-5 with the clipboard change reverted. 1.11.4-4 is also now available in case anyone has a use for it's brokenness :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.11.4-5
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.4-5 *** xorg-server-dmx-1.11.4-5 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.11.4-4: * Reverted the clipboard change in 1.11.4-4, it broke some clipboard uses. 438e6821dcb1f7c727ad63ceb38e *xorg-server-1.11.4-5.tar.bz2 487bbe3149edfe2c49d61d7a34b11791 *xorg-server-dmx-1.11.4-5.tar.bz2 ea71ebda86ccdc3c563f269ebc781ae6 *xorg-server-1.11.4-5-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.11.4-4
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.4-4 *** xorg-server-dmx-1.11.4-4 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.11.4-3: * Remove useless /usr/adm/Xnmsgs functionality, so it doesn't trample on one of our listener sockets if we start with stderr closed. On Cygwin 1.7.10 this caused XWin to spin, when started from a non-cygwin process, spamming the log with _XSERVTransSocketUNIXAccept: accept() failed messages. This would also prevent the X server from accepting connections on the listener socket which had been trampled on. * Empty the Windows clipboard when X loses focus. This should allow us to update the Windows clipboard when the selection changes, but the selection owner has not, at the cost of emptying the clipboard if the selection was not changed while X has the focus. c5c752a2b76e52bf771a2447d1aa95ea *xorg-server-1.11.4-4.tar.bz2 9d66854b8604613445da7cf436e8cf53 *xorg-server-dmx-1.11.4-4.tar.bz2 e4846aa9f2ca9db6a0285730f62f354a *xorg-server-1.11.4-4-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe: _XSERVTransSocketUNIXAccept: accept() failed
On 17/02/2012 18:56, Jon TURNEY wrote: On 15/02/2012 16:39, Bonggren, Jeffrey L wrote: I have recently noticed that XWin.exe is spinning and maxing out a CPU core. I checked the log and saw that it is spamming it with _XSERVTransSocketUNIXAccept: accept() failed messages at a rate of about one per millisecond. This is generating a very large log file! Thanks for reporting this. This seems to be related in some way to how you start the X server. Starting it using startxwin.exe (the recommended method), I don't observe this problem, but using your startxwin.bat, I can reproduce the problem. The obvious difference here between these two cases is that we don't have a cygwin process as our immediate ancestor when started from a batch file, but how that could make a difference is a bit mysterious. This seems to be some sort of regression introduced with the cygwin 1.7.10 DLL, downgrading to 1.7.9 doesn't show the problem (although that is problematic as base-files now depends on tzset introduced in 1.7.10) stracing this is enlightening... 281 23126144 [main] XWin 3084 cygwin_select: select(255, 0x5FDE80, 0x0, 0x0, 0x22CBB4) 35 23126179 [main] XWin 3084 dtable::select_read: fd 0 32 23126211 [main] XWin 3084 dtable::select_read: fd 1 171 23126382 [main] XWin 3084 dtable::select_read: /usr/adm/X0msgs fd 2 33 23126415 [main] XWin 3084 dtable::select_read: /dev/windows fd 5 32 23126447 [main] XWin 3084 dtable::select_read: fd 7 170 23126617 [main] XWin 3084 dtable::select_read: fd 9 32 23126649 [main] XWin 3084 dtable::select_read: fd 10 31 23126680 [main] XWin 3084 dtable::select_read: fd 12 166 23126846 [main] XWin 3084 cygwin_select: to-tv_sec 560, to-tv_usec 203000, ms 560203 21 23126867 [main] XWin 3084 cygwin_select: sel.always_ready 1 25 23126892 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 21 23126913 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 211 23127124 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 25 23127149 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 18 23127167 [main] XWin 3084 peek_windows: window 5(0x0) not ready 17 23127184 [main] XWin 3084 set_bits: me 0x20511260, testing fd 2 (/usr/adm/X0msgs) 206 23127390 [main] XWin 3084 set_bits: ready 1 25 23127415 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 22 23127437 [main] XWin 3084 peek_socket: read_ready: 0, write_ready: 0, except_ready: 0 17 23127454 [main] XWin 3084 cygwin_select: 1 = select(255, 0x5FDE80, 0x22CA10, 0x22C9E0, 0x22CBB4) 208 23127662 [main] XWin 3084 select_stuff::cleanup: calling cleanup routines 20 23127682 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 17 23127699 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 23 23127722 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 17 23127739 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 17 23127756 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 278 23128034 [main] XWin 3084 socket_cleanup: si 0x0 si-thread 0x0 22 23128056 [main] XWin 3084 select_stuff::destroy: deleting select records 279 23128335 [main] XWin 3084 __set_errno: fhandler_socket* get(int):83 setting errno 108 20 23128355 [main] XWin 3084 cygwin_accept: -1 = accept(2, 0x22C92E, 0x22C99C), errno 108 92 23128447 [main] XWin 3084 write: write(3, 0x5F93A0, 13) 161 23128608 [main] XWin 3084 write: 13 = write(3, 0x5F93A0, 13) 236 23128844 [main] XWin 3084 write: write(3, 0x5F93A0, 11) 20 23128864 [main] XWin 3084 write: 11 = write(3, 0x5F93A0, 11) 964 23129828 [main] XWin 3084 write: 45 = write(2, 0x5FA880, 45) 191 23130019 [main] XWin 3084 write: write(3, 0x5F93A0, 34) 21 23130040 [main] XWin 3084 write: 34 = write(3, 0x5F93A0, 34) When started from a Windows parent process, stdin/stdout/stderr are closed, so the X server opens /usr/adm/X0msgs to write stderr output to. However, due to a bug in the X server, when doing that we can trample all over a socket listening on a well-known port, which has already been opened with fd 2. If that file fd ever shows as ready for reading, we will try to accept a connection on it, which is always going to fail :-) This can easily be reproduced using 'X 2-', which shows the same spinning behaviour. (In OsInit(), we check if fd 2 is writeable, and if not, assume stderr has been closed, and open /usr/adm/X0msgs for writing, and dup it on to fd 2. Unfortunately, this happens after CreateWellknownSockets() has opened the listener sockets, and that may use fd 2) This bug has been there a long time, I'm not sure why it's problem now, perhaps the cygwin DLL has changed behaviour so this fd is now always found ready to read? I've applied fix to address this, so hopefully this works better now. I've uploaded a snapshot at [1]. Perhaps you could try that out and see
Re: FW: RE: Cut and Paste between X and WindowsXP sometimes fails
On 15/02/2012 16:26, Bennett, Tony wrote: Given that I'd have to build xclipboard for the host that I'm XDMCPing to, and that host is running AIX... Sadly, I may just have to live with the problem. Is there any hope that the issue will be corrected in the foreseeable future...??? Well, looking at the rate of progress on fd.o bug #5735, it seems reasonable to hope that it will be fixed in a year or two :-) I've applied the patch I've suggested there to today's snapshot, uploaded a at [1]. Perhaps you could try that out and see if that improves things for you? [1] ftp://cygwin.com/pub/cygwinx/XWin.20120218-git-c3b936a38812f88b.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin.exe: _XSERVTransSocketUNIXAccept: accept() failed
On 15/02/2012 16:39, Bonggren, Jeffrey L wrote: I have recently noticed that XWin.exe is spinning and maxing out a CPU core. I checked the log and saw that it is spamming it with _XSERVTransSocketUNIXAccept: accept() failed messages at a rate of about one per millisecond. This is generating a very large log file! Thanks for reporting this. This seems to be related in some way to how you start the X server. Starting it using startxwin.exe (the recommended method), I don't observe this problem, but using your startxwin.bat, I can reproduce the problem. The obvious difference here between these two cases is that we don't have a cygwin process as our immediate ancestor when started from a batch file, but how that could make a difference is a bit mysterious. This seems to be some sort of regression introduced with the cygwin 1.7.10 DLL, downgrading to 1.7.9 doesn't show the problem (although that is problematic as base-files now depends on tzset introduced in 1.7.10) X seems to be behaving normally in spite of this. I typically run only xterm and nedit (many instances) locally. I have verified that the Windows firewall has a blanket allow rule for XWin.exe. I can't place the exact update that caused this problem, but I believe it was not having this issue in December 2011. I am never more than a week behind on updating cygwin. I tried falling back to the previous 1.11.4-2 version of xorg-server, but it failed to start. Perhaps a version conflict with some of the other updated packages? As the announce mail says, you need to upgrade xorg-server and libGL1 at the same time. If you downgrade xorg-server, you need to also downgrade libGL1. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWindows graphics Subroutines
On 17/02/2012 22:06, Ron Hadley wrote: I am trying to port XWindows graphics code from my Linux workstation to my PC using cygwinX. I cannot find the XWindows graphics subroutines (routines that start with X) anywhere in the cygwin library. The file I thought should contain them, cygwin/lib/libX11.a contains similar routines with different names, for which I can find no documentation. Can you direct me to either the XWindows library or the documentation for the routines in libX11.a? Thank you I'm not sure which Xlib function you are looking for, but there should be no difference in the Xlib API between linux and cygwin/x. The libX11-devel package which contains that library also contains man pages for the functions it provides [1] [1] http://cygwin.com/packages/libX11-devel/libX11-devel-1.4.4-1 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: FW: RE: Cut and Paste between X and WindowsXP sometimes fails
On 13/02/2012 23:05, Bennett, Tony wrote: On 03/02/2012 22:55, Bennett, Tony wrote: Often when cutting from Xwin and attempting to Paste to a WindowsXP application, the most recent cut is not pasted... but instead a previous Xwin cut. In other words, this scenario: LOCATIONACTComment XwinCut abc WinXP Pastecorrectly pastes abc XwinCut def WinXP PasteIncorrectly pastes abc When the above problem occurs, no matter how many times a cut from Xwin, Whenever I paste on WinXP it pastes abc. I can correct the problem by cutting from WinXP and pasting into Xwin... ...after doing this the next Xwin cut will correctly paste on WinXP. Yes, this is a rather long-standing problem (see the bug report at [1] for some of the technical details), which is unfortunately not easy to fix in a way that works well for all cases. Fortunately, there is a simple workaround for the moment: If you install and run xclipboard, that will cause XWin to notice every change of the clipboard contents. Thanks for the reply, Jon. Exactly how do I use xclipboard...??? Here's how I'm starting Xwin right now in a Windows Script called startx.bat: @echo off C: chdir C:\cygwin\bin bash -c PATH=$PATH:/bin:/usr/bin;XWin -clipboard -logverbose 3 -ac -query cdcxvd0559.con-way.com -fp \tcp/cdcxvd0559.con-way.com:8000,/usr/share/fonts/100dpi/,/usr/share/fonts/75dpi/,/usr/share/fonts/Type1/\ You'll notice I use XDMCP to establish a CDE session on cdcxvd0559... I've tried starting xclipboard in the same script, after starting Xwin (and sometimes even specifying -noclipboard)... and I always get an IO error and X-win dies. Ah. Applying this workaround is perhaps not so simple when using XDMCP :-( You can't just add a 'xclipboard' line after 'XWin ', because the X server may still be starting up when xclipboard tries to start, which will fail. However, this shouldn't lead to the X server itself dying. It's possible to put a wait here, but there are a couple of other reasons why this approach won't work well. You might find it easier to start xclipboard on the host you are XDMCPing to, possibly as part of your login script there -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cut and Paste between X and WindowsXP sometimes fails
On 03/02/2012 22:55, Bennett, Tony wrote: Often when cutting from Xwin and attempting to Paste to a WindowsXP application, the most recent cut is not pasted... but instead a previous Xwin cut. In other words, this scenario: LOCATIONACTComment XwinCut abc WinXP Paste correctly pastes abc Xwin Cut def WinXP Paste Incorrectly pastes abc When the above problem occurs, no matter how many times a cut from Xwin, Whenever I paste on WinXP it pastes abc. I can correct the problem by cutting from WinXP and pasting into Xwin... ...after doing this the next Xwin cut will correctly paste on WinXP. Yes, this is a rather long-standing problem (see the bug report at [1] for some of the technical details), which is unfortunately not easy to fix in a way that works well for all cases. Fortunately, there is a simple workaround for the moment: If you install and run xclipboard, that will cause XWin to notice every change of the clipboard contents. [1] https://bugs.freedesktop.org/show_bug.cgi?id=5735 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X still crashing, but interesting log messages... different config vals needed?
On 12/02/2012 23:51, Linda Walsh wrote: Jon TURNEY wrote: On 11/02/2012 04:19, Linda Walsh wrote: Still crashes in all the places it did 2 months ago, and more, but gives more interesting messages in log file (/var/log/xwin/XWin.0.log I assume this refers to the problem reported in [1], crashing when running yast2 on SuSE 11.4. I don't know anything about any other crashes you might have been experiencing. I haven't done anything specific to try to fix this, because I can't reproduce the problem and I don't have a useful backtrace. It would be of great help if you could follow the instructions at [2] to download the debug symbols and obtain a backtrace of the crash. I did that last time, then got another email from another admin saying to try some other version instead of that one because the instructions were wrong. I'm assuming you're referring to the exchange we had at [3], but I don't accept that as an accurate summary of it. Nevertheless, partly to prevent a re-iteration of that pointless debate, I have improved my build scripts so I now preserve the debug symbols for the packaged builds of XWin. Instructions on downloading them are available at [2]. At that point, I gave up to go use Xming which didn't have the problem, and was hoping someone else would run into it, since with cygwin, I have had it set on autostart, and it usually crashes within 15-20 minuts -- make kernel, or almost any qt based util,... then I just start Xming -- which was stable until this last cygwin update...which doesn't make sense, as I didn't think there was any code overlap Indeed, the only things they should have in common are your OS installation and your computer, which suggests to me, at least, that the problem may lie there. (main thing is I can no longer click on 'X' in a window and have it close, I have to go through the program's menus in each program to close it...very annoying. Was wondering if I should be giving any different options that might help it behave better? Log from last run below -- Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.11.4.0 OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64) Package: version 1.11.4-3 built 2012-02-05 XWin was started with the following command line: /usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm [ 14334.463] SocketUNIXAccept: accept() failed This log looks normal apart from this line. I don't think this is a new warning, and wasn't in the previous log you posted, so it's hard to see how this could be directly related to the problem. On the other hand, I'm a bit surprised that it works at all after that error. Nevertheless, since UNIX sockets don't seem to be working correctly for you, you might like to try adding '-nolisten unix' to see if that makes any difference. I assume you didn't try this. [1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00012.html [2] http://x.cygwin.com/devel/backtrace.html [3] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00029.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X still crashing, but interesting log messages... different config vals needed?
On 11/02/2012 04:19, Linda Walsh wrote:
Still crashes in all the places it did 2 months ago, and more, but
gives more interesting messages in log file (/var/log/xwin/XWin.0.log
I assume this refers to the problem reported in [1], crashing when running
yast2 on SuSE 11.4. I don't know anything about any other crashes you might
have been experiencing.
I haven't done anything specific to try to fix this, because I can't reproduce
the problem and I don't have a useful backtrace.
It would be of great help if you could follow the instructions at [2] to
download the debug symbols and obtain a backtrace of the crash.
Was wondering if I should be giving any different options that might
help it behave better?
Log from last run below --
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.11.4.0
OS: Windows 7 Service Pack 1 [Windows NT 6.1 build 7601] (WoW64)
Package: version 1.11.4-3 built 2012-02-05
XWin was started with the following command line:
/usr/bin/XWin -dpi 101 -multiwindow -clipboard -nowinkill -wm
[ 14334.463] SocketUNIXAccept: accept() failed
This log looks normal apart from this line.
I don't think this is a new warning, and wasn't in the previous log you
posted, so it's hard to see how this could be directly related to the problem.
On the other hand, I'm a bit surprised that it works at all after that error.
Nevertheless, since UNIX sockets don't seem to be working correctly for you,
you might like to try adding '-nolisten unix' to see if that makes any
difference.
On 11/02/2012 03:53, Linda Walsh wrote:
Re: oh forget the cygcheck...
(attached)..
cygwin = '() { return 0
}'
While I doubt that is is relevant, that's either a bug in cygcheck or a rather
strange setting for the CYGWIN env var
[1] http://cygwin.com/ml/cygwin-xfree/2011-08/msg00012.html
[2] http://x.cygwin.com/devel/backtrace.html
--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.11.4-3
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.4-3 *** xorg-server-dmx-1.11.4-3 These packages contain XWin and the other X.Org X11 servers. This is an update to align with the update to mesa 7.11. You should upgrade libGL1 to 7.11.2-1 at the same time as upgrading the X server to 1.11.4-3, or you may experience X server crashes when using OpenGL applications which use indirect rendering. The following cygwin-specific changes have been made since 1.11.4-2: * Fall back to mesa software rendering rather than using the GDI Generic native renderer (when -wgl is enabled) * Synchronize the indirect function dispatch table offsets with mesa 7.11 * Use shared libglapi for dispatch table 7000b5a215ecd325ca93d59a0e27f772 *xorg-server-1.11.4-3.tar.bz2 c20e1cd9295385f25c32a5409c480f9f *xorg-server-dmx-1.11.4-3.tar.bz2 8646757ae870be8d3db4523f11762649 *xorg-server-1.11.4-3-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: QAW: AW: Levovo trackpoint come delayed (reproducable with xev)
On 02/02/2012 19:46, Paul Maier wrote: 2. Download XWin.20120129-git-45e67e363e19a481.exe.bz2. /bin/startxwin -- /bin/XWin.20120129-git-45e67e363e19a481.exe -logverbose 3 -clipboard -emulate3buttons 100 -nounixkill -nowinkill -xkboptions nbsp:level3 - Doesn't start. Error message on the console is: giving up. /bin/startxwin: No such file or directory (errno 2): unable to connect to X server /bin/startxwin: No such process (errno 3): Server error. - No output at all to file /var/log/xwin/XWin.0.log. Possibly you need to 'chmod +x /bin/XWin.20120129-git-45e67e363e19a481.exe' -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xwin.exe 1.11.4-1 segmentation fault on startup (-wgl -multiwindow)
On 01/02/2012 16:26, Christian Tuma wrote: Thank you for your quick response and the fix. Now XWin starts without crashing. Attached please see the new log-file. You don't appear to be using a graphics card driver with OpenGL acceleration though, I'd be interested to which one? Good point. My system is a Lenovo ThinkPad W520 - it contains two different graphics systems: 1) integrated Intel HD Graphics system (driver 8.15.10.2538) 2) Nvidia Quadro 1000M (latest driver version 285.62 supporting all core features of OpenGL 4.2) XWin seems to run (or to detect or to talk to) with the integrated Intel HD graphics system (GDI generic) and not with the Nvidia Quadro 1000M. How can I change this behaviour? When starting an application within Windows 7 I can usually choose in the context menu which of the two graphics processors to use. How do I do this from within Cygwin? Ah, interesting. I would say it's a bug in the switchable graphics drivers that it doesn't know that OpenGL applications should cause a switch to the non-integrated graphics. Possibly there is some way to configure the driver to tell it that an application is one that needs the non-integrated graphics, so it will switch. It's not very sensible for Xwin to use the GDI generic GL renderer, it would be better to fallback to the mesa software renderer, so I'll make a change to cause that to happen. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.11.4-2
On 31/01/2012 22:02, Angelo Graziosi wrote: I notice a problem moving the mouse pointer. Both with xorg-server-1.11.4-1 and xorg-server-1.11.4-2, the mouse pointer moves in slow motion, in steps, with a delay.. one has difficulty to move finely... If I switch-off wgl, it moves just fine! Is this running a particular X application? Or before you even start one? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: [ANNOUNCEMENT] Updated: xorg-server-1.11.4-2
On 01/02/2012 10:09, Angelo Graziosi wrote: Il 01/02/2012 10.18, Jon TURNEY ha scritto: On 31/01/2012 22:02, Angelo Graziosi wrote: I notice a problem moving the mouse pointer. Both with xorg-server-1.11.4-1 and xorg-server-1.11.4-2, the mouse pointer moves in slow motion, in steps, with a delay.. one has difficulty to move finely... If I switch-off wgl, it moves just fine! Is this running a particular X application? Or before you even start one? Before I start one.. Just starting X with the link I described. I have that link on the desktop and in Automatic Run, so just loging in starts the X server. Killing all XWin and starting the X clicking the link on the Desktop DOES NOT fix but has the same result. Only if I start with -nowgl option I get the normal fluidity of the mouse pointer.. (as before you released 1.11.4-1... Very strange. When you get the jerky mouse pointer, is the CPU usage high? If so, is it XWin which is using it? or is it idling? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xwin.exe 1.11.4-1 segmentation fault on startup (-wgl -multiwindow)
On 31/01/2012 08:43, Christian Tuma wrote: when I invoke xwin.exe for hardware accelerated OpenGL (AIGLX) $ xwin -wgl -multiwindow a segmentation fault occurs. This happens with the latest version (1.11.4-1), but I already had the same problem with my first installation of the X server (1.11.3-1). Attached please find cygcheck.out (sensitive data deleted) and XWin.0.log for further details. [ 3248.876] GL_VERSION: 1.1.0 [ 3248.876] GL_VENDOR: Microsoft Corporation [ 3248.876] GL_RENDERER:GDI Generic [ 3248.876] GL_EXTENSIONS: GL_WIN_swap_hint GL_EXT_bgra GL_EXT_paletted_texture [ 3248.876] wglwrap: Can't resolve wglGetExtensionsStringARB [ 3248.876] WGL_EXTENSIONS: (null)Segmentation fault at address 0x0 [ 3248.876] Fatal server error: [ 3248.876] Caught signal 11 (Segmentation fault). Server aborting [ 3248.876] Server terminated with error (1). Closing log file. Thanks for reporting this issue. I've uploaded a 1.11.4-2 which should contain a fix. When it reaches the mirrors, perhaps you could try it and see if it fixes things for you? You don't appear to be using a graphics card driver with OpenGL acceleration though, I'd be interested to which one? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Errormessage
On 30/01/2012 12:20, Sonja Abe wrote: I have installed cygwinx and now when I will start the programm and entering startxwin, I got allways this error-message: startxwin: Another X server instance is running on DISPLAY :0 . Resource temprarily unavailable Can you help me and write me, what I can do to run this program. Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html There's probably more detail about why it thinks another X server is already running in /var/log/xwin/XWin.0.log, which is why we ask people to attach it to their problem reports in the page linked above. Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
[ANNOUNCEMENT] Updated: xorg-server-1.11.4-2
The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.4-2 *** xorg-server-dmx-1.11.4-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.11.4-1: * Fix a crash in -wgl mode when the WGL_ARB_extensions_string extension is not supported e.g with the 'GDI Generic' GL renderer 5f374cd95e0f67ffe39a095369b32bae *xorg-server-1.11.4-2.tar.bz2 4cef79e875d6d3d2cf038024307a513e *xorg-server-dmx-1.11.4-2.tar.bz2 4c52d3d92bb07d85b2d87675cf50b556 *xorg-server-1.11.4-2-src.tar.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: AW: Levovo trackpoint come delayed (reproducable with xev)
On 23/01/2012 21:56, Paul Maier wrote: On 22/01/2012 23:10, Paul Maier wrote: Lenovo trackpoint scrolling events get buffered somewhere until I release the button: then I get hundreds of scrolling events all at once. I can clearly see these events in xev. Result is that I don't really experience scrolling, rather jumping up and down with a random-like distance. With trackpoint I mean that red button in the middle of a Lenovo laptop. (Mouse wheel scrolling works perfect, in contrast.) Have you tried the workaround given in [1] ? According to the internet, the trackpoint driver tries to be too clever and doesn't send WM_MOUSEWHEEL messages, but tries to fiddle with the Windows scrollbars directly itself, which obviously isn't going to work well for an X window :S [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint I can't find any of the files tp4*.dat on my PC (I'm running Windows 7) - see console output below. It seems that FAQ might need a little updating, that file might found under %PROGRAMFILES% now, C:\Program Files\Synaptics\SynTP\TP4table.dat or C:\Program Files\Lenovo\Trackpoint\tp4table.dat for example. And I do get the trackpoint events, they are just delayed until I release that button; on release I get hundreds of correct events scrolling my window to somewhere. How many events I get depends on how long or how intense I pressed the track point (sounds reasonable to me). So, if you can't try the workaround, perhaps you could do a bit of investigation? Download the latest snapshot built with debugging enabled from [1] Run it using 'WIN_DEBUG_MESSAGES=1 ./XWin -logverbose 3 your usual XWin options, -multiwindow for example' Open up an xterm You should then be able to see WM_MOUSEWHEEL messages being delivered in the debug output from XWin when you use the trackpoint scrolling. Are they being delivered on time, or only when you release the the button? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Levovo trackpoint come delayed (reproducable with xev)
On 22/01/2012 23:10, Paul Maier wrote: Lenovo trackpoint scrolling events get buffered somewhere until I release the button: then I get hundreds of scrolling events all at once. I can clearly see these events in xev. Result is that I don't really experience scrolling, rather jumping up and down with a random-like distance. With trackpoint I mean that red button in the middle of a Lenovo laptop. (Mouse wheel scrolling works perfect, in contrast.) Have you tried the workaround given in [1] ? According to the internet, the trackpoint driver tries to be too clever and doesn't send WM_MOUSEWHEEL messages, but tries to fiddle with the Windows scrollbars directly itself, which obviously isn't going to work well for an X window :S [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: font question, xfs locally on cygwin?
On 17/01/2012 19:58, mathog wrote: On 17-Jan-2012 11:07, mathog wrote: Is xfs really needed, or is putting in the right libfreetype bits and pieces enough? The files that go in /usr/share/fonts/default/Type1 on Mandriva, for instance? To address some of the questions from your previous email: xfs doesn't magically make fonts scalable, or know how to read types of font that the X server itself doesn't (now). So there is no reason whatsoever to use a local xfs. The same result can be achieved (better), simply by adding the same directories to the X server's fontpath. There are also some technical difficulties in building xfs for cygwin, due to libXfont's widespread use of weak symbols. Furthermore, core (server) fonts are a legacy feature. All modern toolkits use Xft (client) fonts. (See [1]) For all of these reasons, we don't provide an xfs. So I tried copying the files from Mandriva over and dropping them into the Cygwin distro. That actually worked, in that the fonts then appeared and they looked good on the screen. Looks like xfs isn't needed. However, there was a problem with the naming conventions. This one works on the Mandriva X11 server -*-courier-medium-r-normal--17-120-*-*-*-iso8859-1 but it doesn't work on the Cygwin X11 server. The file name there must be -*-courier-medium-r-normal--17-120-*-*-*-*-iso8859-13 The problem seems to be that the font naming convention is slightly different. There are 3 fields between 120 and iso8859 on the Mandriva machine, but 4 on Cygwin/X. Change in the font naming conventions between different Xorg versions??? These names should be XLFDs (X logical font descriptions [1]). The first one doesn't look well-formed as it only has 13 fields. Which Cygwin package would install /usr/share/fonts/Type1 properly? I think the fonts we talking about are the so-called 'URW fonts', donated by the URW foundry to ghostscript. These are packaged with ghostscript on cygwin, but it doesn't install them in a place where they can be shared with other uses. All other things being equal, it would be nice to have these fonts available to X, although I don't know if it would be better to pick a some other fonts to be aliased as scalable versions of courier etc. Also, some investigation would be needed to discover if we should adjust the ghostscript-fonts-std package, or make a separate package for these fonts for the X server. We would also need to make or obtain a suitable fonts.alias to map the font names to the standard postscript font names (e.g. so URW nimbus mono l can be accessed by the name courier) [1] http://www.x.org/releases/X11R7.6/doc/xorg-docs/fonts/fonts.html [2] http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/XLFD/xlfd.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWIN-1.11.3.0 crashes when some client programs terminate.
On 10/01/2012 04:01, rodmed...@cantv.net wrote: With the last release of Xwin (1.11.3.0) I have found the following problem. The termination of some programs that otherwise work correctly, produces a crash of Xwin. With some client programs the problem allways appears, with others it happens only occationally. I am attaching the sources of a simple program that consistently produces the crash of the server. I tried your test program, but couldn't reproduce the crash. Perhaps you can follow the instructions at [1] and produce a backtrace? Thanks for attaching the cygcheck.out and XWin.0.log files. I notice one odd thing in the XWin.0.log: [ 9863.906] setlocale failed. According to your cygcheck.out, you have LANG = 'es_VE.ISO-8859-1', which should be valid, and I can't reproduce this either, so there is something I don't understand going on here. Does this error disappear when you revert to a previous version also? [1] http://x.cygwin.com/devel/backtrace.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: considering modifier keys after gaining focus
On 09/01/2012 18:11, Oliver Schmidt wrote: On 09.01.2012 15:06, Jon TURNEY wrote: The code would seem to end up simpler (which is an important consideration) if we were to modify winKeybdReleaseKeys() not to release modifier keys. Some archaeology is probably required to determine if releasing the modifier keys in winKeybdReleaseKeys() is necessary to avoid some other undesirable behaviour? I don't know anything about the cygwin X server history, I can only guess why the current code is as it is: Perhaps the modifier keys are released afer loosing a window's focus because if another Non-cygwin window gains the focus, no more modifier change events will arrive to the cygwin x server. Then you know as much as I do. I didn't write this code. Fortunately, the history of the code is preserved both in the VCS, and in discussions on this mailing list. I think it is useful to consider this history when reviewing a patch, as there are a couple of dangers this avoids: Are we going in circles? Are we fixing one bug just to re-introduce another bug which has already been fixed? Are we doing in the wrong direction? Adding special case on top of special case, increasing the complexity of the code, is often a sign that something is wrong with the approach taken. Anyhow, in a brief look at some mailing list discussions from 2002 or so, it seems that: i) We must release modifier keys when focus leaves the X server, as modifier keys may be part of a Windows shell shortcut which moves the focus elsewhere, e.g. alt-tab) so the key-release isn't received by the X server. ii) We must release non-modifier keys when focus leaves the X server, or they continue to auto-repeat in the X server (specifically a problem when a key-press closes a window (such as typing ctrl-d or exit into an Xterm), as the key-release goes to the next window to receive focus, which may not be an X window) After your change we will have: iii) We must press held modifier keys when focus enters the X server (toggling latching ones as appropriate), so that the future key-presses have the correct modifiers. So I guess we should also consider: iv) What should we do about held non-modifier keys when focus enters the X server? It looks like these should be pressed as well for strict correctness. If we hold down a non-modifier key so it auto-repeats, and move the focus between X and native windows, the native windows receive repeats, but the the X windows do not. I doubt many people care about this behaviour, though :-) Staring at the code some more, this means that winInitializeModeKeyStates() is possibly wrong: It should do the same work as winRestoreModeKeyStates(). If it's possible to launch the X server with a key held down, that key won't be noticed until it's pressed and released :-) This maps VK_CONTROL to KEY_LCtrl. Why not use VK_LCONTROL and VK_RCONTROL, so the generated key-press is for the correct key? Ditto for VK_LSHIFT and VK_RSHIFT Perhaps this might improve the patch, however the internal modifier state of the xserver has only ShiftMask, LockMask, ControlMask, Mod1Mask, Mod2Mask, Mod3Mask, Mod4Mask, and Mod5Mask. So the internal state does not distinguish betweem left or right shift key. Hm... on looking at this again, isn't that code you are adding checking the internal state of non-latching modifiers bogus? If we release all keys on WM_KILLFOCUS, then the non-latching modifiers will always be clear when the WM_SETFOCUS occurs, so we will always generate the keypress for the modifier. (This is different to the existing code below for the latching modifiers, where we generate a keypress and release if necessary to toggle the state of the latching modifier in the X server to match the actual state) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: considering modifier keys after gaining focus
On 08/01/2012 15:23, Oliver Schmidt wrote:
On 8/16/2011 5:31 PM, Oliver Schmidt wrote:
I had the problem, that the state of the modifier keys was lost when a
window is created (or raised).
I send a patch to fix this problem with this email: I just extended the
I just merged the current official source from xorg-server-1.11.3-1 into
my local development source and discovered, that my patch for the
problem lost modifier key after a new window is created has not been
applied.
Is there a chance, that this patch could be applied to a future version
or that another solution could be provided to fix this problem? I'm also
attaching a newer version of the patch with this email.
Thanks very much for the updated patch, and for following up on this, and
apologies for overlooking it.
I have a few questions and comments below:
Example: in window A Ctrl + some key opens a window B, then in window B
Ctrl + some other key triggers the next action. However after the opening
of window B the Ctrl key has to be released and pressed again. If the user
keeps the Ctrl key holding when the window B is opened, the next key press
X will be interpreted as X and not as Ctrl+X.
Can you give an example of an application where this causes a problem, so I
can test your patch?
I send a patch to fix this problem with this email: I just extended the
function winRestoreModeKeyStates in winkeybd.c to consider not only the
mode switch key but also the modifiers Ctrl, Shift, Alt/AltGr by using the
Windows function GetAsyncKeyState.
After your patch, the X server is releasing all keys on WM_KILLFOCUS, then
pressing again some subset of them on WM_SETFOCUS.
The code would seem to end up simpler (which is an important consideration) if
we were to modify winKeybdReleaseKeys() not to release modifier keys. Some
archaeology is probably required to determine if releasing the modifier keys
in winKeybdReleaseKeys() is necessary to avoid some other undesirable behaviour?
This also begs the question why is it only necessary to press some some subset
of the down keys on WM_SETFOCUS? Does the X server behave correctly if a
non-modifier key is held down while focus moves from one X server window to
another, or from one X server window to a native window an back?
diff --git a/cygwin/hw/xwin/winkeybd.c b/cygwin/hw/xwin/winkeybd.c
index 278342f..a2ac4d0 100644
--- a/cygwin/hw/xwin/winkeybd.c
+++ b/cygwin/hw/xwin/winkeybd.c
@@ -283,6 +283,29 @@ winRestoreModeKeyStates (void)
* have a logical XOR operator, so we use a macro instead.
*/
+ {
+/* consider modifer keys */
+
+BOOL ctrl = (GetAsyncKeyState (VK_CONTROL) 0);
+BOOL shift = (GetAsyncKeyState (VK_SHIFT)0);
+BOOL alt= (GetAsyncKeyState (VK_LMENU)0);
+BOOL altgr = (GetAsyncKeyState (VK_RMENU)0);
Why is is correct to use GetAsyncKeyState() here and not GetKeyState()? If we
use GetAsyncKeyState() there may be a message pending (See the remarks on
GetKeyState() in MSDN) to change to the key state, so we might conceivably
double the key press?
+
+if (ctrl altgr) ctrl = FALSE;
+
+if (WIN_XOR (internalKeyStates ControlMask, ctrl))
+ winSendKeyEvent (KEY_LCtrl, ctrl);
This maps VK_CONTROL to KEY_LCtrl. Why not use VK_LCONTROL and VK_RCONTROL,
so the generated key-press is for the correct key?
+
+if (WIN_XOR (internalKeyStates ShiftMask, shift))
+ winSendKeyEvent (KEY_ShiftL, shift);
Ditto for VK_LSHIFT and VK_RSHIFT
+
+if (WIN_XOR (internalKeyStates Mod1Mask, alt))
+ winSendKeyEvent (KEY_Alt, alt);
+
+if (WIN_XOR (internalKeyStates Mod5Mask, altgr))
+ winSendKeyEvent (KEY_AltLang, altgr);
+ }
+
/* Has the key state changed? */
dwKeyState = GetKeyState (VK_NUMLOCK) 0x0001;
if (WIN_XOR (internalKeyStates NumLockMask, dwKeyState))
@@ -328,7 +351,7 @@ winIsFakeCtrl_L (UINT message, WPARAM wParam, LPARAM
lParam)
MSGmsgNext;
LONG lTime;
Bool fReturn;
-
+
static Bool lastWasControlL = FALSE;
static UINT lastMessage;
static LONG lastTime;
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ: http://x.cygwin.com/docs/faq/
Re: Built XWin on mingw - with patches
On 10/11/2011 16:50, Ryan Pavlik wrote: On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY wrote: 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch I am a bit unclear why this is needed, surely the winsock API predates XP? It might be better to add this define to CFLAGS rather than to start sprinkling it around source files as needed? Yes, but one of the calls in that file uses a part of the winsock API introduced in XP - getaddrinfo and freeaddrinfo. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12content-type=text/x-cvsweb-markupcvsroot=src In my build testing, this only seems to be a problem if you explicitly ./configure the X server with --enable-ipv6, and in that case other build problems exist as well (No inet_pton/inet_ntop, inclusion of ws2tcpip.h is needed) (Ideally, if you were to ./configure with CFLAGS=-D_WIN32_WINNT=0x0501, IPv6 should be auto-detected by ./configure and build successfully. But this auto-detection doesn't work, because AC_CHECK_FUNC(getaddrinfo) fails because the test program generated doesn't prototype getaddrinfo, so it doesn't look for it with stdcall mangling...) So it seems there are a couple of generic problems here, so I'm not sure fixing it like this is the right thing to do. 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch Interesting. It would probably be useful to quote the language from the appropriate standard which describes the behavior of realloc() in this error case in the comment. I don't think this change is fully correct however. If the realloc'ed size is 0, realloc() may return NULL, but the previously allocated memory has been freed. Perhaps you need to check if errno has been set by realloc to distinguish these two cases? Did you notice this by inspection or actually have a problem caused by this code? Have you audited the rest of the xserver code for this class of error? Good point. I found this with cppcheck - a static analysis tool that, despite its name, is useful for C code as well. There were other issues it mentioned in the xserver code, but I didn't get to any of the others yet. In any case, it's a completely orthogonal patch. Might be useful for someone more familiar with the code to run cppcheck and address the issues. Since it's outside my area of expertise to do a good review, I'd suggest you post this patch (when you have it in a correct form) directly to xorg-devel. 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch Use whitespace consistently with the context, please Oops - will correct. Looking at this again, I'm a bit puzzled by the comment Fixes having to pass this flag for a successful MinGW build I can understand adding MinGW to the set of targets which don't have setuid binaries, but I'm not sure how the MinGW build can fail if this flag isn't supplied: INSTALL_SETUID appears to only apply to installing the Xorg DDX. Is the real bug here that the test immediately below this assumes that we are not cross-compiling? Should the test check for cross-compiling and assume setuid binaries are possible unless it's on the list of excluded targets? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Why doesn't M-C-s work for me?
On 09/01/2012 18:32, Mark Geary wrote: left Alt-left Ctrl-s (will abbreviate as M-C-s from here-on) does nothing for me. Does anyone have any thoughts on why it might not be working? This seems to work correctly for me: KeyPress event, serial 27, synthetic NO, window 0x101, root 0x206, subw 0x0, time 22102718, (105,96), root:(2137,224), state 0x1c, keycode 39 (keysym 0x73, s), same_screen YES, XLookupString gives 1 bytes: (13) XmbLookupString gives 1 bytes: (13) XFilterEvent returns: False It might be the case that M-C-s has been made a Windows shell shortcut key, in which case the Windows shell will process it before X server gets a chance to see it. You might wish to try the -keyhook X server option to see if that changes anything. I have the left control and the caps lock keys swapped with a registry edit: [HKEY_CURRENT_USER\Keyboard Layout] Scancode Map=hex:00,00,00,00,00,00,00,00,03,00,00,00,1d,00,3a,00,3a,00,1d,00,00,00,00,00 You might want to try with that reverted, both to eliminate it and possible mechanical limitations of your keyboard's caps lock key as a cause. Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.5.3.0 (20090222) I know this is the last X server release for Cygwin 1.5, but it is quite old now. While I can't think of any change made which might fix this, I can't rule that out. If this is a bug in the X server, a fixed X server will only be made available for Cygwin 1.7 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
