Re: multiwindow broken?
Harold, Hmm... maybe Takuma will know something about this since he was recently changing code related to windows not redrawing correctly. Takuma, any ideas? I have committed a fix in winAdjustXWindow. Takuma Murakami
Re: Problem with 4.3.0-47, ssh tunelling and emacs
On Tue, 2 Mar 2004 [EMAIL PROTECTED] wrote: After upgrading to Xfree86-xserv to 4.3.0-47 using the cygwin setup, GNU emacs crashes with the following messages: X protocol error: BadWindow (invalid Window parameter) on protocol request 38 The crash occurs as soon as the mouse is moved *after* the RMB is pressed down. It is systematic and can be repeated easily The crash occurs with both emacs 21.2.1 and 21.3.1. The OS is Red Hat 9. The problem does not sem to occur with other X applications on the same tunnel. xemacs works fine. Surprisingly enough, the crash does not occur all the time. Within the same session, emacs sometimes works just fine. When that is the case, it works fine repeatedly. The crash if frequent though to prevent any reliable use of emacs, and once it kicks in it is systematic. The conditions that trigger the problem are unclear. Stopping and restarting the X server does not help. The problem does not seem to exist in 4.3.0-44, so downgrading to that version seems to be a valid workaround. This may be a problem with the new OpenSSH. You have to add X11ForwardTrusted to the .ssh/config file. See http://x.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-ssh-no-x11forwarding bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
Re: downgrading
On Tue, 2 Mar 2004, Daniel Danger Bentley wrote: Thanks so much! Any good hints on how I downgrade XFree? Can I do it with setup.exe? How do I install it? Is there a good page? I'd love to make this work again. What do you mean with downgrade? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
Reducing configuration headaches for cygwin-xfree
Problem: CygWin-xfree86 is tricky to install and configure and this limits who can successfully install and use this software. (If you do not agree that this is a problem, then the rest of the message is obviously irrelevant. :-) Possible solution: - Create an installer that has various preconfigured profiles which then dictates the rest of the settings. Just like xfree86 has lots of C code that I don't know or understand, the various configuration options and .bat files and scripts must be moved out of the user domain. - ssh -X profile. Create icon(s) on desktop for the various appliactions, e.g. Importantly xterm(cygwin local), xterm remote, Evolution remote, OpenOffice remote. - XDCMP. I don't know much about this, so I won't comment, but I see that this accounts for a lot of the traffic in this mailing list. - infrequently updated. The users targeted by this sort of installer never upgrade unless they absolutely have to. - cygwin1.dll side-by-side install issue solved, i.e. it should be possible to have a stable version of this X server installed next to a bleeding edge CygWin. - The CygWin installer is a stumbling block itself. For those that *only* want an X server, a gigantic self-installing .exe file would be better. - -clipboard enabled by default. - multimonitor support enabled by default. Note, this is not a complaint! I love CygWin and I point to it as one of the stellar examples of what the open source community can achieve with minimal resources! Øyvind
Re: downgrading
Dan, Please use XFree86-xserv-4.3.0-50 when it hits the mirrors in a few hours. Takuma Murakami made a patch that should fix your problem with window moving on multiple monitors (he has a multiple monitor setup at home, so I believe he was able to test this). In answer to your question, can downgrade to the version currently marked as prev via setup.exe if you locate the XFree86-xserv package in the list of packages, then click on the value in the New column until it says the previous version number. You can figure out which is the previous version number by clicking the new column up to about 8 times until you see all options available. However, we generally like to fix things quickly and would prefer not to have most users downgrading to older versions to work around things. Harold Daniel Danger Bentley wrote: Thanks so much! Any good hints on how I downgrade XFree? Can I do it with setup.exe? How do I install it? Is there a good page? I'd love to make this work again. Thanks, Dan
Re: multiwindow broken?
Thanks Takuma. Takuma Murakami wrote: Harold, Hmm... maybe Takuma will know something about this since he was recently changing code related to windows not redrawing correctly. Takuma, any ideas? I have committed a fix in winAdjustXWindow. Takuma Murakami
RE: multiwindow broken?
Bingo. That fixes my problem ;] Thanks guys. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Harold L Hunt II Sent: 03 March 2004 13:32 To: [EMAIL PROTECTED] Subject: Re: multiwindow broken? Thanks Takuma. Takuma Murakami wrote: Harold, Hmm... maybe Takuma will know something about this since he was recently changing code related to windows not redrawing correctly. Takuma, any ideas? I have committed a fix in winAdjustXWindow. Takuma Murakami
Re: Reducing configuration headaches for cygwin-xfree
On Wed, 3 Mar 2004, Øyvind Harboe wrote: CygWin-xfree86 is tricky to install and configure and this limits who can successfully install and use this software. (slightly resorted) My comments on these topics: - cygwin1.dll side-by-side install issue solved, i.e. it should be possible to have a stable version of this X server installed next to a bleeding edge CygWin. This is an issue that must be solved by the cygwin folks and it is unlikely that is ever will. the shared memory sections are required for interprocess communication. if there are two different cygwin1.dlls floating around (even renamed and the shared memory separated) it will break the xserver integration into the cygwin layer. == no go - The CygWin installer is a stumbling block itself. For those that *only* want an X server, a gigantic self-installing .exe file would be better. Separate installers for cygwin programs is pain. Wincvs has done it. OpenSSH has done it. And a lot more too. And it always leads to _huge_ problems if you want to use them together. Most installers also install their own cygwin1.dll with different version and then the programs just bomb. - Create an installer that has various preconfigured profiles which then dictates the rest of the settings. Just like xfree86 has lots of C code that I don't know or understand, the various configuration options and .bat files and scripts must be moved out of the user domain. There were about 5 tries to build a wrapper which handles this. But always it was written with Delphi, VisualC++ or some other non-free compiler. If someone build such a wrapper with plain gcc it is very likely to become included. But not if it depends on VCL, MFC or some other non-free class library. Also adding other dependencies to eg QT or GTK is a bad idea. A simple plain windows application (like cygwin setup) is preferred. - ssh -X profile. Create icon(s) on desktop for the various appliactions, e.g. Importantly xterm(cygwin local), xterm remote, Evolution remote, OpenOffice remote. This is an option for the wrapper. Then it's not only a wrapper but also a configtool for the whole X11 environment. - XDCMP. I don't know much about this, so I won't comment, but I see that this accounts for a lot of the traffic in this mailing list. The most problems result in problems with disabled xdmcp on linux side. This is already covered in the faq. - infrequently updated. The users targeted by this sort of installer never upgrade unless they absolutely have to. A check for updates button in the configtool/wrapper - -clipboard enabled by default. As long as it's not stable it will not be enabled by default. - multimonitor support enabled by default. let's see bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
FW: XWin Xserver maximum root area exceeded?
Hi, Harold suggested that I post my questions on the mailing list details see below. Brigitte Brigitte, Glad you like Cygwin/X, but I am afraid I don't know the answers to all of your questions. You will have better luck at [EMAIL PROTECTED] I found your Cygwin/X User's Guide excellent and easy to use thank you very much for providing it. You are welcome. What I found too: The XWin.exe does not have an easy way to find out its version or did I miss this? (like XWin.exe --version) We didn't have version information in the executable until just now. I was going to add a --version or -version parameter, but I forgot. Oh well, when you do a XWin -help now it has the version number in a popup box, so that should suffice for the time being. Harold -Original Message- From: Bonert Brigitte Sent: Tuesday, March 02, 2004 3:18 PM To: '[EMAIL PROTECTED]' Subject: XWin Xserver maximum root area exceeded? Hi, I am trying to use the prebuilt XWin.exe on a root area of 12800x2048 (20 projectors arranged in 2 rows each with a resolution of 1280x1024) The application on the Unix side (DEC Alpha) uses Pseudo colors so I run with 256 colors only on the special PC which runs a modified WIndows2000 with a special DisplayDriver which supports this resolution (it contains 20 video cards). When I run XWin.exe on my PC and display the pictures of the application on the Unix server everything works just fine (I can have only 256 colors which make for some strange colors) but on the special PC I am getting this error (within the Unix application): X_Error Bad Window (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) and the application on the Unix box fails to run. Is there a max width value I am exceeding and can change and rebuild the executable? I found your Cygwin/X User's Guide excellent and easy to use thank you very much for providing it. What I found too: The XWin.exe does not have an easy way to find out its version or did I miss this? (like XWin.exe --version) Is there a way to define the title of the upcoming server window (I am using xdm on the Unix boxes)? Please let me know Thank you Brigitte Independent Electricity Market Operator * [EMAIL PROTECTED] * 905 855 6102 * This message is intended only for the use of the intended recipients, and it may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message is strictly prohibited. If you are not the intended recipient, please notify me immediately by return e-mail, and delete this message from your system. *
Re: Reducing configuration headaches for cygwin-xfree
Alexander Gottwald wrote: On Wed, 3 Mar 2004, Øyvind Harboe wrote: CygWin-xfree86 is tricky to install and configure and this limits who can successfully install and use this software. (slightly resorted) My comments on these topics: - cygwin1.dll side-by-side install issue solved, i.e. it should be possible to have a stable version of this X server installed next to a bleeding edge CygWin. This is an issue that must be solved by the cygwin folks and it is unlikely that is ever will. the shared memory sections are required for interprocess communication. if there are two different cygwin1.dlls floating around (even renamed and the shared memory separated) it will break the xserver integration into the cygwin layer. == no go I think he is saying that we use the installed cygwin1.dll since it is not usually the cause of stability problems. That is totally acceptable. Though, I think it could have been worded better :) - The CygWin installer is a stumbling block itself. For those that *only* want an X server, a gigantic self-installing .exe file would be better. Separate installers for cygwin programs is pain. Wincvs has done it. OpenSSH has done it. And a lot more too. And it always leads to _huge_ problems if you want to use them together. Most installers also install their own cygwin1.dll with different version and then the programs just bomb. I'm not going to be writing an installer anytime soon. - Create an installer that has various preconfigured profiles which then dictates the rest of the settings. Just like xfree86 has lots of C code that I don't know or understand, the various configuration options and .bat files and scripts must be moved out of the user domain. There were about 5 tries to build a wrapper which handles this. But always it was written with Delphi, VisualC++ or some other non-free compiler. If someone build such a wrapper with plain gcc it is very likely to become included. But not if it depends on VCL, MFC or some other non-free class library. Also adding other dependencies to eg QT or GTK is a bad idea. A simple plain windows application (like cygwin setup) is preferred. I am actually thinking about finally doing this in a way that everyone can contribute to. I have built some test programs using OpenWatcom and they work great; OpenWatcom uses the same w32api headers and libs that Cygwin uses, so it is possibly to compile native Win32 apps in OpenWatcom with no trouble. Additionally, the C runtime is linked statically by default, which means that the distributed executable has no dependencies on external DLLs like MinGW does. In summary, OpenWatcom finally makes this sort of thing possible. Now, whether or not I actually get around to writing this sort of interface is another question. :) Oh, one note worth mentioning: I agree that the proper way to do this sort of profile app is via a stand-alone application that creates command lines for XWin.exe. There is little reason and little benefit to trying to integrate this sort of thing into XWin.exe. However, one of the things required by such an approach is a way to get a unique display number for each invocation of XWin.exe automatically. - ssh -X profile. Create icon(s) on desktop for the various appliactions, e.g. Importantly xterm(cygwin local), xterm remote, Evolution remote, OpenOffice remote. This is an option for the wrapper. Then it's not only a wrapper but also a configtool for the whole X11 environment. Right. - XDCMP. I don't know much about this, so I won't comment, but I see that this accounts for a lot of the traffic in this mailing list. The most problems result in problems with disabled xdmcp on linux side. This is already covered in the faq. Another problem that still remains is that -query commands (by far the most popular) do not always send the outbound interface address as the first address in the list to the XDM server. The XDM server is supposed to check all addresses in the list, but the sample implementation does not, nor do KDM and GDM; so in reality, only the first address is looked at. I just about have a patch in hand that sorts the outbound address to the top of the list, which will eliminate the remaining cases where the -from parameter is required for a -query. Then the only remaining Xdmcp problems will be due to XDM not being configured properly or do to firewalls. - infrequently updated. The users targeted by this sort of installer never upgrade unless they absolutely have to. A check for updates button in the configtool/wrapper Not a bad idea. - -clipboard enabled by default. As long as it's not stable it will not be enabled by default. It is getting very close. At least it doesn't crash XWin.exe anymore and it doesn't cause problems with Xdmcp... so we are getting close to enabling it by default. - multimonitor support enabled by default. let's see Yes, that is still a matter of preference. I think it might be a good
Re: New log file header
Ehud Karni wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 02 Mar 2004 23:38:52 -0500, Harold L Hunt II [EMAIL PROTECTED] wrote: The new header in the log file, as of XFree86-xserv-4.3.0-49, looks like the following: === Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.49 Contact: cygwin-xfree at cygwin daught com XWin was started with the following command line: XWin :0 -multiwindow -clipboard ddxProcessArgument - Initializing default screens [...] === This change is very good, but there are 2 notes: 1. The Identification (Welcome ... Contact) appears twice (at the top and just after winInitializeDefaultScreens. Actually, I saw that and fixed it about an hour after the release of -49. So, there were two -49 releases, one of them silent. :) I figured the number of users getting the new release within the first hour would be small. -50 has the same fix. 2. Could you add a time-stamp at beginning of each line ? I tried to correspond the log messages with external actions (i.e. copy/paste and Emacs errors) and the time stamp could help. That is an interesting idea. I think we can do something like that because we have a single ErrorF function that handles printing the log messages. We should be able to modify this one function to get timestamps on all entries... but it may not look too pretty since it will mess with multiple-line error messages that come from other parts of the source code. If those lines are printed with multiple ErrorF calls, then things will line up correctly. However, if they are printed with a single call to ErrorF with multiple \n's, then it may not look so good. Of course, we could substitute each \n in the format string (except for the last) with \n%TIME%, which would help to keep things aligned. I dunno... I will have to think about this a bit. I use the code below in my programs. Thanks, this will help. BTW. I could not download 4.3.0-50 from the mirrors yet. Some mirrors update hourly, others daily or every two days. You can try to find a more up-to-date mirror if you like. Harold
multimonitor question
Is there any way to specify the default position of new windows when using: -multimonitors -multiwindow? as it stands, my left hand monitor is at a smaller res then the right, and as the x server put it at 0,0 I have to right click the taskbar and Move the window... this is quite frustrating... is there any solution? Or will I have to download the 200+MB source tree? Thanks ben
Re: Mouse cursor is dissapering.
Hello all, Just to inform you that build 4.0.3-50 has just solved 2 problems for me. The mouse cursors goign on holliday and the windows that appear white. Thanx to the team that made this great app possible. Keep going you guys are doing an excelent job. Geordy Korte
Re: FW: XWin Xserver maximum root area exceeded?
On Wed, 3 Mar 2004, Bonert Brigitte wrote: I am trying to use the prebuilt XWin.exe on a root area of 12800x2048 (20 projectors arranged in 2 rows each with a resolution of 1280x1024) The application on the Unix side (DEC Alpha) uses Pseudo colors so I run with 256 colors only on the special PC which runs a modified WIndows2000 with a special DisplayDriver which supports this resolution (it contains 20 video cards). When I run XWin.exe on my PC and display the pictures of the application on the Unix server everything works just fine (I can have only 256 colors which make for some strange colors) but on the special PC I am getting this error (within the Unix application): X_Error Bad Window (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) Just a guess: Are you using ssh? Try adding ForwardX11Trusted to your .ssh/config file (http://x.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-ssh-no-x11forwarding) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723 Chemnitzer Linux-Tag 2004 - 6. und 7. März 2004 http://www.tu-chemnitz.de/linux/tag
RE: XWin Xserver maximum root area exceeded?
Harold, I am not using OpenSSH to ssh into the UNIX. I am using xdm with a modified startup script from the file: \cygwin\usr\X11R6\bin\startxdmcp.bat see below start XWin :2 -query %REMOTE_HOST% -scrollbars -lesspointer -fp tcp/%REMOTE_HOST%:7100 I do get the login screen and everything comes up just fine (it did not with the previous version of XWin I tried some time ago). It connects also just fine to the fontserver I have running on the remote host. Everything works on my PC (with root area of 1600x1200 and NT service pack 6) when displaying the pictures of the application running on the Unix box. But it does not on the controller with the root area of 12800x2048 (running Windows2000) I get the error below. Which is why I suspect a problem with the size of the root area. I downloaded the code and started looking .. but so far no numbers. I also tried to understand the Xf86config file but did not get far with this. Brigitte -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 03, 2004 8:53 AM To: Bonert Brigitte Subject: Re: XWin Xserver maximum root area exceeded? You know, now that I think about it, if you are using OpenSSH on Cygwin to ssh into the UNIX box, then you are probably having problems do to the new trusted X11 bug^H^H^Hfeature. See the following for more information on how to work around it: http://x.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-ssh-no-x11forwarding Harold Bonert Brigitte wrote: Hi, I am trying to use the prebuilt XWin.exe on a root area of 12800x2048 (20 projectors arranged in 2 rows each with a resolution of 1280x1024) The application on the Unix side (DEC Alpha) uses Pseudo colors so I run with 256 colors only on the special PC which runs a modified WIndows2000 with a special DisplayDriver which supports this resolution (it contains 20 video cards). When run XWin.exe on my PC and display the pictures of the application on the Unix server everything works just fine (I can have only 256 colors which make for some strange colors) but on the special PC I am getting this error (within the Unix application): X_Error Bad Window (invalid Window parameter) Major opcode of failed request: 20 (X_GetProperty) and the application on the Unix box fails to run partially. Is there a max width value I am exceeding and can change and rebuild the executable? I found your Cygwin/X User's Guide excellent and easy to use thank you very much for providing it. What I found too: The XWin.exe does not have an easy way to find out its version or did I miss this? (like XWin.exe --version) Is there a way to define the title of the upcoming server window (I am using xdm on the Unix boxes)? Please let me know Thank you Brigitte Independent Electricity Market Operator * [EMAIL PROTECTED] * 905 855 6102 * This message is intended only for the use of the intended recipients, and it may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message is strictly prohibited. If you are not the intended recipient, please notify me immediately by return e-mail, and delete this message from your system. * * This message is intended only for the use of the intended recipients, and it may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message is strictly prohibited. If you are not the intended recipient, please notify me immediately by return e-mail, and delete this message from your system. *
Re: Mouse cursor is dissapering.
Geordy, Glad it works for you. Thanks for following up. Harold [EMAIL PROTECTED] wrote: Hello all, Just to inform you that build 4.0.3-50 has just solved 2 problems for me. The mouse cursors goign on holliday and the windows that appear white. Thanx to the team that made this great app possible. Keep going you guys are doing an excelent job. Geordy Korte
Re: Feature request: version report
Harold L Hunt II [EMAIL PROTECTED] writes: If you could add some means to manually kill and/or restart the clipboard code inside the X server then I could switch back without the risk of losing work, I would add a manual kill/restart as a last resort in a few months. Until then I would prefer to swat bugs rather than try to work around the problem. I agree that fixing the bugs is better, but as well as testing XWin to find bugs I also try to use it for work, and if Windows apps hang unrecoverably then I can't use the clipboard support. So you may be able to swat bugs faster if users can use the software with less risk. XFree86-xserv-4.3.0-49 has some changes that may help to recover from and/or to prevent the deadlock situations. Please try it and let me know if it improves things or not. Thanks for looking at this - I will try 4.3.0-50. (And try running with -clipboard once again.) -- Ed Avis [EMAIL PROTECTED]
Re: reset/terminate problems; preventing multiple XWin instances
Hi, On 29-02-2004 14:11, Takuma Murakami wrote: As for preventing multiple instances of XWin This feature is already implemented in my local tree (not port based but mutex based detection). I see that it's in 4.3.0-50 and working well, but I don't see how the current implementation addresses the common task I mentioned: open an xterm; run XWin first if needed If I use a batchfile that always runs XWin and then xterm, from the 2nd invocation onwards it will produce the error popup reporting a Fatal error and directing me a to log file... Not quite what's needed here.[1] Perhaps there should be a switch that says if the display already exists, exit silently. But that doesn't solve the case where I want to run additional programs (say, twm and xeyes) whenever a new display is created -- again a common scenario, I believe. One way to solve this is to add an option for checking the presence of an XWin instance on the given display number and exiting immediately with a corresponding errorcode; a batchfile can then check for the existance of an XWin instance, and if negative spawn XWin and related stuff. But this could lead to a race condition if two batchfiles do the check simultaneously. An alternative is to add an option for XWin to run some executable iff its startup succeeded. Yes, I realize this is getting somewhat convoluted, but I think it's an important and common use case. I'm trying to move a certain large group of people to Cygwin/X, and the issue of transparently invoking Cygwin/X is one of the two major issues holding things back (the other one is multiwindow mode performance). Regards, Eran [1] For extra helpfulness, perhaps you could specify the nature of the fatal error at a prominent location inside the dialog box and not just inside the log file?
Re: xemacs over ssh tunneling
On Wed, 3 Mar 2004, Daniel Danger Bentley wrote: Thanks so much for .50. I now have this problem when I run xemacs over ssh tunneling from another computer. It didn't used to happen, and it doesn't if I use, e.g., MI-X. When I try to cut anything in xemacs, I get the error message contained in xerror (attached) and xemacs freezes. Does http://cygwin.com/ml/cygwin-xfree/2004-03/msg00071.html help? Normally, it's recommended that you search the archives, but the search doesn't seem to work for some reason (i.e., searching for xemacs ssh tunneling doesn't return any results in the archives). Google didn't cache this yet either. Also, any easy things I can do to help the codebase? I have some amount of experience in cs type stuff... -Dan I'll let Harold answer this, but, AFAIK, there's a TODO in CVS... 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: XWin Xserver maximum root area exceeded?
Bonert, You have an interesting setup that possibly reveals non-trivial bugs. Unless you will continue to consult Harold privately, please show /tmp/XWin.log from a failed session. Takuma Murakami
x apps and windows XP cmd
This question is a mixed bag of both cygwin xterm knowldge and Windows XP knowledge. I have Xwin started using -multiwindow I can now launch xterm -display 127.0.0.1:0 from the windows xp start-run However in addition to the newly created xterm, there's also a new windows cmd console hanging around. I've tried various things including writing a windows batch file that uses START /B xterm -display 127.0.0.1:0 Is there any possible way to get rid of the extra cmd console? I suppose the xterm has to somehow detach itself from the cmd console or something of that nature. Thanks
Re: multimonitor question
Ben, Please utilize the -geometry option as Igor says. Perhaps you are placing your monitors like the following figure (fixed-width fonts are assumed). +---+--+ | | | | | | | | | +---+ | | | monitor B | | | | | monitor A | | | | | +---+--+ Cygwin/X maps the top-left corner of the whole virtual screen to (0, 0) on which new windows are to be placed. As long as you specify -multimonitors in those situations, you should accept this result and make use of -display option. Of course proposals of better ways of mapping would be appreciated. The true problem is that no matter if -multimonitors is specified or not, some code assume the top-left corner of the whole virtual screen is (0, 0). Therefore users will accidentally lose their new windows though they are willing to use only the primary monitor. Takuma Murakami
Re: x apps and windows XP cmd
Trevor, I can now launch xterm -display 127.0.0.1:0 from the windows xp start-run However in addition to the newly created xterm, there's also a new windows cmd console hanging around. I've tried various things including writing a windows batch file that uses START /B xterm -display 127.0.0.1:0 Is there any possible way to get rid of the extra cmd console? run xterm -display 127.0.0.1:0 is supposed to work. Takuma Murakami
Re: Problems with XDMCP connection
Anton, I'm not sure to fix your problem but could you try these? 1. Update XFree86-xserv. 2. Add -clipboard to your XWin invocation. 3. If the problem remains, send in /tmp/XWin.log . Hope this helps. Takuma Murakami
