Re: XTerm won't start on Win2000
I've fixed the problem by totally removing Cygwin and re-installing from scratch. So I guess there was some sort of problem with my previous download. I still have no idea what though. I'm a newbie to Cygwin X, and I can't open an XTerm. I've tried various options including startxwin.bat, startxwin.sh (from a Cygwin bash shell) and manually typing in commands from startxwin.sh. When running the bat file in dos, I get nothing - no error messages and no xterms. From bash, I still don't get xterms but I do get an error message: xterm Xt error: Can't open display: 127.0.0.1:0.0 I've tried reinstalling the whole of my Cygwin dist, just Xfree, fonts and zlib with absolutely no effect. I'm not using ssh and I have a colleague who should have an identical PC build who uses Xfree fine, so I know it's possible. There is no X log being created in /tmp. In fact, /tmp is empty. Having read other posts, I find this distinctly worrying. I'm running Win2000Professional and I've checked for suppressed pop-ups about missing dlls. There aren't any. Sorry not to provide more information but this is all I have! Any clues for where to find more logs, or (even better) a solution to my predicament would be greatly appreciated. Susannah
the procedure entry point_fcntl64 could not be located in the dynamic link libra
Hi.I take an error message:the procedure entry point_fcntl64 could not be located in the dynamic link library cygwin1.dll when i try to start XWin.exe or startx.exe or startxwin.bat. _ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
problem
Hi ! I was using Cygwin and Xfree86 until 1 or 2 weeks ago to run software in my department from home. Now suddenly when I open a shell and type startx it doesnt start XWin.exe any more. I just get anther bash with different colors. Before it used to open a window with X running in it aftrer which I could connect to my dept and run the software I need. Have you heard of this problem before ? Is it known or am I missing some change in the configurationfiles ? Thanks a lot, I would really like to keep using the program, because its great. Ciao, Michael
Re: problem
Now by default the multi-window mode is used: you don't have anymore a specific window for the X server. In this mode Windows Explorer is used as a Window Manager and you can see that X is running by looking at the X shaped icon in the tray. If you want X to start as it did before you must launch directly XWin without the -multiwindow options, or you can provide a .xserverrc file in your home directory (or the system wide configuration in /usr/X11R6/lib/X11/xinit/xserverrc). Ciao, Danilo Michael Nirschl wrote: Hi ! I was using Cygwin and Xfree86 until 1 or 2 weeks ago to run software in my department from home. Now suddenly when I open a shell and type startx it doesnt start XWin.exe any more. I just get anther bash with different colors. Before it used to open a window with X running in it aftrer which I could connect to my dept and run the software I need. Have you heard of this problem before ? Is it known or am I missing some change in the configurationfiles ? Thanks a lot, I would really like to keep using the program, because its great. Ciao, Michael -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 11 mesi 15 giorni 4 ore 41 minuti 40 secondi
Re: Russian Keymap
Alexander Gottwald said: David Snopek wrote: KeyPress event, serial 17, synthetic NO, window 0xc1, root 0x3a, subw 0x0, time 6207984, (442,250), root:(512,367), state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES, XLookupString gives 0 bytes: KeyRelease event, serial 22, synthetic NO, window 0xc1, root 0x3a, subw 0x0, time 6208109, (442,250), root:(512,367), state 0x10, keycode 41 (keysym 0x6c1, Cyrillic_a), same_screen YES, XLookupString gives 0 bytes: So it knows when I press #1072; that its the cyrillic a but the XLookupString returns as the represention? This worked for me (running linux): (taken from http://koi8.pp.ru/frame.html?/xwin.html) $ export LANG=ru_RU.KOI8-R $ xev Yes, I tried this on my Linux machine and it works perfectly. Unfortunately, it has no effect under Cygwin. Also, it causes gtypist to start with the deceptive error message: (null): i18n problem: invalid value for msgid Y/N: #1044;/#1053; And it prints the correct cyrillic characters for Deh and En! So, parts of it are atleast working. This whole thing is really, really irritating. I guess I will just use my linux machine for typing practice. Since Windows itself supports the proper keymap, I can get by. Thank you. -- David Snopek
Re: Possible clipboard hang fix in the works
Christopher Faylor wrote: On Wed, Mar 24, 2004 at 01:02:28AM -0500, Harold L Hunt II wrote: Upon a cursory inspection it should be almost trivial to replace the call to XPeekIfEvent with a simple loop that does the same thing but has a timeout value that prevents it from blocking indefinitely. Why can't you use select()? select() takes a timeout value. Because I won't actually be reading the pending events and processing them... so once I get woken up once I'll have one of two problems: 1) I'll continue to get woken for the same event. 2) I won't get woken for the same event (assuming it is the SelectionNotify event) when I call my function that processes all pending X events by calling select() in a loop. I should explain that in #1 we don't know (and can't expect) that the first event will be the SelectionNotify event. It will more often be the case that there are some events between when we first start waiting and when the SelectionNotify arrives. Harold
Re: the procedure entry point_fcntl64 could not be located in the dynamic link libra
You have one of two problems: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-procedure-entry-point-missing http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-status-access-violation Harold hercules zzz wrote: Hi.I take an error message:the procedure entry point_fcntl64 could not be located in the dynamic link library cygwin1.dll when i try to start XWin.exe or startx.exe or startxwin.bat.
Xterm on HP-UX
Hello, I am using cygwin with xfree68 to connect from my Windows XP machine to a HP-UX 11.11 machine. I am doing a rlogin from an xterm window. Whenever I type in a '@' while logged into the HP machine, I also get a new line. This is preventing me from using such things as sqlplus. Is there a fix for this problem? David Wright
Re: Xterm on HP-UX
On Wed, 24 Mar 2004, Wright, David L wrote: Hello, I am using cygwin with xfree68 to connect from my Windows XP machine to a HP-UX 11.11 machine. I am doing a rlogin from an xterm window. Whenever I type in a '@' while logged into the HP machine, I also get a new line. This is preventing me from using such things as sqlplus. Is there a fix for this problem? That sounds like a shell issue: HP's default settings for stty. stty -a would show if @ (and #) are used. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
On Tue, 23 Mar 2004, Harold L Hunt II wrote: Fabrizio, It looks like your conclusions are correct. I have included your suggested change in XFree86-xserv-4.3.0-60. Please test this on a 24 bit depth system. It seems to work okay on 32 bit depth systems. I tested this with the Oracle installer as well, and it's working fine.. -Rob
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. Thomas Dickey wrote: On Wed, 25 Feb 2004, Alexander Gottwald wrote: On Wed, 25 Feb 2004, Danilo Turina wrote: In effect opening an xterm within rootless mode I can see from stty that the terminal speed is 38400, while opening the same terminal from multiwindow mode I see that the speed is 0 (the same does not happens for rxvt for which stty always reports 38400). I've started bash the following ways: cmd.exe : speed 38400 - xterm.exe : speed 38400 - xterm.exe : speed 38400 XWin.exe (multiwindow) - xterm.exe : speed 0 XWin.exe (no multiwindow) - xterm.exe : speed 0 - xterm.exe : speed 0 XWin.exe (build with console window) - xterm.exe : speed 0 It seems the newly started xterm inherits the speed settings from the starting program. not exactly (I've rebooted to test cygwin, see that BAUD_0 isn't defined). I think the issue is that the ioctl to set the baud rate fails. It doesn't inherit the speed settings, since xterm always sets it. Seeing why it works for rxvt would be useful, for instance. Baud rate for a terminal emulator is bogus anyway - the reason why it is set is to give ncurses a hint about padding. I changed it from 9600 to 38400 a few years ago, and rxvt followed suit. The only solution seems to start the xterms from a windows console. for now, true. -- -- Danilo Turina Alcatel Optics OND Network Management Rieti (Italy) - Phone: +39 0746 600332 -- 2 anni 11 mesi 15 giorni 8 ore 15 minuti 29 secondi
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
On Wed, 24 Mar 2004, Danilo Turina wrote: Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. But I didn't change anything in xterm. It would probably be something changed in the environment which executes xterm. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Re: XWin 4.3.0-50 crashes with -multiwindow (ping Earle)
Rob, Thanks for the test. I was hoping that this fix would resolve most of the weird crashing problems we have been having. Harold Rob Foehl wrote: On Tue, 23 Mar 2004, Harold L Hunt II wrote: Fabrizio, It looks like your conclusions are correct. I have included your suggested change in XFree86-xserv-4.3.0-60. Please test this on a 24 bit depth system. It seems to work okay on 32 bit depth systems. I tested this with the Oracle installer as well, and it's working fine.. -Rob
W2K Terminal Services and multiple users running X
I am able to successfully run XWin after logging onto a W2K Server via Terminal Services, but if another user attempts to do the same thing at the same time, she is not allowed. Is there some way to set this up so that 2 instances of XWin can be running at the same time? Do we each need our own Cygwin /tmp dir? I found many references to Terminal Services in the mail list archives but none pertaining to multiple users. TIA, -joel
Re: W2K Terminal Services and multiple users running X
Joel, Each user needs a unique display number, which is specified as N in the following: XWin :N Such as: XWin :0 (default display zero) XWin :1 (display one) You can either hard-code these in startup scripts for each user, or you can help us with the feature that automatically assigns display numbers... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Harold Joel Moots wrote: I am able to successfully run XWin after logging onto a W2K Server via Terminal Services, but if another user attempts to do the same thing at the same time, she is not allowed. Is there some way to set this up so that 2 instances of XWin can be running at the same time? Do we each need our own Cygwin /tmp dir? I found many references to Terminal Services in the mail list archives but none pertaining to multiple users. TIA, -joel
Re: [SOLVED] MultiWindow Mode: stty speed = 0 on xterm cause rlogin to fail
Thomas Dickey wrote: On Wed, 24 Mar 2004, Thomas Dickey wrote: On Wed, 24 Mar 2004, Danilo Turina wrote: Hey!! I didn't notice it immediately, but now the problem has disappeared (maybe because the new xterm-185?): speed is now 38400 as it should be. But I didn't change anything in xterm. It would probably be something changed in the environment which executes xterm. on second thought - it is possible that there is a difference between the define's used by imake versus those derived from the configure script. We did also jump from 174 to 185... don't know if there were changes in that time period related to this or if you were already aware of that when you made your comment that not much changed. Harold
GB keyboard layout broken
In a previous version (maybe a couple of months old) I had configuration line like this Option XkbLayout gb to give me a uk keyboard layout. Now it doesn't. Nor does setxkblayout seem to do anything but output an error. What is the correct way to set the keyboard layout or is it just broken at the moment ? Cheers, Jon
Re: GB keyboard layout broken
On Wed, 24 Mar 2004, Jon Schneider wrote: In a previous version (maybe a couple of months old) I had configuration line like this Option XkbLayoutgb to give me a uk keyboard layout. Now it doesn't. Nor does setxkblayout seem to do anything but output an error. What is the correct way to set the keyboard layout or is it just broken at the moment ? Please send /tmp/XWin.log and start XWin with the option -xkblayout gb bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: W2K Terminal Services and multiple users running X
Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor On Wed, 24 Mar 2004, Harold L Hunt II wrote: Joel, Each user needs a unique display number, which is specified as N in the following: XWin :N Such as: XWin :0 (default display zero) XWin :1 (display one) You can either hard-code these in startup scripts for each user, or you can help us with the feature that automatically assigns display numbers... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Harold Joel Moots wrote: I am able to successfully run XWin after logging onto a W2K Server via Terminal Services, but if another user attempts to do the same thing at the same time, she is not allowed. Is there some way to set this up so that 2 instances of XWin can be running at the same time? Do we each need our own Cygwin /tmp dir? I found many references to Terminal Services in the mail list archives but none pertaining to multiple users. TIA, -joel -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: W2K Terminal Services and multiple users running X
Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold
Running more than one X server, how (or maybe there's another way)?
I am trying to run more than one X server on my WIn2k system and don't seem to be able to do it. Maybe I'm trying to do the wrong thing and there's another approach to get what I want. I'm running the -60 version. I run a multiple/virtual desktop system on my win2k machine, I run the cygwin X server to display a remote system's Linux desktop in one of the virtual windows and it occupies the whole window. What I want to do in addition is to display local rxvt windows on demand on other win2k virtual desktop windows. Trying to start another X server to display the local rxvt window(s) doesn't seem to work, I've tried using the -screen parameter but that didn't seem to get me far, the rxvt windows insisted in popping up on the Linux desktop anyway and the second X server failed to start up with an error message about invalid screen parameters. Can anyone think of a way of getting what I want? Can I start up an X server that will see the win2k virtual screens as different displays, or can I start up one that will see them all as one big wide display? -- Chris Green ([EMAIL PROTECTED])
Re: W2K Terminal Services and multiple users running X
On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold Harold, It might be possible to have the batch file check for the existence of the display file. A rather crude first approximation would be (1) sleep for a bit, then (2) do dir /b /o:-d c:\cygwin\var\run\XWin.*.display and (3) extract the first file, then (4) type this file to get the display number. There may also be a way of guessing whether the file was created by the current instance of XWin I don't have it fleshed out yet, but something like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not, create it, (3) run XWin, (4) sleep in a loop while the first file returned by dir /b /o:-d c:\cygwin\var\run\XWin.*.display is XWin.lock.display; finally, (5) extract the first file and (6) type the file to get the display number. The XWin.lock.display will serve as both a lock file for concurrent invocations (still not foolproof, but much better than nothing), and also as a marker (it will be the newest such file until XWin creates one, so it will be first in the list). Of course, step (7) is to remove the lock file... Hope this makes sense. I think I can implement the above with the NT command subset (cmd.exe commands). I'm not sure if the limited expressiveness of command.com on Win9x systems will allow this. Any takers? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: Running more than one X server, how (or maybe there's another way)?
On Wed, 24 Mar 2004, Chris Green wrote: I am trying to run more than one X server on my WIn2k system and don't seem to be able to do it. Maybe I'm trying to do the wrong thing and there's another approach to get what I want. I'm running the -60 version. I run a multiple/virtual desktop system on my win2k machine, I run the cygwin X server to display a remote system's Linux desktop in one of the virtual windows and it occupies the whole window. What I want to do in addition is to display local rxvt windows on demand on other win2k virtual desktop windows. Trying to start another X server to display the local rxvt window(s) doesn't seem to work, I've tried using the -screen parameter but that didn't seem to get me far, the rxvt windows insisted in popping up on the Linux desktop anyway and the second X server failed to start up with an error message about invalid screen parameters. Can anyone think of a way of getting what I want? Can I start up an X server that will see the win2k virtual screens as different displays, or can I start up one that will see them all as one big wide display? Try XWin :0 ; XWin :1 . Of course, arbitrary parameters may be added to either invocation... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: W2K Terminal Services and multiple users running X
Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold Harold, It might be possible to have the batch file check for the existence of the display file. A rather crude first approximation would be (1) sleep for a bit, then (2) do dir /b /o:-d c:\cygwin\var\run\XWin.*.display and (3) extract the first file, then (4) type this file to get the display number. There may also be a way of guessing whether the file was created by the current instance of XWin I don't have it fleshed out yet, but something like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not, create it, (3) run XWin, (4) sleep in a loop while the first file returned by dir /b /o:-d c:\cygwin\var\run\XWin.*.display is XWin.lock.display; finally, (5) extract the first file and (6) type the file to get the display number. The XWin.lock.display will serve as both a lock file for concurrent invocations (still not foolproof, but much better than nothing), and also as a marker (it will be the newest such file until XWin creates one, so it will be first in the list). Of course, step (7) is to remove the lock file... Hope this makes sense. I think I can implement the above with the NT command subset (cmd.exe commands). I'm not sure if the limited expressiveness of command.com on Win9x systems will allow this. Any takers? I'm pretty sure you would still be messed up by batch files not having the concept of assigning the output of a program to an environment variable. There is a hack you can sort of do, which I have done, which is to have your program generate a batch file that sets the value of an env var, then CALL that batch file from your original batch file. Of course, this do nothing to solve the mutli-user problem since you would have to know the name of the batch file that was assigned, which is a nice Catch-22 back to the problem of not being able to assign the output of programs to an env var. I'm pretty sure it wouldn't be possible unless we had XWin.exe launched directly, then have it pre-process, write out to a temp file, and run a specified batch script. Sounds kinda weird to me and like just using shell scripts would be easier and less to maintain. What do you think? Harold
Problem with Gnuplot under Cygwin/XFree86
I described a problem with Gnuplot under Cygwin/XFree86 here: http://groups.google.com/groups?dq=hl=enlr=ie=UTF-8threadm=c3mrn7%24oko%241%40nets3.rz.RWTH-Aachen.DEprev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.graphics.apps.gnuplot In the opinion of one of the Gnuplot gurus (Hans BB), it's a Cygwin/XFree86 problem not a Gnuplot problem. I don't know. Do any of the cygwin-xfree86 authorities agree? Either way, I'd like to be able to resolve it. BTW, is there an FAQ that describes the correct way to post a reply to a message in this group so it registers as a follow-up message. Thanks, jjo -- Protect yourself from spam, use http://sneakemail.com
Re: Problem with Gnuplot under Cygwin/XFree86
Have you tried the Cygwin/X gnuplot package instead of the one that you compiled? It is possible that Volker has already fixed this problem in his Cygwin-specific patch. If not, he reads this list and maybe he will want to try to fix it. ;) Harold I described a problem with Gnuplot under Cygwin/XFree86 here: http://groups.google.com/groups?dq=hl=enlr=ie=UTF-8threadm=c3mrn7%24oko%241%40nets3.rz.RWTH-Aachen.DEprev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.graphics.apps.gnuplot In the opinion of one of the Gnuplot gurus (Hans BB), it's a Cygwin/XFree86 problem not a Gnuplot problem. I don't know. Do any of the cygwin-xfree86 authorities agree? Either way, I'd like to be able to resolve it. BTW, is there an FAQ that describes the correct way to post a reply to a message in this group so it registers as a follow-up message. Thanks, jjo
RE: Hydravision problem?
Hi, thanks for the suggestion. I have updated to 4.3.0-59 and 4.3.0-60. It is a little bit different behavior than the earlier version I had. On the secondary display the xterm seems fine. No immediate issures. On the primary display the refresh does not seem to work correctly. The window seems to have some smaller portion on the left hand side that works correctly. The size seems to vary from a sliver on the left barely visable to about half the xterm. I can't seem to tell whats determining the size. The part that does not refresh is black or white. Even the pointer (which is a }{ symbol) seems to stop where the refresh stops. Note that it will go up and down and you can still see part of it on the edge of the refresh area. Thanks again for your help. Pete Inskeep
Re: Cygwin install
On Wed, 24 Mar 2004, Crescioli, Phil wrote: All, Is KDE bundled somewhere within Cygwin or do I have to get KDE for Cygwin/Win XP separately? Thanks, Phil Crescioli First off, wrong list. X-related questions should go to cygwin-xfree at cygwin dot com. I'm redirecting this reply there. Secondly (a general Cygwin point): if you don't find what you need at http://cygwin.com/packages/, it's not part of Cygwin. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
Hi I just discovered why uxterm and xfontsel are crashing on my system. It's happening when running cygserver so X can detect shared memory support. When disabling cygserver I see the following message in XWin.log: MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel but then uxterm and xfontsel are running fine. So it looks like the XFree86-Bigfont extension somehow doesn't work properly with cygserver. Here my relevant environment. cygwin 1.5.9-1 libXft 2.1.6-1 libXft-devel2.1.6-1 libXft1 1.0.0-1 libXft2 2.1.6-1 XFree86-base4.3.0-9 XFree86-bin 4.3.0-19 XFree86-bin-icons 4.3.0-7 XFree86-doc 4.3.0-1 XFree86-etc 4.3.0-11 XFree86-f1004.3.0-1 XFree86-fcyr4.3.0-1 XFree86-fenc4.3.0-1 XFree86-fnts4.3.0-1 XFree86-fscl4.3.0-1 XFree86-fsrv4.3.0-8 XFree86-html4.3.0-8 XFree86-jdoc4.3.0-1 XFree86-lib 4.3.0-2 XFree86-lib-compat 4.3.0-2 XFree86-man 4.3.0-8 XFree86-nest4.3.0-7 XFree86-prog4.3.0-19 XFree86-prt 4.3.0-5 XFree86-ps 4.3.0-1 XFree86-startup-scripts 4.2.0-5 XFree86-vfb 4.3.0-7 XFree86-xserv 4.3.0-60 XFree86-xwinclip4.3.0-2 xterm 185-3 Can anbody confirm my observation ? Ciao Volker
RE: Hydravision problem?
Howdy, At 10:05 PM 3/24/2004 -0500, Pete Inskeep wrote: On the secondary display the xterm seems fine. No immediate issures. On the primary display the refresh does not seem to work correctly. The window seems to have some smaller portion on the left hand side that works correctly. The size seems to vary from a sliver on the left barely visable to about half the xterm. I can't seem to tell whats determining the size. The part that does not refresh is black or white. Even the pointer (which is a }{ symbol) seems to stop where the refresh stops. Note that it will go up and down and you can still see part of it on the edge of the refresh area. Does Hydravision expose two separate displays in the Display control panel, Advanced tab (i.e. numbered 1 and 2 in the dialog)? If so, what is the orientation of these displays? relative to the one you have defined as the main screen (use this device as primary monitor)? Can you click-and-drag both displays and report the (x,y) coordinate of each one's upper-left corner (shows in a balloon help window when you draw a monitor in the dialog)? And are the X/Y pixel dimension of each monitor the same? It looks like what's going on is the X/Y dimensions of the X root window aren't matching the X/Y dimensions of the Win32 desktop for some reason. The same thing happens if you use multiwindow w/o the multiplemonitors option on a 2- or 3-head box... -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: W2K Terminal Services and multiple users running X
On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold Harold, It might be possible to have the batch file check for the existence of the display file. A rather crude first approximation would be (1) sleep for a bit, then (2) do dir /b /o:-d c:\cygwin\var\run\XWin.*.display and (3) extract the first file, then (4) type this file to get the display number. There may also be a way of guessing whether the file was created by the current instance of XWin I don't have it fleshed out yet, but something like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not, create it, (3) run XWin, (4) sleep in a loop while the first file returned by dir /b /o:-d c:\cygwin\var\run\XWin.*.display is XWin.lock.display; finally, (5) extract the first file and (6) type the file to get the display number. The XWin.lock.display will serve as both a lock file for concurrent invocations (still not foolproof, but much better than nothing), and also as a marker (it will be the newest such file until XWin creates one, so it will be first in the list). Of course, step (7) is to remove the lock file... Hope this makes sense. I think I can implement the above with the NT command subset (cmd.exe commands). I'm not sure if the limited expressiveness of command.com on Win9x systems will allow this. Any takers? I'm pretty sure you would still be messed up by batch files not having the concept of assigning the output of a program to an environment variable. Well, the point was that the NT command subset *does* have this concept. The syntax would be something like (this prints it, but you get the point): FOR /F tokens=* %%G IN ('dir /b /o:-d') DO @(IF NOT DEFINED notfirst (echo %%G call SET notfirst=1)) There is a hack you can sort of do, which I have done, which is to have your program generate a batch file that sets the value of an env var, then CALL that batch file from your original batch file. Of course, this do nothing to solve the mutli-user problem since you would have to know the name of the batch file that was assigned, which is a nice Catch-22 back to the problem of not being able to assign the output of programs to an env var. As mentioned above, we may need to resort to this hack for Win9x. I'm pretty sure it wouldn't be possible unless we had XWin.exe launched directly, then have it pre-process, write out to a temp file, and run a specified batch script. Sounds kinda weird to me and like just using shell scripts would be easier and less to maintain. What do you think? Harold Nah, we probably should just call a shell script on Win9x... Fortunately, we can test the output of VER to see if we're on Win9x... Unfortunately, if we do go to the trouble of writing the shell script, we might as well use it everywhere. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
Re: W2K Terminal Services and multiple users running X
Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold Harold, It might be possible to have the batch file check for the existence of the display file. A rather crude first approximation would be (1) sleep for a bit, then (2) do dir /b /o:-d c:\cygwin\var\run\XWin.*.display and (3) extract the first file, then (4) type this file to get the display number. There may also be a way of guessing whether the file was created by the current instance of XWin I don't have it fleshed out yet, but something like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not, create it, (3) run XWin, (4) sleep in a loop while the first file returned by dir /b /o:-d c:\cygwin\var\run\XWin.*.display is XWin.lock.display; finally, (5) extract the first file and (6) type the file to get the display number. The XWin.lock.display will serve as both a lock file for concurrent invocations (still not foolproof, but much better than nothing), and also as a marker (it will be the newest such file until XWin creates one, so it will be first in the list). Of course, step (7) is to remove the lock file... Hope this makes sense. I think I can implement the above with the NT command subset (cmd.exe commands). I'm not sure if the limited expressiveness of command.com on Win9x systems will allow this. Any takers? I'm pretty sure you would still be messed up by batch files not having the concept of assigning the output of a program to an environment variable. Well, the point was that the NT command subset *does* have this concept. The syntax would be something like (this prints it, but you get the point): FOR /F tokens=* %%G IN ('dir /b /o:-d') DO @(IF NOT DEFINED notfirst (echo %%G call SET notfirst=1)) Huh... I have never heard of this being supported in NT's cmd. Are you sure that you can actually get the value stored into an env var? There is a hack you can sort of do, which I have done, which is to have your program generate a batch file that sets the value of an env var, then CALL that batch file from your original batch file. Of course, this do nothing to solve the mutli-user problem since you would have to know the name of the batch file that was assigned, which is a nice Catch-22 back to the problem of not being able to assign the output of programs to an env var. As mentioned above, we may need to resort to this hack for Win9x. I'm pretty sure it wouldn't be possible unless we had XWin.exe launched directly, then have it pre-process, write out to a temp file, and run a specified batch script. Sounds kinda weird to me and like just using shell scripts would be easier and less to maintain. What do you think? Harold Nah, we probably should just call a shell script on Win9x... Fortunately, we can test the output of VER to see if we're on Win9x... Unfortunately, if we do go to the trouble of writing the shell script, we might as well use it everywhere. Possibly. It might be a good idea to have a pure batch solution available so that people could adapt it if they had good reason to. The default should probably just be a shell script though. Harold
Clipboard fix - Please test
I have just uploaded XFree86-xserv-4.3.0-61 and I think it will fix the clipboard related hangs. I would really appreciate it if people in other timezones could test this through the night (should show up on some mirrors with in a few hours, like mirrors.kernel.org) so that I can fix any problems with the change tomorrow. I would like to get this change stabilized before including Takuma's additional performance enhancement for multi-window mode. I also want to fix our dang tray icon that isn't cleaning itself up in all cases anymore... Harold
Re: uxterm from xterm-185-3 and xfontsel crashing when running under cygserver support
Hi I tried to find some information about the BigFont extension. This is from the X man page: XF86BIGFONT_DISABLE Setting this variable to a non-empty value disables the XFree86-Bigfont extension. This extension is a mechanism to reduce the memory consumption of big fonts by use of shared mem- ory. So I tried the following. I enabled the cygserver service again and set XF86BIGFONT_DISABLE=1 in my environment before starting up XWin. And voila, xfontsel and uxterm are working properly. So there's definitely a problem with the shared memory support of cygserver related to the BigFont extension. BTW I see the problem also with my mule enabled XEmacs when opening mails under Gnus with Japanese characters. XEmacs crashes happily, but not when using XF86BIGFONT_DISABLE or when disabling cygserver. Ciao Volker
Re: W2K Terminal Services and multiple users running X
On Thu, 25 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: On Wed, 24 Mar 2004, Harold L Hunt II wrote: Igor Pechtchanski wrote: Harold, ... but the true difficulty in that is communicating the assigned display number back to the shell from which XWin was launched so that X programs can know the correct display to connect to. Why not have XWin write its display number to a file in /var/run, e.g., /var/run/XWin.$$.display, where $$ stands for the PID of the XWin process? Since anyone who started XWin in the background from a shell script will have access to its PID via $!, the following idiom will work: XWin -multiwindow -emulate3buttons XWINPID=$! DISPLAY_FILE=/var/run/XWin.$XWINPID.display while [ ! -e $DISPLAY_FILE ]; do sleep 1; done DISPLAY=`cat $DISPLAY_FILE` Unfortunately, this approach won't work from .bat scripts (since they aren't aware of Cygwin process IDs). It also won't work if cygstart XWin is used. Any ideas on how to address it? Igor Batch scripts was more of my concern... it would be possible to do from a Cygwin shell like you describe (though I did not have all of the tricks in mind). Maybe the solution is to make the batch files just launch a shell script to do the heavy lifting... sort of cheating but if it makes it possible then it is acceptable to me. Harold Harold, It might be possible to have the batch file check for the existence of the display file. A rather crude first approximation would be (1) sleep for a bit, then (2) do dir /b /o:-d c:\cygwin\var\run\XWin.*.display and (3) extract the first file, then (4) type this file to get the display number. There may also be a way of guessing whether the file was created by the current instance of XWin I don't have it fleshed out yet, but something like: (1) check if c:\cygwin\var\run\XWin.lock.display exists, (2) if not, create it, (3) run XWin, (4) sleep in a loop while the first file returned by dir /b /o:-d c:\cygwin\var\run\XWin.*.display is XWin.lock.display; finally, (5) extract the first file and (6) type the file to get the display number. The XWin.lock.display will serve as both a lock file for concurrent invocations (still not foolproof, but much better than nothing), and also as a marker (it will be the newest such file until XWin creates one, so it will be first in the list). Of course, step (7) is to remove the lock file... Hope this makes sense. I think I can implement the above with the NT command subset (cmd.exe commands). I'm not sure if the limited expressiveness of command.com on Win9x systems will allow this. Any takers? I'm pretty sure you would still be messed up by batch files not having the concept of assigning the output of a program to an environment variable. Well, the point was that the NT command subset *does* have this concept. The syntax would be something like (this prints it, but you get the point): FOR /F tokens=* %%G IN ('dir /b /o:-d') DO @(IF NOT DEFINED notfirst (echo %%G call SET notfirst=1)) Huh... I have never heard of this being supported in NT's cmd. Are you sure that you can actually get the value stored into an env var? Yep. Try it (from the command line): FOR /F tokens=* %G IN ('dir /b /o:-d') DO @(IF NOT DEFINED val SET val=%G) %val% will be set to the name of the last modified file in the current directory. Of course, for the batch file we'll use %%G instead of %G. There is a hack you can sort of do, which I have done, which is to have your program generate a batch file that sets the value of an env var, then CALL that batch file from your original batch file. Of course, this do nothing to solve the mutli-user problem since you would have to know the name of the batch file that was assigned, which is a nice Catch-22 back to the problem of not being able to assign the output of programs to an env var. As mentioned above, we may need to resort to this hack for Win9x. I'm pretty sure it wouldn't be possible unless we had XWin.exe launched directly, then have it pre-process, write out to a temp file, and run a specified batch script. Sounds kinda weird to me and like just using shell scripts would be easier and less to maintain. What do you think? Harold Nah, we probably should just call a shell script on Win9x... Fortunately, we can test the output of VER to see if we're on Win9x... Unfortunately, if we do go to the trouble of writing the shell script, we might as well use it everywhere. Possibly. It might be a good idea to have a pure batch solution available so that people could adapt it if they had good reason to. The default should probably just be a shell script though. Harold Yes, but then the default batch should check the OS and bail out if it's Win9x/ME. Igor --
Re: Problem with Gnuplot under Cygwin/XFree86
Harold == Harold L Hunt writes: Harold Have you tried the Cygwin/X gnuplot package instead of the one that Harold you compiled? It is possible that Volker has already fixed this Harold problem in his Cygwin-specific patch. If not, he reads this list and Harold maybe he will want to try to fix it. ;) I can confirm that my version also exhibits this problem :-( Harold Harold Ciao Volker