Re: Xserver corresponds to display :1.0 instead of :0.0
At 2015-10-16 07:41, paul was heard to say: I have a very simple ~/.startxwinrc: xrdb -load $HOME/.Xresources xterm -display :0.0 # xterm & exec sleep infinity Recently, I found that the xterm wasn't launching. I googled, read some cygwin threads about X authorities, but have to admit, I have a lot to learn about X windows. Anyway, since I could open an xterm by right clicking on the Cygwin/Xserver:1.0 app in the notification area of Windows 7, I sneakily (OK, it wasn't the craftiest thing in the world) echo'd $DISPLAY. Lo, it was 1.0, and the following works fine: xterm -display :1.0 & Yes, I know it says 1.0 in the tip for the Cygwin/Xserver:1.0 app, but I didn't actually look at that detail until now, as I'm posting. A google for the following doesn't turn up anything: cygwin xterm "-display :0.0" "display :1.0" I'm wondering if this was a planned change in how X-windows works or if something is awry with my setup, causing a server with display :0.0 to fail, and making go to :1.0. I did a browse of the cygin announce list on gmane (since the X-windows announce list is now obsolete), but no joy. And I would have expected anything to show up in my google search. Can anyone point me to the description of this change? If it is not a deliberate change, what would be a good approach to troubleshoot it? I have a file ~/.xsession-errors, but it is dated 2015-09-16, and I've used X-windows plenty since then. Hi, you may have a leftover lock file from a crashed X session. Check if there is a /tmp/.X0-lock (IIRC) before you start your X server. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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/
fontconfig warning after recent upgrade
Hi, I usually start X sessions from mintty using commands like: startxwin /usr/bin/emacs somefile.txt After I upgraded my Cygwin installation yesterday, the following message pops up in mintty while Emacs starts up and whenever Emacs loads additional fonts: Fontconfig warning: ignoring C.UTF-8: not a valid language tag This doesn't hurt but it is a bit annoying as it sometimes screws up things which I need to copy and paste from the terminal. I used to have the following settings in my .bashrc in order to get English console messages: LC_ALL=C.UTF-8 export LC_ALL If I change that to e.g. en_US.UTF-8, fontconfig no longer complains. Is this behaviour intended? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: startxwin/XWin won't start properly
"Bradley, Mike" was heard to say: I don't see any difference if I set DISPLAY to :0.0 or 127.0.0.1:0.0. However, in the past its only worked if I set to 127.0.0.1:0.0 My current procedure to start X is as follows: 1. do not set $DISPLAY anywhere. It is just empty. 2. open MinTTY 3. type something like "startxwin /usr/bin/emacs" That's about it. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: startxwin/XWin won't start properly
"Bradley, Mike" was heard to say: Notice the value of $DISPLAY above, which does not match whats in XWin.0.log (it has :0.0). No idea how/why that happens. $DISPLAY is empty over here unless I manually set it. But then, I'm not sure if it has something to do with your problems, as 127.0.0.1:0.0 points to the first display on localhost, which IMHO isn't all that wrong. What happens if you set $DISPLAY manually, e.g. to ":0.0". This always worked fine for me. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
Ken Brown writes: > That's because /usr/bin/emacs is a symlink. Try straceing emacs-X11. > Who'd have thunk? Thanks, that's going to make it easier then. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
Dan Tsafrir was heard to say: The two numbers at the beginning of each strace output line (like the ones you quoted above) answer this question. I believe the first number is elapsed microseconds since the previous line and the second number is elapsed microseconds since the beginning of the run. If this is correct then the block above takes about 8ms. Note, however, that the strace log of xclock's startup is comprised of 414,669 lines, a fact that coincides with the several minutes it has taken the straced xclock to open. Oh, I see. I never could make sense of those numbers. I've noticed that the problem is not 100% reproducible here. I've tried this quite often today, restarted the X server, tried again and so on. Sometimes xterm starts up fairly quick, but more often than not it starts up with a huge delay. Also, I've noticed that writing a log to a file with "strace -o file xterm", or even with "strace xterm|tee file" does not correctly show the kind of delay I was talking about. The following snippet is copied+pasted from MinTTY after running "strace xterm": 7551448 12884434 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 59 12884493 [main] xterm 3524 readv: no need to call ready_for_read 211 12884704 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 45 12884749 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 8089730 20974479 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 57 20974536 [main] xterm 3524 readv: no need to call ready_for_read 213 20974749 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 43 20974792 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 7699688 28674480 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 62 28674542 [main] xterm 3524 readv: no need to call ready_for_read 221 28674763 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 45 28674808 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 7870040 36544848 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 54 36544902 [main] xterm 3524 readv: no need to call ready_for_read 195 36545097 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 42 36545139 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 7927224 44472363 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 57 44472420 [main] xterm 3524 readv: no need to call ready_for_read 216 44472636 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 40 44472676 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 7598403 52071079 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 55 52071134 [main] xterm 3524 readv: no need to call ready_for_read 209 52071343 [main] xterm 3524 fhandler_base::read: returning 65536, binary mode 43 52071386 [main] xterm 3524 readv: 65536 = readv (5, 0x2295C4, 1), errno 2 8083403 60154789 [main] xterm 3524 readv: readv (5, 0x2295C4, 1) blocking, sigcatchers 0 57 60154846 [main] xterm 3524 readv: no need to call ready_for_read 178 60155024 [main] xterm 3524 fhandler_base::read: returning 51051, binary mode 47 60155071 [main] xterm 3524 readv: 51051 = readv (5, 0x2295C4, 1), errno 2 Please note the readv calls, some of which take around 7-8 seconds. I have no idea why those numbers don't show up in logs written directly to a file, as the overall startup time appears to be similar in both cases. Anyway, we may be looking at unrelated problems. If you can't see readv calls with excessive times while watching the strace output, this may not be the cause of your problem. OTOH searching for "open" in your and my logs returns 62744 and 381 counts, respectively. This is more likely to cause the kind of delay you see. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
Dan Tsafrir was heard to say: I wasn't able to strace emacs, but I am able to strace xclock (brining it up, which when strace-ing takes several long minutes on my netbook, and then immediately killing it). Neither was I. I always get this error (the error number is variable though): strace: error creating process emacs, (error 2) I've had a look at your strace log. I've noticed the same block of statements which seems to be repeated over and over again (see my previous post). Did you watch the strace output on the console in real time to verify that this is where the process spends most of its time? 3139 16066368 [main] xclock 5708 readv: readv (4, 0x22A6D4, 1) blocking, sigcatchers 0 1765 16068133 [main] xclock 5708 readv: no need to call ready_for_read 1487 16069620 [main] xclock 5708 fhandler_base::read: returning 1024, binary mode 1531 16071151 [main] xclock 5708 readv: 1024 = readv (4, 0x22A6D4, 1), errno 2 This is where I have seen xterm to spend most of its time. In your log, this block of statements appears to be repeated several times for each font it checks in /etc/fonts. This would explain why it is related somehow to fonts in your case. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: emacs-x11 takes 30-40 sec to open after upgrading to cygwin-1.7
Jon TURNEY was heard to say: So far it seems that (1) emacs takes a long time to start up (2) xterm starts up quickly. Are there other X applications that you use and how do they behave? I've followed this thread with interest, but so far I thought I'm not affected. I usually start emacs along with the xserver by typing "startxwin /usr/bin/emacs" in the MinTTY console. This works without problems. Also, starting Emacs from the right-click menu of the X server in the system tray works fine. However, I've never noticed that starting emacs from MinTTY into a running X session actually takes quite some time. That is, I can confirm this part of the OP's problem. What I cannot confirm is that xterm works ok. xterm runs ok from the X server right-click menu. It shows the same start-up delay when started from MinTTY as emacs. Interesting, but not necessarily related to the problem is the fact that in both cases different bash startup files seem to be evaluated. When starting from MinTTY (and waiting...), I get my customized bash prompt, whereas I get a default "bash-3.2$" prompt when starting from the right-click menu. BTW I don't have a ~/.fontconfig directory or an ~/Xdefaults file, so these are probably not related to the problem. I used strace to see where xterm spends its start-up time, see the output below. I get several pages of the block of lines shown below. Each block takes a couple of seconds to finish, so this is where most of the time is wasted. Does this help to find out what's happening? regards, Markus 51 65525456 [main] xterm 3332 fhandler_base::open_fs: 1 = fhandler_disk_file::open (\??\C:\Programme\cygwin-1.7\var\run\utmp, 0x10002) 58 65525514 [main] xterm 3332 open: 4 = open (/var/run/utmp, 0x10002) 58 65525572 [main] xterm 3332 readv: readv (4, 0x22BCF4, 1) blocking, sigcatchers 0 1137 65526709 [main] xterm 3332 readv: no need to call ready_for_read 74 65526783 [main] xterm 3332 fhandler_base::read: returning 308, binary mode 35 65526818 [main] xterm 3332 readv: 308 = readv (4, 0x22BCF4, 1), errno 0 -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
Ken Brown writes: > Does your CYGWIN environment variable contain tty? > > http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-startxwin-no-windows > administra...@pc51997 ~ $ echo $CYGWIN server Which, in fact, is a leftover of 1.5. But no, there is no tty here. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
Ken Brown writes: > Does your CYGWIN environment variable contain tty? > > http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-startxwin-no-windows > Thanks for the hint. Will check on Monday. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
Jon TURNEY writes: > Google suggests '4.90.2.20040617' is a novell netware client version. > Good catch. I use a Windoze client on a Netware network at work, so this client is likely to be installed. But then, why would xterm try to run that client??? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
Markus Hoenicka mumbled: As this method to start xterm seems to work, do I have to start the X server some other way than I do now? I just use the Win start menu entry Cygwin-X->XWin Server. I can answer that one myself. Running startxwin from mintty works without a hitch. This is no big deal for me, but this still leaves me wondering why one of the officially recommended ways to start X (as per the docs, see http://x.cygwin.com/docs/ug/using.html#using-starting) fails on my system. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
"Larry Hall (Cygwin X)" was heard to say: For the mintty test case, yes, you need to set DISPLAY. Use this: export DISPLAY=:0.0 Yep, that works, except for the following warning: Warning: Missing charsets in String to FontSet conversion As this method to start xterm seems to work, do I have to start the X server some other way than I do now? I just use the Win start menu entry Cygwin-X->XWin Server. thanks Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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: problems starting xterm
Reid Thompson was heard to say: what happens when you call xterm from the mintty command line? $ xterm Xt error: Can't open display: xterm: DISPLAY is not set Do I have to set DISPLAY manually? And if yes, what should it read? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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/
problems starting xterm
Hi, I've set up Cygwin 1.7.1 lately, along with X and some applications. The X server works ok and claims to be "Version 1.7.5 Build Date: 2010-02-05". I can run Emacs as an X application without hassles. However, when I start the X server, or when I try to run xterm from the X server systray icon, xterm apparently fails to find a shell to run, so it terminates (no pun intended) after a couple of seconds: xterm: Could not exec 4.90.2.20040617: No such file or directory I have plenty of shells installed (bash, ash, dash), and they work ok in MinTTY. I'm afraid I'm missing some simple but important setting somewhere. Any ideas? regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 -- 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/
