WM_QUIT problem (was "twm issue ...")
Since nobody has responded at all, I thought I would try again, a different way ... This is a case where what I believe is normal termination of a window manager (in my case twm) is causing a seg fault in XWin, at least that's what the attached log seems to say. The odd thing is that this happens when I exit twm by typing control-shift-q, where I have the following twm declaration: "q" = s | c : all : f.quit But I also have a menu with an f.quit item, and when I exit that way, I do not get the seg fault (second attached log). I suppose this is not a huge deal, since I am exiting everything anyway, but a seg fault is kind of scary to a user of an important thing like X :-) ... Best wishes -- Eliot Moss Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -auth /home/Eliot/.serverauth.5240 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 800 winInitializeDefaultScreens - Returning 2009-11-12 06:56:49 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-12 06:56:49 (II) xorg.conf is not supported 2009-11-12 06:56:49 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-12 06:56:49 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2009-11-12 06:56:49 LoadPreferences: Done parsing the configuration file... 2009-11-12 06:56:49 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:56:49 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-12 06:56:49 winDetectSupportedEngines - DirectDraw installed 2009-11-12 06:56:49 winDetectSupportedEngines - DirectDraw4 installed 2009-11-12 06:56:49 winDetectSupportedEngines - Returning, supported engines 0007 2009-11-12 06:56:49 winSetEngine - Using Shadow DirectDraw NonLocking 2009-11-12 06:56:49 winAdjustVideoModeShadowDDNL - Using Windows display depth of 32 bits per pixel 2009-11-12 06:56:49 winFinishScreenInitFB - Masks: 00ff ff00 00ff 2009-11-12 06:56:49 Screen 0 added at XINERAMA coordinate (0,0). 2009-11-12 06:56:49 MIT-SHM extension disabled due to lack of kernel support 2009-11-12 06:56:49 XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel 2009-11-12 06:56:49 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so 2009-11-12 06:56:49 (II) GLX: Initialized DRISWRAST GL provider for screen 0 2009-11-12 06:56:49 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! 2009-11-12 06:56:49 winPointerWarpCursor - Discarding first warp: 640 400 2009-11-12 06:56:49 (--) 8 mouse buttons found 2009-11-12 06:56:49 (--) Setting autorepeat to delay=500, rate=31 2009-11-12 06:56:49 (--) winConfigKeyboard - Layout: "0409" (0409) 2009-11-12 06:56:49 (--) Using preset keyboard for "English (USA)" (409), type "4" 2009-11-12 06:56:49 Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" 2009-11-12 06:56:50 winProcEstablishConnection - Hello 2009-11-12 06:56:50 winInitClipboard () 2009-11-12 06:56:50 winClipboardProc - Hello 2009-11-12 06:56:50 DetectUnicodeSupport - Windows NT/2000/XP 2009-11-12 06:56:50 winProcEstablishConnection - winInitClipboard returned. 2009-11-12 06:56:50 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:56:50 winClipboardProc - DISPLAY=:0.0 2009-11-12 06:56:50 winClipboardProc - XOpenDisplay () returned and successfully opened the display. 2009-11-12 06:56:50 winClipboardFlushXEvents - unexpected event type 34 2009-11-12 06:57:09 winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop. 2009-11-12 06:57:09 winClipboardProc - XDestroyWindow succeeded. 2009-11-12 06:57:09 Segmentation fault at address 0x268 2009-11-12 06:57:09 Fatal server error: 2009-11-12 06:57:09 Caught signal 11 (Segmentation fault). Server aborting 2009-11-12 06:57:09 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.7.1.0 (10701000) Build Date: 2009-11-04 Contact: cygwin-xfree@cygwin.com XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -auth /home/Eliot/.serverauth.8996 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 800 winInitializeDefaultScreens - Returning 2009-11-12 06:55:42 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 2009-11-12 06:55:42 (II) xorg.conf is not supported 2009-11-12 06:55:42 (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information 2009-11-12 06:55:42 winPrefsLoadPreferences: /etc/X11/system.XWinrc 2009-11-12 06:55:42 LoadPreferences: Done parsing the configuration file... 2009-11-12 06:55:42 winGetDisplay: DISPLAY=:0.0 2009-11-12 06:55:42 winDetectSupportedEngines - Windows NT/2000/XP 2009-11-12 06:55:42 winDetectSupportedEngines - DirectDraw installed 2009-11
Re: building issue
On 07/11/2009 01:10, Cesar Strauss wrote: Jon TURNEY wrote: I think I've finally found out why these "Permission denied" errors occur. It seems to be caused by the XWin.exe.manifest file we store in the same directory (it's not shipped as it's embedded into the final executable using the resource compiler) Presumably the manifest is incompatible with the libtool wrapper executable in some way and we get this unhelpful error message. Please try setting the execute bit (chmod +x) on the manifest file. See also: Libtool: Generated manifests need execute permission http://article.gmane.org/gmane.os.cygwin/110870 You are absolutely right, setting the execute bit on the manifest file fixes this. Thanks! -- 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 1.7.0-63 problems with X programs
On 08/11/2009 14:11, Eliot Moss wrote: Corinna Vinschen wrote: On Nov 7 09:27, Eliot Moss wrote: Like another user, I had difficulty getting X to fire up. After setting LANG=en_US.UTF-8 I got farther, but these issues remain: Each xterm, xemacs, and xclock I start outputs this: Warning: Missing charsets in String to FontSet conversion I also get a series of: twm: warning: font for charset XXX is lacking. Where XXX is replaced by each of these in turn: JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 Those three lines repeat 6 times. Now we are in a UTF-8 locale, it seems that Xlib tries rather excessively hard (see [1]) to find some CJK fonts, presumably just in case we try to output some characters they might provide. I think this also causes the noticably slower startup of applications, as they repeatedly search for fonts with these missing CJK encodings. The workaround is too install the font-isas-misc, font-jis-misc and font-daewoo-misc packages to provide fonts with these encodings. I'm not sure if there is a better solution than that. [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/modules/om/generic/omGeneric.c, line 845 Also: 1) the whole deal takes noticeably longer to start 2) xemacs does not receive its normal geometry from .Xdefaults If you could provide a specific example of a setting you are making in .Xdefaults and how you know it's not being used 3) each xterm started from .xinitrc has a blank line before the initial bash prompt, that wasn't present before Well spotted. In fact this seems to affect all Xterms, but I had completely failed to notice this. Are you absolutely sure it was updating to cygwin 1.7.0-63 which introduces this, and not an Xserver/Xlib/xterm update? I can reproduce that, but I can't make any sense of it. What on earth does that have to do with setting LANG to "en_US.UTF-8"?!? I'll redirect this to the cygwin-xfree list. Thanks for the redirect, Corinna. I can report a bit more ... - Adding the locale lines for C.UTF-8 into locale.dir and compose.dir do work to get X to start for me. (These are the patches discussed in the "X11R7.5 and C.UTF-8" thread on cygwin-xfree.) - The other problems go away if I set LANG=C, so it's definitely something about the locale. Am I unusual in using twm :-) ? Yes, but not in a good way :-) Anyway, for now I am using LANG=C, set in the Windows environment variables, but once there are patches or updates to test, I am happy to try them ... -- 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: Option to disable PRIMARY clipboard
On 09/11/2009 16:48, Corentin Chary wrote: Is there a way to disable the PRIMARY clipboard ? Would a patch like that http://sourceware.org/ml/cygwin-xfree/2003-06/msg00148.html (with a command line option) be accepted ? It's far more likely to be accepted if you say what problem you are trying to solve and why a patch like that is the right solution. -- 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: Option to disable PRIMARY clipboard
On Thu, Nov 12, 2009 at 2:53 PM, Jon TURNEY wrote: > On 09/11/2009 16:48, Corentin Chary wrote: >> >> Is there a way to disable the PRIMARY clipboard ? >> Would a patch like that >> http://sourceware.org/ml/cygwin-xfree/2003-06/msg00148.html (with a >> command line option) be accepted ? > > It's far more likely to be accepted if you say what problem you are trying > to solve and why a patch like that is the right solution. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer > We use nx to display X application hosted on a Linux servers. Clients could be on Linux, Windows or MacOS. The PRIMARY clipboard really confuse windows (and MacOS) users. An option (XWin.exe -no-primary-clipboard) would really be great for that. -- Corentin Chary http://xf.iksaif.net -- 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 1.7.0-63 problems with X programs
Thanks, Jon! Installing the three font collections you suggested seems to have solved all THREE of the problems I mentioned. I can only guess that somehow the font/locale issues prevented some .Xdefault information from being loaded or used properly, but I attach the .Xdefaults file anyway. The way I know it's not being used is that my .xinitrc has the following for strting xemacs, i.e., no override of the default, and the window definitely came up a different shape without the isas, jis, and deawoo fonts installed. xemacs -T xemacs -iconname xemacs -iconic & In any case, I guess that as we move into cygwin 1.7 we'll save a lot of blood, sweat, and tears if we point out the need to install these fonts. In any case, now LANG=C.UTF-8 works well, as does LANG=en_US.UTF-8! Best wishes -- Eliot -- 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: Can't read lock file
On 11/11/2009 07:40, Fergus wrote: I have made no alterations/ patches/ amendments and have a completely current [1.7] system. For all of cygwin1.7.61.dll - cygwin1.7.64.dll the command run XWin fails with a reference to /vat/log/XWin.0.log which reads Can't read lock file /tmp/.X0.lock But when reverting to cygwin1.7.60.dll everything goes ahead smoothly and correctly and I can start a X terminal etc. Q1. Is it still the case that this problem is "not well understood" as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Perhaps this FAQ needs a bit of clarification. Creating the lockfile will fail if /tmp is on a FAT32 filesystem, for the reasons outlined in Corinna's email. (although I guess this may have behaved differently in some 1.7.x beta version if you haven't seen it there) For reasons which I don't currently understand, creating the lockfile also reportedly fails sometimes for people who have /tmp on a NTFS filesystem. If you can contribute some information which might help in solving this problem, please do so at [1] [1] http://sourceware.org/bugzilla/show_bug.cgi?id=9778 Q2. Is there anything obvious in the progression from cygwin1.7.60.dll to cygwin1.7.61.dll that might explain why the start command run XWin works with 1.7.60 and fails with 1.7.61? Finally Q3. Confession: I am completely confused by all recent posts about LANG, locale and all the rest. Are fiddling with LANG or applying patches such as described at http://cygwin.com/ml/cygwin-xfree/2009-11/msg00071.html fixes intended to address problems starting XWin? If you are not setting LANG (or are setting it to C.UTF-8) and have xorg-server-1.7.1-2, you will probably experience random crashes in multiwindow mode) Until there is a new libX11 release, if you are experiencing such crashes, applying that patch in that email OR setting LANG to something more sensible (e.g. en_GB.UTF-8) should resolve that problem. Thank you. Fergus PS Not quite "finally". Can I please ask a 4th question: Q4 Why are questions about X specifically directed to a different mailing list? Apart from occasional high-frequency dialogue as at present, posts about X are (or seem to me to be) no more frequent than posts about grep or ls or chmod or ... . The "main" Cygwin list has a much higher readership and posts directed there might generate many useful hints, tips, experiences, fixes or even solutions? I am lazy and don't read the main list :-) -- 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: Can't read lock file
On 11/11/2009 10:07, Corinna Vinschen wrote: On Nov 11 07:40, Fergus wrote: Q1. Is it still the case that this problem is "not well understood" as in this reference? http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-cant-read-lock-file Hardlinks don't work on FAT filesystems since FAT doesn't support them. Up to Cygwin 1.7.0-60, hardlinks on FAT were faked by copying the file. This has obvious downsides (unsecure, potential denial-of-service problems, portability), so we discussed and decided to remove this fake and to return an error instead when trying to create a hardlink on a FAT FS: http://cygwin.com/ml/cygwin/2009-09/msg00208.html (My experiments with possible cause/ cure are confounded because on Machine 1 I have NTFS filesystems but lack administrator rights and on Machine 2 where I am Administrator, all filesystems are FAT32.) Which is bad since FAT32 has no security at all. Any process of any user on the machine can overwrite any file, even in the Windows folder. NTFS is much more secure and has a couple of features you never get with FAT32, and hardlinks are only one minor advantage. You should really update the filesystem to NTFS using the on-board convert.exe tool. As for X, it should have a fallback method if the /tmp filesystem doesn't support hardlinks. Well, the fallback method is to use -nolock :-) The only use of the lock file appears to be to stop people from doing things like starting 'X :0 -nolisten inet -nolisten inet6' and 'X :0 -nolisten unix' at the same time, so I'm kind of tempted just to make '-nolock' the default and let people run with scissors if they want to :-) However, since there does seem to be some code to grovel over the mount options to try to detect if /tmp is textmode and warn about that for some reason, perhaps I'll look at checking if it's FAT and turning off the lockfile automatically in that case. -- 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] [1.7] Updated: xorg-server-1.7.1-3
The following package has been updated for Cygwin 1.7: * xorg-server-1.7.1-3 This package contains XWin and the other X.Org X11 servers. The following patches has been added in this release: - Don't crash if conversion of window name to UTF-8 fails. - Discourage other window managers from starting when in multiwindow mode. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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] [1.7] Updated: libX11-1.3.2-2
The following packages have been updated for Cygwin 1.7: * libX11_6-1.3.2-2 * libX11-devel-1.3.2-2 * libX11-xcb1-1.3.2-2 * libX11-xcb-devel-1.3.2-2 libX11, aka Xlib, is the core library of the X11 protocol. This release adds support for the C.UTF-8 locale. Yaakov Cygwin/X CYGWIN-XFREE-ANNOUNCE UNSUBSCRIBE INFO == If you want to unsubscribe from the cygwin-xfree-announce mailing list, please use the automated form at: http://cygwin.com/lists.html#subscribe-unsubscribe If this does not work, then look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-xfree-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- 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: Can't read lock file
On 11/12/2009 01:16 PM, Jon TURNEY wrote: The only use of the lock file appears to be to stop people from doing things like starting 'X :0 -nolisten inet -nolisten inet6' and 'X :0 -nolisten unix' at the same time, so I'm kind of tempted just to make '-nolock' the default and let people run with scissors if they want to :-) Where can I get these scissors you speak of? They sound especially fun to run with. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- 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 & Paste problem between X windows
Hi, I am having trouble with pasting text into xterm windows, in cygwin1.7. The problem I'm having seems like the same one recently reported in this thread 'Cut & Paste problem between X windows'. However, I am using a microsoft mouse (the problem in that thread was with a logitech mouse). I was wondering if anybody else is seeing the problem with a microsoft mouse, and whether there is a workaround/fix. I installed cygwin1.7 yesterday (in place of 1.5 which I had been using). Basically, I can select text in an xterm using mouse buttons 1 and 3, but cannot paste using button 2. Clicking with button 2 has no effect. In general, cygwinx is recognizing mouse button 2, as I can use it for other things in other X clients without any problems. Also, I've tried xev, and can see the ButtonPress and ButtonRelease events for button 2. I tried installing the microsoft intellipoint software, and in it, I set the action for button 2 to 'Middle Click'. This seemed equivalent to what was suggested previously for the logitech mouse, using the logitech 'setpoint' software. But this didn't seem to have any effect. One other issue, not sure if this is related, but when I select text in an xterm, I cannot paste it in windows. It seems like the selection is not being shared between cygwinx and windows, like it was with cygwin1.5. I am starting Xwin.exe with the -clipboard option, just as I was with cygwin1.5, but selection sharing just doesn't seem to work. Anybody have any ideas about these problems? Thanks! -Dave Levi dbl...@comcast.net -- 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: 'run xterm' fails to open a window
On 10/11/2009 23:44, Mike Ayers wrote: On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap> gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap> (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mike>C:\cygwin\bin\run.exe -p /usr/bin sh -c "gvim>/dev/null 2>&1" C:\mike> [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Also, the suggestions that this has something to do with DISPLAY not being set correctly seem a little unlikely. If gvim or any other X application isn't able to determine which display to use, it should exit with an error, not hang around -- 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 & Paste problem between X windows
Hi, I just discovered that setting "LANG=en_US.UTF-8" in my environment solved the problem with pasting into an xterm. Not exactly sure why this fixed that problem, anybody know? I still have the problem with clipboard sharing between windows and cygwinx, though. Could this also be related to the LANG environment variable? Is there some other value other than en_US.UTF-8 required to get it to work? -Dave Levi dbl...@comcast.net - Original Message - From: dbl...@comcast.net To: cygwin-xfree@cygwin.com Sent: Thursday, November 12, 2009 3:11:22 PM GMT -05:00 US/Canada Eastern Subject: Re: Cut & Paste problem between X windows Hi, I am having trouble with pasting text into xterm windows, in cygwin1.7. The problem I'm having seems like the same one recently reported in this thread 'Cut & Paste problem between X windows'. However, I am using a microsoft mouse (the problem in that thread was with a logitech mouse). I was wondering if anybody else is seeing the problem with a microsoft mouse, and whether there is a workaround/fix. I installed cygwin1.7 yesterday (in place of 1.5 which I had been using). Basically, I can select text in an xterm using mouse buttons 1 and 3, but cannot paste using button 2. Clicking with button 2 has no effect. In general, cygwinx is recognizing mouse button 2, as I can use it for other things in other X clients without any problems. Also, I've tried xev, and can see the ButtonPress and ButtonRelease events for button 2. I tried installing the microsoft intellipoint software, and in it, I set the action for button 2 to 'Middle Click'. This seemed equivalent to what was suggested previously for the logitech mouse, using the logitech 'setpoint' software. But this didn't seem to have any effect. One other issue, not sure if this is related, but when I select text in an xterm, I cannot paste it in windows. It seems like the selection is not being shared between cygwinx and windows, like it was with cygwin1.5. I am starting Xwin.exe with the -clipboard option, just as I was with cygwin1.5, but selection sharing just doesn't seem to work. Anybody have any ideas about these problems? Thanks! -Dave Levi dbl...@comcast.net -- 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: 'run xterm' fails to open a window
> From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- > ow...@cygwin.com] On Behalf Of Jon TURNEY > Wait, are you saying that the process that run starts is blocked if it > tries > to output anything? That is what I am experiencing. > Also, the suggestions that this has something to do with DISPLAY not > being set > correctly seem a little unlikely. If gvim or any other X application > isn't > able to determine which display to use, it should exit with an error, > not hang > around I agree. I think DISPLAY is a red herring. Not having the display set can cause programs which exit without output, not hang around. HTH, Mike
Re: Cut & Paste problem between X windows
dbl...@comcast.net wrote: Hi, I just discovered that setting "LANG=en_US.UTF-8" in my environment solved the problem with pasting into an xterm. Not exactly sure why this fixed that problem, anybody know? I still have the problem with clipboard sharing between windows and cygwinx, though. Could this also be related to the LANG environment variable? Is there some other value other than en_US.UTF-8 required to get it to work? -Dave Levi dbl...@comcast.net Explicitly setting LANG=C (not C.UTF-8) enabled me to work around various X problems until enough other things were fixed. With the latest available X-org packages and the latest cygwin (released just in the last day or so) en_US.UTF-8 and C.UTF-8 started working for me *provided* I also installed several sets of fonts: font-daewoo-misc font-isas-misc font-jis-misc Apparently these were needed because X wants them around *in case* it needs their encodings -- but only demands them if LANG is set to a UTF-8 encoding (meaning: not in the LANG=C case). Cheers -- Eliot Moss -- 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 & Paste problem between X windows
Sounds weird, perhaps you've tried already but did you just highlight the word in the xterm (without clicking) to copy it and then (in some other place) press the middle (button 2) to paste it?I saw some friends having this little problem time ago. Sent from my iPod On Nov 12, 2009, at 3:11 PM, dbl...@comcast.net wrote: Hi, I am having trouble with pasting text into xterm windows, in cygwin1.7. The problem I'm having seems like the same one recently reported in this thread 'Cut & Paste problem between X windows'. However, I am using a microsoft mouse (the problem in that thread was with a logitech mouse). I was wondering if anybody else is seeing the problem with a microsoft mouse, and whether there is a workaround/fix. I installed cygwin1.7 yesterday (in place of 1.5 which I had been using). Basically, I can select text in an xterm using mouse buttons 1 and 3, but cannot paste using button 2. Clicking with button 2 has no effect. In general, cygwinx is recognizing mouse button 2, as I can use it for other things in other X clients without any problems. Also, I've tried xev, and can see the ButtonPress and ButtonRelease events for button 2. I tried installing the microsoft intellipoint software, and in it, I set the action for button 2 to 'Middle Click'. This seemed equivalent to what was suggested previously for the logitech mouse, using the logitech 'setpoint' software. But this didn't seem to have any effect. One other issue, not sure if this is related, but when I select text in an xterm, I cannot paste it in windows. It seems like the selection is not being shared between cygwinx and windows, like it was with cygwin1.5. I am starting Xwin.exe with the -clipboard option, just as I was with cygwin1.5, but selection sharing just doesn't seem to work. Anybody have any ideas about these problems? Thanks! -Dave Levi dbl...@comcast.net -- 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/ -- 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: checkX problems
On 30/10/2009 13:48, Ken Brown wrote: I'm having trouble with checkX. I haven't seen other people complain about this, so I assume it's something about my system, but I can't figure out what. There are two symptoms: 1. If I run checkX with a timeout, the timeout seems to be ignored. For example, with the X server *not* running: $ checkX -d 127.0.0.1:0.0 -t 100 --debug checkX.exe DEBUG: displayname : '127.0.0.1:0.0' checkX.exe DEBUG: opt_location: 0 checkX.exe DEBUG: opt_loglevel: 7 checkX.exe DEBUG: opt_nogui : 0 checkX.exe DEBUG: opt_notty : 0 checkX.exe DEBUG: opt_timeout : 100.00 checkX.exe DEBUG: (adjust_path) path is : /usr/local/texlive/2009/bin/i386-cygwin:/usr/local/bin:/usr/bin:/c/Program Files/ThinkPad/Utilities:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program Files/Intel/Wireless/Bin/:/c/Program Files/IBM ThinkVantage/Client Security Solution:/c/Program Files/ThinkPad/ConnectUtilities:/c/Program Files/QuickTime/QTSystem/:/c/Program Files/Common Files/Lenovo:/usr/lib/lapack:/usr/X11R6/bin:/usr/bin checkX.exe DEBUG: (find_X11_lib) DLL is /usr/bin/cygX11-6.dll checkX.exe DEBUG: (dlopen_X11_lib) /usr/bin/cygX11-6.dll dlopen'ed successfully. checkX.exe DEBUG: (load_X11_symbols) symbol XOpenDisplay loaded ok checkX.exe DEBUG: (load_X11_symbols) symbol XCloseDisplay loaded ok checkX.exe DEBUG: (try_with_timeout) Using delay of 100 secs, 0 nanosecs (100.00) checkX.exe DEBUG: (try_with_timeout) xserver search was unsuccessful checkX.exe Info: could not open X display '127.0.0.1:0.0' checkX.exe DEBUG: returning with status 1 checkX.exe Info: Exiting with status 1 The problem is that it returns within a second, in spite of the timeout. Or am I misunderstanding what the timeout is supposed to do? I think this is a misunderstanding here. Looking at the source, the timeout is the maximum time checkX will wait for an XOpenDisplay() to complete. If that fails immediately (e.g. due to with ECONNREFUSED), checkX will stop immediately. This is pretty reasonable. If there is nothing listening on the socket for the X server, that is not going to get better if we wait... ... except if the server happens to be starting up when we execute checkX. So, this is not quite what startxwin.bat requires, as the server may still be in the process of starting up. Fortunately, the X server binds it's socket pretty early in the startup, so this probably works pretty well, but in theory at least there is still a possible timing window in startxwin.bat. So it perhaps be useful if checkX retried the XOpenDisplay() periodically until the timeout was up (as xinit does) 2. If I start the X server by using the default startxwin.bat or startxwin.sh (both of which call checkX), the server is very unstable and crashes within a few minutes. This happens consistently, and it never happens if I comment out the line calling checkX. I think I was able to reproduce this problem (it is not how I normally start the X server) However, now I come back to look at this in detail, the problem no longer seems to exist. Are you still able to demonstrate it? I tried strace'ing checkX, but I don't know what to look for in the output. (I'll send it if it would be useful, but I don't want to spam the list otherwise.) I'm attaching cygcheck output. -- 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/
Cygwin/x window no longer appears
Hello! I have recently started to work with Cygwin/X. Until now, I have been starting Cygwin/X by using startxwin.bat in the Cygwin bash shell. Everything seemed to be working fine. However, it has now stopped working... When I type "startxwin.bat" in the Cygwin shell, the normal >startxwin.bat - starting on Windows NT/2000/XP/2003 appears. Yet, the window which used to appear no longer does. I am really not too sure what to do about this, given that I have not (consciously!) modified anything. I have installed Cygwin (and Cygwin/x) very recently, and have tried to reinstall the latter using Cygwin's setup.exe, but to no effect. Would anyone have any advice? Thank you! Olivia PS: I have attached cygcheck.out. -- 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 window no longer appears
Here is my cygcheck.out. Sorry about that! - Original Message > From: Olivia Cheronet > To: cygwin-xfree@cygwin.com > Sent: Thu, November 12, 2009 10:16:16 PM > Subject: Cygwin/x window no longer appears > > Hello! > > > I have recently started to work with Cygwin/X. > Until now, I have been starting Cygwin/X by using startxwin.bat in the Cygwin > bash shell. Everything seemed to be working fine. However, it has now stopped > working... > When I type "startxwin.bat" in the Cygwin shell, the normal > >startxwin.bat - starting on Windows NT/2000/XP/2003 > appears. Yet, the window which used to appear no longer does. I am really not > too sure what to do about this, given that I have not (consciously!) modified > anything. > I have installed Cygwin (and Cygwin/x) very recently, and have tried to > reinstall the latter using Cygwin's setup.exe, but to no effect. > > Would anyone have any advice? > > Thank you! > > Olivia > > PS: I have attached cygcheck.out. cygcheck.out Description: Binary data -- 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: checkX problems
Jon TURNEY wrote: [...] Fortunately, the X server binds it's socket pretty early in the startup, so this probably works pretty well, but in theory at least there is still a possible timing window in startxwin.bat. Yep, and in my setup the X server *always* comes up too late. So it perhaps be useful if checkX retried the XOpenDisplay() periodically until the timeout was up (as xinit does) In principle, the script calling checkX could do that, because ``checkX'' has return status 1 if it couldn't connect. But as I already pointed out (http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19529.html) ``startxwin.bat'' uses ``run'' as a wrapper for ``checkX''. => Definitely no waiting and no passing on of the status of ``checkX'' to %errorlevel%, as ``run'' immediately goes background (unless called from an xterm, dunno why). Since more people seem to have this problem (cf. also Olivia's post), I repeat my question (essentially already posed by Ken Brown: http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why using ``run'' at all? If we really need a wrapper (do we?) wouldn't ``sh'' be a better one? To push this even further: Do we really need two *independent* scripts, ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate to the latter? Asks Lothar -- 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 window no longer appears
> From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- > ow...@cygwin.com] On Behalf Of Olivia Cheronet > Sent: Thursday, November 12, 2009 2:16 PM > I have recently started to work with Cygwin/X. > Until now, I have been starting Cygwin/X by using startxwin.bat in the > Cygwin bash shell. Everything seemed to be working fine. However, it > has now stopped working... > When I type "startxwin.bat" in the Cygwin shell, the normal > >startxwin.bat - starting on Windows NT/2000/XP/2003 > appears. Yet, the window which used to appear no longer does. I am > really not too sure what to do about this, given that I have not > (consciously!) modified anything. > I have installed Cygwin (and Cygwin/x) very recently, and have tried to > reinstall the latter using Cygwin's setup.exe, but to no effect. Try this: http://www.cygwin.com/ml/cygwin-xfree/2009-11/msg00071.html or set your LOCALE to en_US.UTF-8. You may need to install CJK fonts if things work but are sluggish. HTH, Mike
Re: Cygwin/x window no longer appears
On 12/11/2009 23:04, Mike Ayers wrote: From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree- ow...@cygwin.com] On Behalf Of Olivia Cheronet Sent: Thursday, November 12, 2009 2:16 PM I have recently started to work with Cygwin/X. Until now, I have been starting Cygwin/X by using startxwin.bat in the Cygwin bash shell. Everything seemed to be working fine. However, it has now stopped working... When I type "startxwin.bat" in the Cygwin shell, the normal startxwin.bat - starting on Windows NT/2000/XP/2003 appears. Yet, the window which used to appear no longer does. I am really not too sure what to do about this, given that I have not (consciously!) modified anything. I have installed Cygwin (and Cygwin/x) very recently, and have tried to reinstall the latter using Cygwin's setup.exe, but to no effect. Try this: http://www.cygwin.com/ml/cygwin-xfree/2009-11/msg00071.html or set your LOCALE to en_US.UTF-8. You may need to install CJK fonts if things work but are sluggish. If you read the cygcheck output which Olivia kindly provided, you will see that she is running cygwin 1.5, with Xserver 1.5.3, so these recent breakages relating to Xserver 1.7.1 are unlikely to be the cause of her problems. -- 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 window no longer appears
> If you read the cygcheck output which Olivia kindly provided, you will > see > that she is running cygwin 1.5, with Xserver 1.5.3, so these recent > breakages > relating to Xserver 1.7.1 are unlikely to be the cause of her problems. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer DOH! Sorry about that, Mike
Re: checkX problems
On 12/11/2009 23:09, Lothar Brendel wrote: Jon TURNEY wrote: [...] Fortunately, the X server binds it's socket pretty early in the startup, so this probably works pretty well, but in theory at least there is still a possible timing window in startxwin.bat. Yep, and in my setup the X server *always* comes up too late. So it perhaps be useful if checkX retried the XOpenDisplay() periodically until the timeout was up (as xinit does) In principle, the script calling checkX could do that, because ``checkX'' has return status 1 if it couldn't connect. But as I already pointed out (http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19529.html) ``startxwin.bat'' uses ``run'' as a wrapper for ``checkX''. => Definitely no waiting and no passing on of the status of ``checkX'' to %errorlevel%, as ``run'' immediately goes background (unless called from an xterm, dunno why). But why would you fix the timeout problem by doing some horrible horrible iteration in the DOS batch script (horrible) (which would probably have to busy-wait (also horrible) as there's no sleep command), when you can fix checkX, which has the bonus of fixing other uses of it? Since more people seem to have this problem (cf. also Olivia's post), I repeat my question (essentially already posed by Ken Brown: http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why using ``run'' at all? If we really need a wrapper (do we?) wouldn't ``sh'' be a better one? I guess we use run for the reason run exists: to hide the console window, which otherwise would be shown? Perhaps if you look how startxwin.bat is started from the start menu shortcut, (as 'run startxwin.bat') you can see why this might be useful? To push this even further: Do we really need two *independent* scripts, ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate to the latter? Indeed. They are useless to me for starting the server and a continual source of problems. I would be quite happy to just delete them completely. :-) Looking forward to reading your patches to address any of these problems. -- 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: checkX problems
Jon TURNEY wrote: > But why would you fix the timeout problem by doing some horrible > horrible iteration in the DOS batch script (horrible) (which would > probably have to busy-wait (also horrible) as there's no sleep command), > when you can fix checkX, which has the bonus of fixing other uses of it? I actually wrote a version of this. It IS horrible -- but no need for a busywait, I used the "ping trick": C:\windows\system32\ping -n 2 127.0.0.1>nul "sleeps" for (n-1)==1 seconds. >> Since more people seem to have this problem (cf. also Olivia's post), I >> repeat my question (essentially already posed by Ken Brown: >> http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg19402.html): Why >> using ``run'' at all? If we really need a wrapper (do we?) wouldn't >> ``sh'' be a better one? > > I guess we use run for the reason run exists: to hide the console > window, which otherwise would be shown? But checkX is compiled as a GUI program, so it really shouldn't need "run" to hide its (non-existent) console: $ objdump -p /usr/bin/checkX.exe | grep ^Subsystem Subsystem 0002(Windows GUI) Now, in startxwin.bat, we actually use: %RUN% checkX -wait run.exe is peculiar. The first argument is the target, and IF the VERY NEXT argument is "-wait", run "usurps" that argument. That is, run will invoke: checkX and checkX will never see "-wait". So, what does run.exe do with "-wait"? It...waits. run.exe won't exit, until after the inferior does. So, if checkX takes 12 seconds to come back, then run will take 12 seconds ... and the entire script is paused until checkX exits. HOWEVER, since checkX is a GUI program, you SHOULD get the same result from both of these two commands: %RUN% checkX -wait checkX > Perhaps if you look how startxwin.bat is started from the start menu > shortcut, (as 'run startxwin.bat') you can see why this might be useful? > >> To push this even further: Do we really need two *independent* scripts, >> ``starxwin.bat'' and ``starxwin.sh''? Why can't the former just delegate >> to the latter? > > Indeed. They are useless to me for starting the server and a continual > source of problems. I would be quite happy to just delete them > completely. :-) Well, I think the OP is suggesting that one or the other go away, not both. However, what is /your/ preferred way of starting the Xserver from a shortcut, Jon? launching xinit via run? or do you always start the server from within an existing shell session? > Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it "retry" if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t . Just look at run2-0.3.0/lib/checkX.c::try_with_timeout(). Some function signatures might need to be changed in order to pass opt.retry down to that level, but it'd be a nice short project for someone. I'll try to get to this but it'll be a few weeks, unless somebody sends me a patch sooner. -- Chuck -- 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: checkX problems
On 11/12/2009 4:31 PM, Jon TURNEY wrote: On 30/10/2009 13:48, Ken Brown wrote: 2. If I start the X server by using the default startxwin.bat or startxwin.sh (both of which call checkX), the server is very unstable and crashes within a few minutes. This happens consistently, and it never happens if I comment out the line calling checkX. I think I was able to reproduce this problem (it is not how I normally start the X server) However, now I come back to look at this in detail, the problem no longer seems to exist. Are you still able to demonstrate it? Yes, it's still reproducible on one machine (the one for which I sent cygcheck output in my original post), but the problem doesn't occur on a second machine that I sometimes use. And I don't think anyone else has reported this problem. So I guess it must be BLODA or some other peculiarity of the one system. Ken -- 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: 'run xterm' fails to open a window
On 11/12/2009 3:17 PM, Jon TURNEY wrote: On 10/11/2009 23:44, Mike Ayers wrote: On Behalf Of jean-luc malet Sent: Monday, November 09, 2009 2:50 AM no more result... gvim process is still started, appears in ps -a, but nothing is displayed on screen, replacing gvim by xterm still work with this solution... To find out why this is, run gvim from an xterm: [SNIP] m-ayers-lap> gvim (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GSUB table 0x6EAD (gvim:1748): Pango-WARNING **: Error loading GPOS table 0x6EAD m-ayers-lap> (gvim:1092): Pango-WARNING **: Error loading GPOS table 0x6EAD [/SNIP] Apparently, run.exe is not providing stdout/stderr to dump to. The workaround: [SNIP] C:\mike>C:\cygwin\bin\run.exe -p /usr/bin sh -c "gvim>/dev/null 2>&1" C:\mike> [/SNIP] Wait, are you saying that the process that run starts is blocked if it tries to output anything? Ah, so this explains my xterm problem that started this thread. When I start xterm from a shell, I always get the message Warning: Missing charsets in String to FontSet conversion When I start xterm via run, this message apparently has nowhere to go and the xterm process is blocked. Mike's workaround (with 'gvim' replaced by 'xterm') solves the problem, as he said. Is this a bug in run? It would also be nice to get rid of that xterm warning. Setting LANG=C gets rid of it, so it seems to be another locale issue. Ken -- 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: checkX problems
Charles Wilson wrote: [...] run.exe is peculiar. The first argument is the target, and IF the VERY NEXT argument is "-wait", run "usurps" that argument. That is, run will invoke: checkX and checkX will never see "-wait". So, what does run.exe do with "-wait"? It...waits. run.exe won't exit, until after the inferior does. Could you please clarify an issue here? (Sorry, it seems, I wronged to ``run'' in the previous posts.) In a Windows command prompt (being somewhere on C:) I put the line \cygwin\bin\run -p /usr/bin sleep -wait 5 into a file ``dosleep.bat''. Executing that BAT-script (w/o any wrapper), it *does* sleep. Typing that very line directly at the prompt lets ``run'' return immediately, though. Can you confirm this behaviour? Looking forward to reading your patches to address any of these problems. It shouldn't be too hard to add an option to checkX to make it "retry" if ECONNREFUSED. This would have to manually track the elapsed time for each attempt, charging against the specified -t . Another possibility would be an option ``-n'' to specify the number of retries. Just look at run2-0.3.0/lib/checkX.c::try_with_timeout(). Some function signatures might need to be changed in order to pass opt.retry down to that level, but it'd be a nice short project for someone. I'll try to get to this but it'll be a few weeks, unless somebody sends me a patch sooner. I'd volunteer for that. How/where do I upload? Asks Lothar -- 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/
