From dickey@his.com Wed Sep 1 09:07:00 2010 From: dickey@his.com (Thomas Dickey) Date: Wed, 01 Sep 2010 09:07:00 -0000 Subject: changing font In-Reply-To: References: <20100720134027.M30079@mail101.his.com> <20100830162223.N41005@mail101.his.com> Message-ID: <20100901050234.D82945@mail101.his.com> On Tue, 31 Aug 2010, matias kaukonen wrote: > Yes, it displays the font but it does not set the font. Only the > 'quit' button works. I was asking about the result with xfd to be sure that the font itself is recognized. I don't see anything wrong with the description of your changes to the X resources. Another place to check is whether there are conflicting font resources shown, e.g., using "appres XTerm". Beyond that, I generally just compile xterm with its debugging trace enabled and see what resource value is actually used. It's also possible to get the nominal value of the font using an escape sequence in a script or program such as xtermset. > > On Mon, Aug 30, 2010 at 4:22 PM, Thomas Dickey wrote: >> On Mon, 30 Aug 2010, matias kaukonen wrote: >> >>> The above worked on my previous computer, but now it does not work with my >>> current computer. ?This is what I tried: >>> 1. a) ?Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xdefaults >>> ? b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources >>> >>> next, >>> 2. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xresources >>> ? b) ?typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources >>> >>> But neither one affected the xterm font. >> >> does >> ? ? ? ?xfd -fn lucidasanstypewriter-10 >> >> display the font you asked for? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -------------- next part -------------- -- 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/ From ryanjohn@ece.cmu.edu Wed Sep 1 10:15:00 2010 From: ryanjohn@ece.cmu.edu (Ryan Johnson) Date: Wed, 01 Sep 2010 10:15:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C7D3542.8000605@dronecode.org.uk> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> Message-ID: <4C7E27A1.4010200@ece.cmu.edu> On 8/31/2010 7:00 PM, Jon TURNEY wrote: > Okay, I think I have worked out the correct thing to do do to handle > bpp changes in the RANDR code, and I've uploaded a test build at [1]. > Perhaps you could try it and see if it works for you? > > Note that you will need to use -resize with this build to turn on > RANDR in any mode. > > If you can make this crash, with or without -resize, a backtrace would > be very helpful. > > [1] > ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 > I'll give that a try in the next couple of days. Meanwhile, what kind of backtrace did you mean? Is the .exe.stackdump actually helpful? Ryan -- 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/ From matias.364@gmail.com Wed Sep 1 14:33:00 2010 From: matias.364@gmail.com (matias kaukonen) Date: Wed, 01 Sep 2010 14:33:00 -0000 Subject: changing font In-Reply-To: <20100901050234.D82945@mail101.his.com> References: <20100720134027.M30079@mail101.his.com> <20100830162223.N41005@mail101.his.com> <20100901050234.D82945@mail101.his.com> Message-ID: based on the result of 'appres XTerm', i changed .Xdefaults to: *VT100.utf8Fonts.font:lucidasanstypewriter-10 This worked -- thanks. On Wed, Sep 1, 2010 at 5:06 AM, Thomas Dickey wrote: > On Tue, 31 Aug 2010, matias kaukonen wrote: > >> Yes, it displays the font but it does not set the font. ?Only the >> 'quit' button works. > > I was asking about the result with xfd to be sure that the font itself is > recognized. ?I don't see anything wrong with the description of your changes > to the X resources. > > Another place to check is whether there are conflicting font resources > shown, e.g., using "appres XTerm". > > Beyond that, I generally just compile xterm with its debugging trace > enabled and see what resource value is actually used. ?It's also possible > to get the nominal value of the font using an escape sequence in a script > or program such as xtermset. > >> >> On Mon, Aug 30, 2010 at 4:22 PM, Thomas Dickey wrote: >>> >>> On Mon, 30 Aug 2010, matias kaukonen wrote: >>> >>>> The above worked on my previous computer, but now it does not work with >>>> my >>>> current computer. ?This is what I tried: >>>> 1. a) ?Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xdefaults >>>> ? b) typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources >>>> >>>> next, >>>> 2. a) Added XTerm[.*]vt100.font:lucidasanstypewriter-10 to .Xresources >>>> ? b) ?typed: xrdb ~/.Xdefaults; xrdb ~/.Xresources >>>> >>>> But neither one affected the xterm font. >>> >>> does >>> ? ? ? ?xfd -fn lucidasanstypewriter-10 >>> >>> display the font you asked for? > > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net > > -- > Unsubscribe info: ? ? ?http://cygwin.com/ml/#unsubscribe-simple > Problem reports: ? ? ? http://cygwin.com/problems.html > Documentation: ? ? ? ? http://x.cygwin.com/docs/ > FAQ: ? ? ? ? ? ? ? ? ? http://x.cygwin.com/docs/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Wed Sep 1 17:55:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 01 Sep 2010 17:55:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C7E27A1.4010200@ece.cmu.edu> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> <4C7E27A1.4010200@ece.cmu.edu> Message-ID: <4C7E9367.5050905@dronecode.org.uk> On 01/09/2010 11:14, Ryan Johnson wrote: > On 8/31/2010 7:00 PM, Jon TURNEY wrote: >> Okay, I think I have worked out the correct thing to do do to handle bpp >> changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps >> you could try it and see if it works for you? >> >> Note that you will need to use -resize with this build to turn on RANDR in >> any mode. >> >> If you can make this crash, with or without -resize, a backtrace would be >> very helpful. >> >> [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 >> > I'll give that a try in the next couple of days. Meanwhile, what kind of > backtrace did you mean? Is the .exe.stackdump actually helpful? In theory I believe it's possible to get something from a .stackdump file using addr2line, but a backtrace from gdb is much better. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From marshallst@appstate.edu Wed Sep 1 19:33:00 2010 From: marshallst@appstate.edu (Scott T. Marshall) Date: Wed, 01 Sep 2010 19:33:00 -0000 Subject: No xauth program Message-ID: <4C7EA987.9090006@appstate.edu> Hi All, I am struggling to get my ssh server to forward x windows. I have followed the cygwin documentation several times and cannot get my windows 7 (x64) machine to forward any x windows over ssh. This is particularly frustrating because I set this all up with no problem on my laptop which is also running windows 7 (x64). Here is my short description and info. Please let me know if I need to provide any extra info. I've done extensive web searches and searched the cygwin FAQ's and mailing lists, but can't seem to find a similar problem. I have added "ForwardX11 yes" to /etc/ssh_config I have added "X11Forwarding yes" to /etc/sshd_config I have the XWin server running and am using xterm with the following command (on one line of course) C:\cygwin\bin\run.exe -p /usr/X11R6/bin xterm -display 127.0.0.1:0.0 -ls -g 115x35 +tb -fn 8x16 -sl 1000 -sb -rightbar -ms red -fg yellow -bg black So, my xterm pops up just like normal and I can successfully ssh to localhost, but when I try to open something graphical (e.g xeyes or nedit) I get Error: Cannot open display when I connect using ssh -Yv localhost the last few lines of output are: debug1: Entering interactive session. debug1: No xauth program. Warning: No xauth data; using fake authentication data for X11 forwarding. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Remote: No xauth program; cannot forward with spoofing. Last login: Wed Sep 1 15:03:40 2010 from ::1 I don't understand the No xauth program part. I have xauth in /bin which xauth returns /usr/bin/xauth and when I check the permissions on xauth, I see that they are 755 and I am the owner. I even tried the suggestion that someone made on the listserv to add a line to ~/.ssh/config XauthLocation=/usr/bin/xauth and that didn't work, so I tried XauthLocation=/bin/xauth and that didn't work either. Does anyone have any ideas what is going on here? Any help would be very much appreciated. Cheers, -Scott -- 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/ From jon.turney@dronecode.org.uk Thu Sep 2 15:11:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 02 Sep 2010 15:11:00 -0000 Subject: No xauth program In-Reply-To: <4C7EA987.9090006@appstate.edu> References: <4C7EA987.9090006@appstate.edu> Message-ID: <4C7FBEAD.3020208@dronecode.org.uk> On 01/09/2010 20:29, Scott T. Marshall wrote: > when I connect using > > ssh -Yv localhost > > the last few lines of output are: > > debug1: Entering interactive session. > debug1: No xauth program. > Warning: No xauth data; using fake authentication data for X11 forwarding. > debug1: Requesting X11 forwarding with authentication spoofing. > debug1: Remote: No xauth program; cannot forward with spoofing. > Last login: Wed Sep 1 15:03:40 2010 from ::1 > > I don't understand the No xauth program part. I have xauth in /bin > which xauth > returns > /usr/bin/xauth > and when I check the permissions on xauth, I see that they are 755 and I am > the owner. You might like to try if xauth can actually run successfully? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From marshallst@APPSTATE.EDU Thu Sep 2 18:06:00 2010 From: marshallst@APPSTATE.EDU (Scott T. Marshall) Date: Thu, 02 Sep 2010 18:06:00 -0000 Subject: No xauth program In-Reply-To: <4C7FBEAD.3020208@dronecode.org.uk> References: <4C7EA987.9090006@appstate.edu> <4C7FBEAD.3020208@dronecode.org.uk> Message-ID: <4C7FE53C.1070606@appstate.edu> Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to do or what syntax is requires (the man page was not completely clear to me), but what I can say is that if I try to execute xauth in an xterm, it gives no errors. I can also say that when I ssh to other linux machines, I can open X applications, but my cygwin/windows 7 x64 box will not forward x windows when someone log onto it. -Scott On 9/2/2010 11:11 AM, Jon TURNEY wrote: > On 01/09/2010 20:29, Scott T. Marshall wrote: >> when I connect using >> >> ssh -Yv localhost >> >> the last few lines of output are: >> >> debug1: Entering interactive session. >> debug1: No xauth program. >> Warning: No xauth data; using fake authentication data for X11 >> forwarding. >> debug1: Requesting X11 forwarding with authentication spoofing. >> debug1: Remote: No xauth program; cannot forward with spoofing. >> Last login: Wed Sep 1 15:03:40 2010 from ::1 >> >> I don't understand the No xauth program part. I have xauth in /bin >> which xauth >> returns >> /usr/bin/xauth >> and when I check the permissions on xauth, I see that they are 755 and >> I am >> the owner. > > You might like to try if xauth can actually run successfully? > -- <><><><><><><><><><><><><><><> Scott T. Marshall Department Of Geology Appalachian State University 572 Rivers St. Boone, NC 28608 http://www.appstate.edu/~marshallst/ ftp://pm.appstate.edu/pub/prog/marshallst/ -- 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/ From jon.turney@dronecode.org.uk Thu Sep 2 22:48:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 02 Sep 2010 22:48:00 -0000 Subject: No xauth program In-Reply-To: <4C7FE53C.1070606@appstate.edu> References: <4C7EA987.9090006@appstate.edu> <4C7FBEAD.3020208@dronecode.org.uk> <4C7FE53C.1070606@appstate.edu> Message-ID: <4C8029BD.7010204@dronecode.org.uk> > On 9/2/2010 11:11 AM, Jon TURNEY wrote: >> On 01/09/2010 20:29, Scott T. Marshall wrote: >>> when I connect using >>> >>> ssh -Yv localhost >>> >>> the last few lines of output are: >>> >>> debug1: Entering interactive session. >>> debug1: No xauth program. >>> Warning: No xauth data; using fake authentication data for X11 >>> forwarding. >>> debug1: Requesting X11 forwarding with authentication spoofing. >>> debug1: Remote: No xauth program; cannot forward with spoofing. >>> Last login: Wed Sep 1 15:03:40 2010 from ::1 >>> >>> I don't understand the No xauth program part. I have xauth in /bin >>> which xauth >>> returns >>> /usr/bin/xauth >>> and when I check the permissions on xauth, I see that they are 755 and >>> I am >>> the owner. >> >> You might like to try if xauth can actually run successfully? >> On 02/09/2010 18:56, Scott T. Marshall wrote: > Thanks for the suggestion Jon. I don't know exactly what I should ask xauth to > do or what syntax is requires (the man page was not completely clear to me), > but what I can say is that if I try to execute xauth in an xterm, it gives no > errors. > I can also say that when I ssh to other linux machines, I can open X > applications, but my cygwin/windows 7 x64 box will not forward x windows when > someone log onto it. Hmm... it looks like the latest openssh package has the wrong default path to xauth for some reason. As a workaround, you might try adding XAuthLocation=/usr/bin/xauth to /etc/sshd_config and restarting sshd. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From sneakypete81@gmail.com Fri Sep 3 09:01:00 2010 From: sneakypete81@gmail.com (Pete) Date: Fri, 03 Sep 2010 09:01:00 -0000 Subject: XServer draws to incorrect window when using VirtuaWin In-Reply-To: References: Message-ID: On 13 August 2010 11:38, Pete wrote: > VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop > manager for Windows that lets you switch between several "virtual > desktops", similar to those provided in KDE & Gnome. > > When switching between desktops that have CygwinX windows open, > occasionally the Xserver draws to the wrong window. This is difficult > to describe, so will continue with an example: > > Using Windows 7, Cygwin/X v1.8.0 > > Steps to reproduce: > 1) Install VirtuaWin from?http://virtuawin.sourceforge.net/ > 2) Start the CygwinX server > 3) Open a (DOS) cygwin window > 4) Type "xterm &" twice, to open two xterm windows. Maximise these two > windows to full screen. > 5) Move one of these windows to desktop2 > 6) Type "ping google.com -n 1000" to get a stream of data appearing in > the xterm window on desktop2 > 7) Go back to desktop1, and make sure the DOS cygwin window is selected > 8) Switch back to desktop2. The "ping" xterm window should be selected. > 9) Switch back to desktop1. The cygwin window should be selected. > > What should happen: > The empty xterm session on desktop1 should be displayed in the window > behind the cygwin window > > What happens: > The ping data stream appears in the xterm window on desktop1, and > continues receiving updates every second. > Selecting the xterm window causes the ping data to disappear and the > empty xterm session to be displayed correctly. > > This is reproducible every time. The critical thing is that if the > xterm window on desktop1 is not selected after a desktop switch, it > shows the data from the xterm window on desktop 2. > > FWIW, this problem doesn't exist with xming, and I haven't seen the > issue with any other applications. > > Any questions, please let me know. > Thanks, > Pete > Is there anything else I can do to help debug this? Unfortunately it is necessary to install VirtuaWin to reproduce the issue, but it's very reproducible. -- 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/ From marshallst@appstate.edu Fri Sep 3 16:50:00 2010 From: marshallst@appstate.edu (Scott T. Marshall) Date: Fri, 03 Sep 2010 16:50:00 -0000 Subject: No xauth program In-Reply-To: <4C8029BD.7010204@dronecode.org.uk> References: <4C7EA987.9090006@appstate.edu> <4C7FBEAD.3020208@dronecode.org.uk> <4C7FE53C.1070606@appstate.edu> <4C8029BD.7010204@dronecode.org.uk> Message-ID: <4C812520.8080601@appstate.edu> Brilliant!!! That did the trick. Thanks so much. This was really driving me crazy. Cheers, -Scott On 9/2/2010 6:48 PM, Jon TURNEY wrote: >> On 9/2/2010 11:11 AM, Jon TURNEY wrote: >>> On 01/09/2010 20:29, Scott T. Marshall wrote: >>>> when I connect using >>>> >>>> ssh -Yv localhost >>>> >>>> the last few lines of output are: >>>> >>>> debug1: Entering interactive session. >>>> debug1: No xauth program. >>>> Warning: No xauth data; using fake authentication data for X11 >>>> forwarding. >>>> debug1: Requesting X11 forwarding with authentication spoofing. >>>> debug1: Remote: No xauth program; cannot forward with spoofing. >>>> Last login: Wed Sep 1 15:03:40 2010 from ::1 >>>> >>>> I don't understand the No xauth program part. I have xauth in /bin >>>> which xauth >>>> returns >>>> /usr/bin/xauth >>>> and when I check the permissions on xauth, I see that they are 755 and >>>> I am >>>> the owner. >>> >>> You might like to try if xauth can actually run successfully? >>> > On 02/09/2010 18:56, Scott T. Marshall wrote: >> Thanks for the suggestion Jon. I don't know exactly what I should ask >> xauth to >> do or what syntax is requires (the man page was not completely clear >> to me), >> but what I can say is that if I try to execute xauth in an xterm, it >> gives no >> errors. >> I can also say that when I ssh to other linux machines, I can open X >> applications, but my cygwin/windows 7 x64 box will not forward x >> windows when >> someone log onto it. > > Hmm... it looks like the latest openssh package has the wrong default > path to xauth for some reason. > > As a workaround, you might try adding XAuthLocation=/usr/bin/xauth to > /etc/sshd_config and restarting sshd. > -- <><><><><><><><><><><><><><><> Scott T. Marshall Department Of Geology Appalachian State University 572 Rivers St. Boone, NC 28608 http://www.appstate.edu/~marshallst/ ftp://pm.appstate.edu/pub/prog/marshallst/ -- 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/ From ryanjohn@ece.cmu.edu Fri Sep 3 23:10:00 2010 From: ryanjohn@ece.cmu.edu (Ryan Johnson) Date: Fri, 03 Sep 2010 23:10:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C7D3542.8000605@dronecode.org.uk> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> Message-ID: <4C818051.3020102@ece.cmu.edu> On 8/31/2010 7:00 PM, Jon TURNEY wrote: > Okay, I think I have worked out the correct thing to do do to handle > bpp changes in the RANDR code, and I've uploaded a test build at [1]. > Perhaps you could try it and see if it works for you? > > Note that you will need to use -resize with this build to turn on > RANDR in any mode. > > If you can make this crash, with or without -resize, a backtrace would > be very helpful. > > [1] > ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 > So far so good... I've switched monitors several times without problems (both with -resize and without). Thanks! Ryan -- 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/ From ryanjohn@ece.cmu.edu Mon Sep 6 21:01:00 2010 From: ryanjohn@ece.cmu.edu (Ryan Johnson) Date: Mon, 06 Sep 2010 21:01:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C7D3542.8000605@dronecode.org.uk> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> Message-ID: <4C855696.4060204@ece.cmu.edu> On 8/31/2010 7:00 PM, Jon TURNEY wrote: > Okay, I think I have worked out the correct thing to do do to handle > bpp changes in the RANDR code, and I've uploaded a test build at [1]. > Perhaps you could try it and see if it works for you? > > Note that you will need to use -resize with this build to turn on > RANDR in any mode. > > If you can make this crash, with or without -resize, a backtrace would > be very helpful. > > [1] > ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 Hmm.. I don't get seg faults while resizing, but every once in a while I'll alt-tab to an xterm and start typing, only to have the xterm evaporate. Once it also happened to emacs, which left both emacs and the terminal pretty well unusable. Unfortunately, I don't get a stack trace or any messages in /var/log/XWin.*.log. It just goes away. I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling back to it. I'll holler if the problem continues. Ideas? Ryan -- 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/ From ryanjohn@ece.cmu.edu Mon Sep 6 21:38:00 2010 From: ryanjohn@ece.cmu.edu (Ryan Johnson) Date: Mon, 06 Sep 2010 21:38:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C855696.4060204@ece.cmu.edu> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> <4C855696.4060204@ece.cmu.edu> Message-ID: <4C855F43.30102@ece.cmu.edu> On 9/6/2010 11:01 PM, Ryan Johnson wrote: > On 8/31/2010 7:00 PM, Jon TURNEY wrote: >> Okay, I think I have worked out the correct thing to do do to handle >> bpp changes in the RANDR code, and I've uploaded a test build at >> [1]. Perhaps you could try it and see if it works for you? >> >> Note that you will need to use -resize with this build to turn on >> RANDR in any mode. >> >> If you can make this crash, with or without -resize, a backtrace >> would be very helpful. >> >> [1] >> ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 > Hmm.. I don't get seg faults while resizing, but every once in a while > I'll alt-tab to an xterm and start typing, only to have the xterm > evaporate. Once it also happened to emacs, which left both emacs and > the terminal pretty well unusable. Unfortunately, I don't get a stack > trace or any messages in /var/log/XWin.*.log. It just goes away. > > I'd never seen this behavior with 1.8.2-0 (or earlier), so I'm rolling > back to it. I'll holler if the problem continues. Oops. It just happened for 1.8.2-0 and for diff.exe. I've posted the issue to the cygwin mailing list because it doesn't seem x-related if diff.exe dies... Ryan -- 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/ From pyroklastiqflow@aol.com Tue Sep 7 03:30:00 2010 From: pyroklastiqflow@aol.com (Michael) Date: Tue, 07 Sep 2010 03:30:00 -0000 Subject: frequently getting a =?utf-8?b?U1RBVFVTX0FDQ0VTU19WSU9MQVRJT04=?= exception under win7 References: Message-ID: I was having this same issue. Cygwin Xserver was working properly under Win XP, but the fork failure began occuring when I migrated to Win 7 Home Premium 32-bit. My issue was Microsoft Security Essentials was set to default which allows it to real time scan all files/directories/real-time processes. If you are also running this, I guarantee it is your problem (or at least one of them). To resolve, open Security Essentials and navigate to the settings tab. Under the "Excluded files & locations" menu, add the cygwin root directory (C:\cygwin\ if you used the default install config). Under excluded processes, add startx.exe, startxwin.exe, xterm.exe, and Cygwin.bat. These files will all be in the C:\cygwin\ and C:\cygwin\bin\ directories. Save the changes to the firewall and give it a shot. -- 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/ From jon.turney@dronecode.org.uk Tue Sep 7 13:38:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 07 Sep 2010 13:38:00 -0000 Subject: XServer draws to incorrect window when using VirtuaWin In-Reply-To: References: Message-ID: <4C864040.4060807@dronecode.org.uk> On 03/09/2010 10:01, Pete wrote: > On 13 August 2010 11:38, Pete wrote: >> VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop >> manager for Windows that lets you switch between several "virtual >> desktops", similar to those provided in KDE& Gnome. >> >> When switching between desktops that have CygwinX windows open, >> occasionally the Xserver draws to the wrong window. This is difficult >> to describe, so will continue with an example: I'm afraid I think this falls into the category of "known problems", see [1]. The tricks that XWin uses to implement multiwindow mode don't seem to be compatible with the tricks that VirtuaWin uses to implement multiple desktops. [1] https://bugs.freedesktop.org/show_bug.cgi?id=21540 >> Using Windows 7, Cygwin/X v1.8.0 >> >> Steps to reproduce: >> 1) Install VirtuaWin from http://virtuawin.sourceforge.net/ >> 2) Start the CygwinX server >> 3) Open a (DOS) cygwin window >> 4) Type "xterm&" twice, to open two xterm windows. Maximise these two >> windows to full screen. >> 5) Move one of these windows to desktop2 >> 6) Type "ping google.com -n 1000" to get a stream of data appearing in >> the xterm window on desktop2 >> 7) Go back to desktop1, and make sure the DOS cygwin window is selected >> 8) Switch back to desktop2. The "ping" xterm window should be selected. >> 9) Switch back to desktop1. The cygwin window should be selected. >> >> What should happen: >> The empty xterm session on desktop1 should be displayed in the window >> behind the cygwin window >> >> What happens: >> The ping data stream appears in the xterm window on desktop1, and >> continues receiving updates every second. >> Selecting the xterm window causes the ping data to disappear and the >> empty xterm session to be displayed correctly. >> >> This is reproducible every time. The critical thing is that if the >> xterm window on desktop1 is not selected after a desktop switch, it >> shows the data from the xterm window on desktop 2. >> >> FWIW, this problem doesn't exist with xming, and I haven't seen the >> issue with any other applications. Xming version number, please? > Is there anything else I can do to help debug this? Unfortunately it > is necessary to install VirtuaWin to reproduce the issue, but it's > very reproducible. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Tue Sep 7 13:51:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 07 Sep 2010 13:51:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C818051.3020102@ece.cmu.edu> References: <4C606FBA.90704@ece.cmu.edu> <4C607B0B.4000401@dronecode.org.uk> <4C60E813.9070208@ece.cmu.edu> <4C64173D.30702@dronecode.org.uk> <4C64180A.20108@ece.cmu.edu> <4C641C58.3000608@dronecode.org.uk> <4C7D3542.8000605@dronecode.org.uk> <4C818051.3020102@ece.cmu.edu> Message-ID: <4C864329.7070907@dronecode.org.uk> On 04/09/2010 00:10, Ryan Johnson wrote: > On 8/31/2010 7:00 PM, Jon TURNEY wrote: >> Okay, I think I have worked out the correct thing to do do to handle bpp >> changes in the RANDR code, and I've uploaded a test build at [1]. Perhaps >> you could try it and see if it works for you? >> >> Note that you will need to use -resize with this build to turn on RANDR in >> any mode. >> >> If you can make this crash, with or without -resize, a backtrace would be >> very helpful. >> >> [1] ftp://cygwin.com/pub/cygwinx/XWin.20100831-git-5fa9c90425fb1d68.exe.bz2 >> > So far so good... I've switched monitors several times without problems (both > with -resize and without). Good news, thanks for testing! :-) -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From sneakypete81@gmail.com Tue Sep 7 15:54:00 2010 From: sneakypete81@gmail.com (Pete) Date: Tue, 07 Sep 2010 15:54:00 -0000 Subject: XServer draws to incorrect window when using VirtuaWin In-Reply-To: <4C864040.4060807@dronecode.org.uk> References: <4C864040.4060807@dronecode.org.uk> Message-ID: On 7 September 2010 14:38, Jon TURNEY wrote: > On 03/09/2010 10:01, Pete wrote: >> On 13 August 2010 11:38, Pete ?wrote: >>> >>> VirtuaWin (http://virtuawin.sourceforge.net/) is a virtual desktop >>> manager for Windows that lets you switch between several "virtual >>> desktops", similar to those provided in KDE& ?Gnome. >>> >>> When switching between desktops that have CygwinX windows open, >>> occasionally the Xserver draws to the wrong window. This is difficult >>> to describe, so will continue with an example: > > I'm afraid I think this falls into the category of "known problems", see > [1]. > > The tricks that XWin uses to implement multiwindow mode don't seem to be > compatible with the tricks that VirtuaWin uses to implement multiple > desktops. > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=21540 Thanks for your reply. You're right, this is the same issue. I'll update the bug. > >>> Using Windows 7, Cygwin/X v1.8.0 >>> >>> Steps to reproduce: >>> 1) Install VirtuaWin from http://virtuawin.sourceforge.net/ >>> 2) Start the CygwinX server >>> 3) Open a (DOS) cygwin window >>> 4) Type "xterm&" twice, to open two xterm windows. Maximise these two >>> windows to full screen. >>> 5) Move one of these windows to desktop2 >>> 6) Type "ping google.com -n 1000" to get a stream of data appearing in >>> the xterm window on desktop2 >>> 7) Go back to desktop1, and make sure the DOS cygwin window is selected >>> 8) Switch back to desktop2. The "ping" xterm window should be selected. >>> 9) Switch back to desktop1. The cygwin window should be selected. >>> >>> What should happen: >>> The empty xterm session on desktop1 should be displayed in the window >>> behind the cygwin window >>> >>> What happens: >>> The ping data stream appears in the xterm window on desktop1, and >>> continues receiving updates every second. >>> Selecting the xterm window causes the ping data to disappear and the >>> empty xterm session to be displayed correctly. >>> >>> This is reproducible every time. The critical thing is that if the >>> xterm window on desktop1 is not selected after a desktop switch, it >>> shows the data from the xterm window on desktop 2. >>> >>> FWIW, this problem doesn't exist with xming, and I haven't seen the >>> issue with any other applications. > > Xming version number, please? It was 6.9.0.31. -- 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/ From flxmra@inwind.it Wed Sep 8 15:24:00 2010 From: flxmra@inwind.it (flxmra@inwind.it) Date: Wed, 08 Sep 2010 15:24:00 -0000 Subject: Comment on Todo List Message-ID: <27282275.4643201283959477794.JavaMail.defaultUser@defaultHost> Good morning, I'm a cygwin/x user and I installed it on a Windows Server 2003 R2 Terminal Server, so that several users can start X sessions from their machines. Of course as soon as I started using cygwin/x the problem occured: how to automatically assign the first free display? And so after some googling I read the Todo List topic "Automatically assign display number", dated 2004. I understood this functionality is not available yet and maybe it's not under analysis. But it would really be a very useful functionality, for the scenario I'm coping with. In the meanwhile, I implemented a workaround (not so elegant, I know): I created a batch script doing the following: - access to c:\cygwin\tmp\.x11-unix - execute the loop FOR k = 0 TO 100 with step 1 - for each k, if the file Xk exists in the directory the loop continues, otherwise we have found the first free display and the loop breaks - execute the command: c:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c "/usr/bin/XWin.exe :k" If you like you can publish this workaround and, if interested, I can send the batch or write the exact content (I switched off my virtual machine, so I don't have it right now). Great work with the project. Bye, Mauro. -- 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/ From ostroffjh@sbcglobal.net Thu Sep 9 23:45:00 2010 From: ostroffjh@sbcglobal.net (Jack Ostroff) Date: Thu, 09 Sep 2010 23:45:00 -0000 Subject: odd case of "Can't connect to display" Message-ID: <1284075889.11622.1@ffortso4> I'm doing "ssh user@host -X" to get to my linux desktop machine from my laptop running Cygwin under Windows Vista. I've been doing this for several months, and I know the basic setup is fine, because I can run any X program without problems. However, just today, after being logged in for a while, even if I have another X program running (in background - so I'm using the same xterm I used to launch to other X program) I get "Error: Can't open display: localhost:10.0" (Yes, DISPLAY is correctly set to localhost:10.0.) If I log out of the ssh session and start a new one, X programs work again, but after a few minutes, it goes back to the error. I am assuming that if the network (wireless from laptop to router, wired from router to switch to desktop) were flaky, the ssh connection would probably be affected, and the other running X program (sometimes emacs, sometimes balsa email client) would also get dropped, but they both continue running with no apparent problems. I'd appreciate any ideas of how to troubleshoot what might be causing this, since it is certainly annoying. I've done a fair amount of searching, but everything I've found so far is a problem with getting either X running at all, or getting ssh to handle X, neither of which is my problem. Thanks for any hints or suggestions. Jack -- 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/ From chuckh1958@gmail.com Fri Sep 10 19:04:00 2010 From: chuckh1958@gmail.com (Chuck) Date: Fri, 10 Sep 2010 19:04:00 -0000 Subject: cygwin/X and nVidia nview multiple desktops Message-ID: Is there any way to get cygwin/X windows to move to another virtual desktop using nView? When I try, the window just remains visible on all desktops. -- 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/ From ozgurmurath@gmail.com Tue Sep 14 08:15:00 2010 From: ozgurmurath@gmail.com (Ozgur Murat Homurlu) Date: Tue, 14 Sep 2010 08:15:00 -0000 Subject: Keyboard layout is not automatically detected. Message-ID: Hi, My keyboard layout is not automatically detected. Relevant info according to your FAQ is below: /var/log/XWin.0.log : [ 4704.046] (--) Windows keyboard layout: "0000041F" (0000041f) "Turkish Q", type 4 [ 4704.046] (EE) Keyboardlayout "Turkish Q" (0000041F) is unknown, using X server default layout "setxkbmap tr" command fixes layout problem. Link of description of the layout: http://www.microsoft.com/resources/msdn/goglobal/keyboards/kbdtuq.htm Thanks, ?zg?r -- 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/ From reedfish@ix.netcom.com Tue Sep 14 17:51:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Tue, 14 Sep 2010 17:51:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <21008309.1284486680053.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> I've been using Cygwin X trouble-free for years, and am running the latest distribution of X and the Cygwin1.dll for at least two weeks (since the Cygwin 1.7.7.1 release). It's been fine until this morning when it started locking on me whenever I used the mouse to highlight text. I have NO IDEA what changed on my system to now cause this behavior. **ANY** help you can give to assist me would be most appreciated since I use it for all my development efforts. I tried re-installing both Base Cygwin and all of the X components but it made no difference. Attached are a cygcheck.out, an XWin strace (zipped) made while engaging the error, and also the XWin log. Thanks! Brian Kelly -------------- next part -------------- A non-text attachment was scrubbed... Name: cygcheck.out Type: application/octet-stream Size: 237678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin.0.log Type: application/octet-stream Size: 2847 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Tue Sep 14 18:38:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 14 Sep 2010 18:38:00 -0000 Subject: Keyboard layout is not automatically detected. In-Reply-To: References: Message-ID: <4C8FC0FC.2040805@dronecode.org.uk> On 14/09/2010 09:15, Ozgur Murat Homurlu wrote: > My keyboard layout is not automatically detected. Relevant info > according to your FAQ is below: > > /var/log/XWin.0.log : > > [ 4704.046] (--) Windows keyboard layout: "0000041F" (0000041f) > "Turkish Q", type 4 > [ 4704.046] (EE) Keyboardlayout "Turkish Q" (0000041F) is unknown, > using X server default layout > > "setxkbmap tr" command fixes layout problem. Thanks for reporting this, and the information necessary to fix it Patch to follow to add automatic detection for "Turkish Q" and "Turkish F" keyboard layouts Hopefully, this should get added to the next X server release -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Tue Sep 14 18:39:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 14 Sep 2010 18:39:00 -0000 Subject: [PATCH] Cygwin/X: Add turkish keyboard layouts to keyboard layout mapping table In-Reply-To: <4C8FC0FC.2040805@dronecode.org.uk> References: <4C8FC0FC.2040805@dronecode.org.uk> Message-ID: <1284489560-5588-1-git-send-email-jon.turney@dronecode.org.uk> 0x0000041f "Turkish Q" => layout tr 0x0001041f "Turkish F" => layout tr variant f Signed-off-by: Jon TURNEY --- hw/xwin/winlayouts.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/xwin/winlayouts.h b/hw/xwin/winlayouts.h index f5397e3..d7a9f27 100644 --- a/hw/xwin/winlayouts.h +++ b/hw/xwin/winlayouts.h @@ -81,6 +81,8 @@ WinKBLayoutRec winKBLayouts[] = { 0x816, -1, "pc105", "pt", NULL, NULL, "Portuguese (Portugal)"}, { 0x41a, -1, "pc105", "hr", NULL, NULL, "Croatian"}, { 0x41d, -1, "pc105", "se", NULL, NULL, "Swedish (Sweden)"}, + { 0x41f, -1, "pc105", "tr", NULL, NULL, "Turkish (Q)"}, + {0x1041f, -1, "pc105", "tr", "f", NULL, "Turkish (F)"}, { 0x424, -1, "pc105", "si", NULL, NULL, "Slovenian"}, { 0x425, -1, "pc105", "ee", NULL, NULL, "Estonian"}, { 0x452, -1, "pc105", "gb", "intl", NULL, "United Kingdom (Extended)"}, -- 1.7.1 -- 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/ From jon.turney@dronecode.org.uk Tue Sep 14 18:47:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 14 Sep 2010 18:47:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text In-Reply-To: <21008309.1284486680053.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> References: <21008309.1284486680053.JavaMail.root@elwamui-darkeyed.atl.sa.earthlink.net> Message-ID: <4C8FC343.2080002@dronecode.org.uk> On 14/09/2010 18:51, Brian Kelly wrote: > I've been using Cygwin X trouble-free for years, and am running the latest > distribution of X and the Cygwin1.dll for at least two weeks (since the > Cygwin 1.7.7.1 release). It's been fine until this morning when it started > locking on me whenever I used the mouse to highlight text. I have NO IDEA > what changed on my system to now cause this behavior. **ANY** help you can > give to assist me would be most appreciated since I use it for all my > development efforts. This is very likely to be some sort of problem with the clipboard integration code. You might find that using the '-noclipboard' option works around the problem (at the cost of not being able to cut/paste between Windows and X apps). An xserver log with '-logverbose 3' might shed a bit more light on what's going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From reedfish@ix.netcom.com Tue Sep 14 19:52:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Tue, 14 Sep 2010 19:52:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <945831.1284493955409.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Thanks Jon for the quick reply. I attached a new log file generated with an attempt to highlight - followed by the "hang". Again, this worked PERFECTLY just yesterday. I ran a chkdsk on my system just about an hour ago, and while it repaired a few files, the problem remains. I'll try your -noclipboard suggestion, but unfortunately for me, I do a lot of pasting back and forth between cygwin and native windows. I may have to go back to using the CMD based bash shell console window that is the cygwin default. Not relishing that thought ... Re-imaging my machine is not really an option either - that could set me back a "week". Brian Kelly -----Original Message----- >From: Jon TURNEY >Sent: Sep 14, 2010 1:47 PM >Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text > >On 14/09/2010 18:51, Brian Kelly wrote: >> I've been using Cygwin X trouble-free for years, and am running the latest >> distribution of X and the Cygwin1.dll for at least two weeks (since the >> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >> locking on me whenever I used the mouse to highlight text. I have NO IDEA >> what changed on my system to now cause this behavior. **ANY** help you can >> give to assist me would be most appreciated since I use it for all my >> development efforts. > >This is very likely to be some sort of problem with the clipboard integration >code. > >You might find that using the '-noclipboard' option works around the problem >(at the cost of not being able to cut/paste between Windows and X apps). > >An xserver log with '-logverbose 3' might shed a bit more light on what's >going on. > >-- >Jon TURNEY >Volunteer Cygwin/X X Server maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin.0.log Type: application/octet-stream Size: 4151 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From reedfish@ix.netcom.com Tue Sep 14 20:06:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Tue, 14 Sep 2010 20:06:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <18144233.1284494731515.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Also - tried GVim, and it locked when I only got one character highlighted. Tried minTTY, and it works perfectly (of course it's not X-based). The cut-and-paste works flawlessly. Again, why "X" highlighting and cut-and-paste worked yesterday and not today is the real mystery. The machine has been rebooted numerous times as well - to no avail. Brian Kelly -----Original Message----- >From: Brian Kelly >Sent: Sep 14, 2010 2:52 PM >Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text > >Thanks Jon for the quick reply. I attached a new log file generated with an attempt to highlight - followed by the "hang". > >Again, this worked PERFECTLY just yesterday. I ran a chkdsk on my system just about an hour ago, and while it repaired a few files, the problem remains. > >I'll try your -noclipboard suggestion, but unfortunately for me, I do a lot of pasting back and forth between cygwin and native windows. I may have to go back to using the CMD based bash shell console window that is the cygwin default. > >Not relishing that thought ... > >Re-imaging my machine is not really an option either - that could set me back a "week". > >Brian Kelly > > > >-----Original Message----- >>From: Jon TURNEY >>Sent: Sep 14, 2010 1:47 PM > >>Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text >> >>On 14/09/2010 18:51, Brian Kelly wrote: >>> I've been using Cygwin X trouble-free for years, and am running the latest >>> distribution of X and the Cygwin1.dll for at least two weeks (since the >>> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >>> locking on me whenever I used the mouse to highlight text. I have NO IDEA >>> what changed on my system to now cause this behavior. **ANY** help you can >>> give to assist me would be most appreciated since I use it for all my >>> development efforts. >> >>This is very likely to be some sort of problem with the clipboard integration >>code. >> >>You might find that using the '-noclipboard' option works around the problem >>(at the cost of not being able to cut/paste between Windows and X apps). >> >>An xserver log with '-logverbose 3' might shed a bit more light on what's >>going on. >> >>-- >>Jon TURNEY >>Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From reply-to-list-only-lh-x@cygwin.com Tue Sep 14 20:12:00 2010 From: reply-to-list-only-lh-x@cygwin.com (Larry Hall (Cygwin X)) Date: Tue, 14 Sep 2010 20:12:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text In-Reply-To: <18144233.1284494731515.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> References: <18144233.1284494731515.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Message-ID: <4C8FD72F.1020308@cygwin.com> On 9/14/2010 4:05 PM, Brian Kelly wrote: > Also - tried GVim, and it locked when I only got one character highlighted. > Tried minTTY, and it works perfectly (of course it's not X-based). The > cut-and-paste works flawlessly. > > Again, why "X" highlighting and cut-and-paste worked yesterday and not today > is the real mystery. The machine has been rebooted numerous times as well - > to no avail. You might want to look at what Windows, virus, and spyware updates occurred recently. It's also possible this is interference from BLODA. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _____________________________________________________________________ A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting annoying in email? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From reedfish@ix.netcom.com Tue Sep 14 20:14:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Tue, 14 Sep 2010 20:14:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <4739900.1284495209752.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Jon - I tried the -noclipboard option, and you were right. I can now highlight and cut-and-paste within the X environment. Hope that helps you. In the meantime, I will use minTTY, and try to get along without X-based GVim. I sure "hope" you can find something to correct. I will cooperate and try to give you anything you need from me that might assist. Thanks, Brian Kelly -----Original Message----- >From: Jon TURNEY >Sent: Sep 14, 2010 1:47 PM >Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text > >On 14/09/2010 18:51, Brian Kelly wrote: >> I've been using Cygwin X trouble-free for years, and am running the latest >> distribution of X and the Cygwin1.dll for at least two weeks (since the >> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >> locking on me whenever I used the mouse to highlight text. I have NO IDEA >> what changed on my system to now cause this behavior. **ANY** help you can >> give to assist me would be most appreciated since I use it for all my >> development efforts. > >This is very likely to be some sort of problem with the clipboard integration >code. > >You might find that using the '-noclipboard' option works around the problem >(at the cost of not being able to cut/paste between Windows and X apps). > >An xserver log with '-logverbose 3' might shed a bit more light on what's >going on. > >-- >Jon TURNEY >Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From ssk288@gmail.com Wed Sep 15 10:56:00 2010 From: ssk288@gmail.com (Sudhir S Kudva) Date: Wed, 15 Sep 2010 10:56:00 -0000 Subject: Important letter about the acc's expiration from Yahoo's anti-spam bot Message-ID: -- 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/ From jon.turney@dronecode.org.uk Wed Sep 15 12:13:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 15 Sep 2010 12:13:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text In-Reply-To: <945831.1284493955409.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> References: <945831.1284493955409.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Message-ID: <4C90B865.9050701@dronecode.org.uk> On 14/09/2010 20:52, Brian Kelly wrote: > Thanks Jon for the quick reply. I attached a new log file generated with > an attempt to highlight - followed by the "hang". Can you please attach an X server log generated with the additional server option '-logverbose 3' Can you be more detailed about what you mean by a 'hang'? Does just the X server application become unresponsive? or your whole system? > Again, this worked PERFECTLY just yesterday. I understood the first time. I would suggest that something has changed on your system to cause this change in behaviour, but you are best placed to find out what that is. > -----Original Message----- >> From: Jon TURNEY >> Sent: Sep 14, 2010 1:47 PM > >> Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text >> >> On 14/09/2010 18:51, Brian Kelly wrote: >>> I've been using Cygwin X trouble-free for years, and am running the latest >>> distribution of X and the Cygwin1.dll for at least two weeks (since the >>> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >>> locking on me whenever I used the mouse to highlight text. I have NO IDEA >>> what changed on my system to now cause this behavior. **ANY** help you can >>> give to assist me would be most appreciated since I use it for all my >>> development efforts. >> >> This is very likely to be some sort of problem with the clipboard integration >> code. >> >> You might find that using the '-noclipboard' option works around the problem >> (at the cost of not being able to cut/paste between Windows and X apps). >> >> An xserver log with '-logverbose 3' might shed a bit more light on what's >> going on. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From reedfish@ix.netcom.com Wed Sep 15 16:12:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Wed, 15 Sep 2010 16:12:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <29725467.1284567139489.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> See attached log run with XWin -logverbose 3 Only the X System hangs - not the whole PC. Other apps continue to work fine. However, **while** the X system is hung, mintty loses it's cut-and-paste capabilities. Once Windows or I with /bin/kill, stop the X system, mintty can once again cut-and-paste (without any need to restart the app). I did have a system failure caused by a VPN memory clash that caused a "blue screen of death" and instant system shutdown. It seems my X-Windows problem began after that episode. I don't know if that is germane, but it's all I can think of as a potential causal contributor. Thanks Jon -----Original Message----- >From: Jon TURNEY >Sent: Sep 15, 2010 7:13 AM >Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text > >On 14/09/2010 20:52, Brian Kelly wrote: >> Thanks Jon for the quick reply. I attached a new log file generated with >> an attempt to highlight - followed by the "hang". > >Can you please attach an X server log generated with the additional server >option '-logverbose 3' > >Can you be more detailed about what you mean by a 'hang'? Does just the X >server application become unresponsive? or your whole system? > >> Again, this worked PERFECTLY just yesterday. > >I understood the first time. > >I would suggest that something has changed on your system to cause this change >in behaviour, but you are best placed to find out what that is. > >> -----Original Message----- >>> From: Jon TURNEY >>> Sent: Sep 14, 2010 1:47 PM >> >>> Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text >>> >>> On 14/09/2010 18:51, Brian Kelly wrote: >>>> I've been using Cygwin X trouble-free for years, and am running the latest >>>> distribution of X and the Cygwin1.dll for at least two weeks (since the >>>> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >>>> locking on me whenever I used the mouse to highlight text. I have NO IDEA >>>> what changed on my system to now cause this behavior. **ANY** help you can >>>> give to assist me would be most appreciated since I use it for all my >>>> development efforts. >>> >>> This is very likely to be some sort of problem with the clipboard integration >>> code. >>> >>> You might find that using the '-noclipboard' option works around the problem >>> (at the cost of not being able to cut/paste between Windows and X apps). >>> >>> An xserver log with '-logverbose 3' might shed a bit more light on what's >>> going on. > >-- >Jon TURNEY >Volunteer Cygwin/X X Server maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin.0.log Type: application/octet-stream Size: 5152 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From reedfish@ix.netcom.com Wed Sep 15 16:21:00 2010 From: reedfish@ix.netcom.com (Brian Kelly) Date: Wed, 15 Sep 2010 16:21:00 -0000 Subject: Latest Cygwin X hangs when mouse is used to highlight text Message-ID: <9710000.1284567691050.JavaMail.root@elwamui-rustique.atl.sa.earthlink.net> Also, notepad can't paste while the X system is in the "hung" condition. Once it's killed, paste in notepad returns. I can send you the "Dr. Watson" error reports generated by Windows when it kills the "Non-Responsive" app - if you would find them at all helpful. Brian -----Original Message----- >From: Brian Kelly >Sent: Sep 15, 2010 11:12 AM >Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text > >See attached log run with XWin -logverbose 3 > >Only the X System hangs - not the whole PC. Other apps continue to work fine. However, **while** the X system is hung, mintty loses it's cut-and-paste capabilities. Once Windows or I with /bin/kill, stop the X system, mintty can once again cut-and-paste (without any need to restart the app). > >I did have a system failure caused by a VPN memory clash that caused a "blue screen of death" and instant system shutdown. It seems my X-Windows problem began after that episode. I don't know if that is germane, but it's all I can think of as a potential causal contributor. > >Thanks Jon > > >-----Original Message----- >>From: Jon TURNEY >>Sent: Sep 15, 2010 7:13 AM > >>Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text >> >>On 14/09/2010 20:52, Brian Kelly wrote: >>> Thanks Jon for the quick reply. I attached a new log file generated with >>> an attempt to highlight - followed by the "hang". >> >>Can you please attach an X server log generated with the additional server >>option '-logverbose 3' >> >>Can you be more detailed about what you mean by a 'hang'? Does just the X >>server application become unresponsive? or your whole system? >> >>> Again, this worked PERFECTLY just yesterday. >> >>I understood the first time. >> >>I would suggest that something has changed on your system to cause this change >>in behaviour, but you are best placed to find out what that is. >> >>> -----Original Message----- >>>> From: Jon TURNEY >>>> Sent: Sep 14, 2010 1:47 PM >>> >>>> Subject: Re: Latest Cygwin X hangs when mouse is used to highlight text >>>> >>>> On 14/09/2010 18:51, Brian Kelly wrote: >>>>> I've been using Cygwin X trouble-free for years, and am running the latest >>>>> distribution of X and the Cygwin1.dll for at least two weeks (since the >>>>> Cygwin 1.7.7.1 release). It's been fine until this morning when it started >>>>> locking on me whenever I used the mouse to highlight text. I have NO IDEA >>>>> what changed on my system to now cause this behavior. **ANY** help you can >>>>> give to assist me would be most appreciated since I use it for all my >>>>> development efforts. >>>> >>>> This is very likely to be some sort of problem with the clipboard integration >>>> code. >>>> >>>> You might find that using the '-noclipboard' option works around the problem >>>> (at the cost of not being able to cut/paste between Windows and X apps). >>>> >>>> An xserver log with '-logverbose 3' might shed a bit more light on what's >>>> going on. >> >>-- >>Jon TURNEY >>Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From kylenix@gmail.com Thu Sep 16 23:56:00 2010 From: kylenix@gmail.com (Kyle Zhou) Date: Thu, 16 Sep 2010 23:56:00 -0000 Subject: Cygwin/X server start up fatal error - failed to compile keymap Message-ID: <4C92AE80.4020901@gmail.com> Haven't used Cygwin/X for some time. Now when I start it (either with startxwin.exe, XWin.exe, startx etc), I always get a fatal error: A fatal error has occurred and Cygwin/X will now exit. Failed to activate core devices. The /var/log/XWin.0.log contains the following EE messages: [143394.171] (EE) Error compiling keymap (server-0) [143394.171] (EE) XKB: Couldn't compile keymap [143394.171] XKB: Failed to compile keymap [143394.171] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [143394.171] Fatal server error: [143394.171] Failed to activate core devices. Searched the web and found some similar problems other people had. But no solutions work for me. Tried: rebaseall, reinstall xkeyboard-config, reinstall bash, make sure /bin/sh exists, xkbcomp exists, /usr/share/X11/xkb/rules exists. Nothing works. versions: cygwin 1.7.7-1 xorg-server 1.8.2-1 xkeyboard-config 1.9-1 What should I do to solve this or how to further investigate it? Please help. Thanks Kyle -- 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/ From PayPal@intl-updates.com Fri Sep 17 00:07:00 2010 From: PayPal@intl-updates.com (PayPal) Date: Fri, 17 Sep 2010 00:07:00 -0000 Subject: Your account has been temporarily limited Message-ID: <201009170007.o8H075DY023429@ne07.tt.co.kr> Dear customer, Your account has been temporarily limited . Download and fill out the form to resolve the problem. Thank You. -------------- next part -------------- A non-text attachment was scrubbed... Name: Restore_your_account_PayPal.html Type: application/octetstream Size: 10193 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From skbjpwcr@mvddahf.com Fri Sep 17 20:29:00 2010 From: skbjpwcr@mvddahf.com (Ujjx) Date: Fri, 17 Sep 2010 20:29:00 -0000 Subject: Biqxm Pofa Upypvs Message-ID: A non-text attachment was scrubbed... Name: Trobq_7486.rar Type: application/octet-stream Size: 633 bytes Desc: not available URL: From jjreisert@alum.mit.edu Fri Sep 17 22:05:00 2010 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Fri, 17 Sep 2010 22:05:00 -0000 Subject: Cygwin X causes system pauses Message-ID: I have a recurring problem with Cygwin-X. First off, I'm my work laptop is running Win XP SP3. In general, the applications I have open are MS Outlook 2007, RealVNC, and of course xterm/xemacs. X1 (email indexing) runs in the background). I'm running some sort of Norton Enterprise Anti-virus (I can't find the icon for it). After some period of time, if I try to type something into an Outlook E-mail message, the text pauses (no echo), then after several/many seconds, it will appear (usually with the typos I didn't see). If I kill XWin.exe, then normal performance is restored. This problem is exacerbated (or happens sooner) if I'm doing a lot of cut/copy/paste in Emacs. A second problem is sometimes I copy text from a Windows app. then try to paste it into Emacs. Instead of the text showing up, I get an XWin hourglass and I'm pretty much hosed at this point (only the X system is hung, the rest of the PC is fine). Killing XWin.exe and restarting fixes this problem. I thought I had added the extra debug to my XWin log, but now I'm not so sure. The Outlook problem just happened a few mins ago, and here is the tail end of the XWin log file (repeated about 25 times): [1317564.000] winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY This has been an ongoing problem for months, it's not something that just started happening. Any idea how to debug this further? -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From hummel.michel@gmail.com Sat Sep 18 18:44:00 2010 From: hummel.michel@gmail.com (michel hummel) Date: Sat, 18 Sep 2010 18:44:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4C5EADBB.5000009@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> Message-ID: <4C950885.5080205@gmail.com> Hi, I have checked the code of the clipboard thread and the race condition you talk about should not be a problem. Before to start a new clipboard thread, the code waits for the end of the first thread (pthread_join) then fixe the variable g_fClipboardLaunched = FALSE; g_fClipboardStarted = FALSE; So the new thread will never be launched before the old one has terminated. I have a proposition of modification to make the clipboard thread more robust. 1/ Adding a cleanup function which will be automaticaly called at the end of the thread. I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() 2/ You said that having a long-lived thread will be a good solution to simplify the code. I have an other proposition which needs less modification and can simplify the code : By using also here the macro pthread_cleanup_push() we can automaticaly restart the thread on every unexpected exit. We just have to delete this restart when the exit is expected (ie. End of the function) With this solution we don't have to take care about the thread being killed by anyone, it will be restarted. 3/ An other thing I saw is that when the Xwindow part of the clipboard is killed by an other application, the thread will still be alive but the clipboard doesn't work anymore. A solution can be : when an winClipboardErrorHandler() is catched, check for this Xwindow window and whenever this window doesn't exist anymore, create a new one. What do you think about my suggestions ? I tested them and they seem to work as expected. For example, I skipped the wrapper of XQueryTree (actualy needed for xdmcp) and the clipboard is now working with xdmcp/gdm, etc. If you don't like something in my propositions, please tell me what and I will try to adapt it. If you are interested in a patch doing this, I will be happy to give it after a quick review and a clean Thks Michel Hummel Le 08/08/2010 15:14, Jon TURNEY a ??crit : > On 06/08/2010 13:55, Michel Hummel wrote: > > I didn't saw any response to my patch proposition, did someone tried > it ? > > If I didn't posted it in the good place where should I have to > > Yes, this is abolutely the right place for your patch. > > It looks good and I shall incorporate it in the next X server release. > > > I will be happy to explain the problem if my first mail wasn't clear. > > Nope, the analysis was very clear, thank you. > > I wonder if there also exists a race condition when the clipboard > thread is stopping? i.e. if we try to start a new one just as the old > one is stopping, we think it is still running and fail to do so? > > In general this code could do with a tidy up: I think it would be much > more sensible to have a long-lived thread which tries to reconnect to > the server when ever it gets disconnected, it would avoid all this > complexity and the complexity of trying to avoid being killed by GDM > as well. > >> 2010/8/3 Michel Hummel: >>> Hello, >>> I'm using cygwin on Microsoft Windows XP with XWin version : >>> sh-3.2# XWin.exe -version >>> Welcome to the XWin X Server >>> Vendor: The Cygwin/X Project >>> Release: 1.8.0.0 (10800000) >>> Build Date: 2010-04-02 >>> Contact: >>> >>> I think I have found a bug in the XWin reset procedure which leads to >>> the start of two clipboard thread's and sometime to a crash of the X >>> server. >>> >>> The crash can be produced by lauching startkde on a Red Hat 5 remote >>> machine (The crash should arrive after some minutes of work) >>> but the bug can simply be produced like this : >>> >>> On my installation if I launch Xwin with this options : >>> XWin :0 -ac& >>> then I do >>> xsetroot -solid '#FFFF00' >>> >>> After setting the color, Xwin launches its reset procedure because >>> there is no more client connected ( the server loses the color but it >>> is the normal comportment isn't it ? >>> http://sourceware.org/ml/cygwin-xfree/2002-01/msg00106.html) >>> >>> The problem comes from the clipboard thread. In this example, when the >>> server launches its reset procedure, the clipboard is in state >>> "Launched" but is not in state "Started" (Boolean variable about >>> clipboard status, see file hw/xwin/winclipboardthread.c). >>> >>> This particular status of the ClipboardThread during server reset is >>> normaly managed by two "if" statements : >>> >>> * An "if" in the file hw/xwin/InitOutput.c disables the exit of the >>> clipboard thread in this state >>> Extract of the file hw/xwin/InitOutput.c (with line number) : >>> >>> 169 winClipboardShutdown (void) >>> 170 { >>> 171 /* Close down clipboard resources */ >>> 172 if (g_fClipboard&& g_fClipboardLaunched&& >>> g_fClipboardStarted) >>> 173 { >>> 174 /* Synchronously destroy the clipboard window */ >>> 175 if (g_hwndClipboard != NULL) >>> 176 { >>> 177 SendMessage (g_hwndClipboard, WM_DESTROY, 0, 0); >>> 178 /* NOTE: g_hwndClipboard is set to NULL in >>> winclipboardthread.c */ >>> 179 } >>> 180 else >>> 181 return; >>> 182 >>> 183 /* Wait for the clipboard thread to exit */ >>> 184 pthread_join (g_ptClipboardProc, NULL); >>> 185 >>> 186 g_fClipboardLaunched = FALSE; >>> 187 g_fClipboardStarted = FALSE; >>> 188 >>> 189 winDebug ("winClipboardShutdown - Clipboard thread has >>> exited.\n"); >>> 190 } >>> 191 } >>> >>> * An "if" statement in the file hw/xwin/winclipboardwrappers.c >>> prohibits the launch of clipboard thread if one is already Launched. >>> Extract of the file hw/xwin/winclipboardwrappers.c (with line number) >>> 256 /* If the clipboard client has already been started, abort */ >>> 257 if (g_fClipboardLaunched) >>> 258 { >>> 259 ErrorF ("winProcEstablishConnection - Clipboard client >>> already " >>> 260 "launched, returning.\n"); >>> 261 return iReturn; >>> 262 } >>> >>> >>> The problem is that the Boolean variables g_fClipboardLaunched and >>> g_fClipboardStarted are re-initialized by the server reset procedure >>> (function winInitializeGlobals of the file hw/xwin/winglobals.c) >>> Extract of the file hw/xwin/winglobals.c (with line number) >>> 128 /* >>> 129 * Re-initialize global variables that are invalidated 130 * by a >>> server reset. >>> 131 */ >>> 132 >>> 133 void >>> 134 winInitializeGlobals (void) >>> 135 { >>> 136 g_dwCurrentThreadID = GetCurrentThreadId (); >>> 137 g_hwndKeyboardFocus = NULL; >>> 138 #ifdef XWIN_CLIPBOARD >>> 139 g_fClipboardLaunched = FALSE; >>> 140 g_fClipboardStarted = FALSE; >>> 141 g_iClipboardWindow = None; >>> 142 g_pClipboardDisplay = NULL; >>> 143 g_atomLastOwnedSelection = None; >>> 144 g_hwndClipboard = NULL; >>> 145 #endif >>> 146 } >>> >>> The consequence of this Re-initialization in this particular situation >>> is that the clipboard thread is launched two times and sometimes leads >>> to a crash of the X server. >>> You can see the double launch of the clipboard thread at the end of >>> the attached log file Xwin.0.log ( 2 times the sentence : >>> winClipboardProc - XOpenDisplay () returned and successfully opened >>> the display. ) >>> >>> To fix this bug I purpose to remove the variables g_fClipboardLaunched >>> and g_fClipboardStarted of the "winInitializeGlobals (void)" function, >>> as their re-initializations are handled in in the files : >>> hw/xwin/InitOutput.c. >>> >>> That what is doing the patch Attached to this email. > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From deepali.shefali@gmail.com Mon Sep 20 10:31:00 2010 From: deepali.shefali@gmail.com (Dees) Date: Mon, 20 Sep 2010 10:31:00 -0000 Subject: Running Java application with drag and drop support in cygwin In-Reply-To: <15fe165d0912230456uc64b0fenfd4bf808c8dcecd2@mail.gmail.com> References: <15fe165d0910272257x18264be8sadf9d778e15d8f25@mail.gmail.com> <4AE9A9A3.7090704@dronecode.org.uk> <15fe165d0910300206n2fad7c58p9c9e69ccb5fae959@mail.gmail.com> <4AFD73A0.5030407@dronecode.org.uk> <15fe165d0912132242h3626f4f2k7eccb1e652300a63@mail.gmail.com> <15fe165d0912172153o5c48e300s63d80704d0c504c8@mail.gmail.com> <15fe165d0912230456uc64b0fenfd4bf808c8dcecd2@mail.gmail.com> Message-ID: Any update? On Wed, Dec 23, 2009 at 6:26 PM, Dees wrote: > > People, any clue? Struggling really hard. > > On Fri, Dec 18, 2009 at 11:23 AM, Dees wrote: > > Hi Jon, > > > > Did you get a chance to look at this? > > From whatever posts available online, I could not get a clue what is > > going wrong. > > Please respond. > > > > Thanks, > > Shefali > > > > On Mon, Dec 14, 2009 at 12:12 PM, Dees wrote: > >> On Fri, Nov 13, 2009 at 8:26 PM, Jon TURNEY wrote: > >>> On 30/10/2009 09:06, Dees wrote: > >>>> > >>>> Your reply is much appreciated Jon. I will try to be more specific > >>>> about the problem in further mails. > >>>> > >>>> On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEY > >>>> wrote: > >>>>> > >>>>> On 28/10/2009 05:57, Dees wrote: > >>>>>> > >>>>>> I have developed a Java application involving jTree with extensive > >>>>>> drag and drop support, which runs correctly in my Linux box. However, > >>>>>> when I switch to a windows box and access the same Linux box using > >>>>>> cygwin x-server, the drag and drop in jTree stops working. > >>>>>> Interestingly, rest of the application still works fine. After > >>>>>> analyzing a bit I found that x-server is able to recognize the drag > >>>>>> event but fails to recognize a drop event. > >>>>> > >>>>> Details? > >>>> > >>>> OS : Suse Linux Enterprise Server 10 (i586) > >>>> Version : 10 > >>>> Patch level : 3 > >>>> Other version information: > >>>> Java : JDK 5 > >>>> Cygwin setup-version: 2.573.2.3 > >>>> Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but > >>>> that also doesn't solve the problem. > >>>> > >>>>> > >>>>>> Is there any setting, which should be done prior to running the Java > >>>>>> swing applications? > >>>>>> > >>>>>> Here is a sample code which behaves in exactly same way. > >>>>>> http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm > >>>>> > >>>>> I have no idea how to use that java code to reproduce the problem you are > >>>>> seeing. > >>>> > >>>> Using the above java code in Linux: > >>>> 1. Download and Install Java Development Toolkit on your Linux box > >>>> (Java sun download site: > >>>> http://java.sun.com/javase/downloads/index.jsp), if you do not have it > >>>> already. > >>>> 2. Save the sample code in the above link with the file name > >>>> TreeTester.java, say in /home/user/ > >>>> 3. Navigate to TreeTester.java from shell, and compile the java code: > >>>> # cd /home/user/ > >>>> # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java > >>>> Ignore any warnings of deprecated APIs. > >>>> 4. This will create a few .class files in /home/user/ directory. Final > >>>> step is to run the Java code, using: > >>>> # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester > >>>> This will open up a GUI, with a jTree each on left and right pane. > >>>> You can drag and drop any of the leaf nodes from one jTree to the root > >>>> node of the other jTree and this should add a new node in the other > >>>> jTree. You will get messages on console for the operations being > >>>> performed. Now ssh the same box using cygwin/xming from any other > >>>> windows box, and run the application using command in step 4. You > >>>> should be able to drag (a small icon will come under cursor indicating > >>>> that something is being dragged) but when you will drop it, the new > >>>> node would not be added to the tree. Thats where lies my problem!!! > >>> > >>> Thanks for the test case and instructions, this makes it much easier for me > >>> to try it out. > >>> > >>> However, this testcase and your jar archive both work fine for me (using > >>> Xserver 1.7.1-3)! > >>> > >>>>>> May be my problem is related to some setting. Though, not sure. > >>>>>> Has anybody come across something similar? What should be done then? > >>>>>> Please let me know. > >>>>> > >>>>> No it's probably a bug in Cygwin/X. But you're going to need to be a lot > >>>>> more specific about the problem before any progress can be made on fixing > >>>>> it. > >>> > >>>> Also, putting some debug messages in the code lets me conclude that > >>>> it's the drop event which is not being recognized, as the main control > >>>> never reaches there. > >>> > >>> There is not really any drop event, as far as the X server is concerned, > >>> just mouse click and motion events, which are passed on to you application > >>> (which has a framework to interpret them as dragging and dropping an item). > >>> > >>> Now having a better idea of the problem, it seems less likely it is an > >>> Xserver bug at all. The only Xserver cause I can think of would be if it > >>> was somehow not sending the correct events to your applications window, > >>> which you could test using xev -id (you can > >>> use xwininfo to find the window id) > >>> > >> I have tried this, but could not get any idea if any event is going wrong. > >> Here is the output of xev -id 0xe00021 (only for drag and drop event): > >> > >> LeaveNotify event, serial 13, synthetic NO, window 0xe00021, > >> root 0x5a, subw 0xe00025, time 3560250, (87,65), root:(91,95), > >> mode NotifyGrab, detail NotifyVirtual, same_screen YES, > >> focus YES, state 256 > >> > >> FocusOut event, serial 13, synthetic NO, window 0xe00021, > >> mode NotifyGrab, detail NotifyAncestor > >> > >> EnterNotify event, serial 13, synthetic NO, window 0xe00021, > >> root 0x5a, subw 0xe00025, time 3565375, (212,48), root:(216,78), > >> mode NotifyUngrab, detail NotifyVirtual, same_screen YES, > >> focus YES, state 0 > >> > >> KeymapNotify event, serial 13, synthetic NO, window 0x0, > >> keys: 90 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > >> > >> FocusIn event, serial 13, synthetic NO, window 0xe00021, > >> mode NotifyUngrab, detail NotifyAncestor > >> > >> KeymapNotify event, serial 13, synthetic NO, window 0x0, > >> keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > >> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > >> > >> LeaveNotify event, serial 13, synthetic NO, window 0xe00021, > >> root 0x5a, subw 0xe00025, time 3569046, (205,211), root:(209,241), > >> mode NotifyNormal, detail NotifyNonlinearVirtual, same_screen YES, > >> focus YES, state 0 > >> > >> Does the window 0x0 in two events in the log(above) signify anything > >> misbehaving? > >> Your reply is much awaited and appreciated. > >> > >> > >>> -- > >>> Jon TURNEY > >>> Volunteer Cygwin/X X Server maintainer > >>> > >> > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 20 13:59:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 20 Sep 2010 13:59:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4C950885.5080205@gmail.com> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> Message-ID: <4C9768C1.2050508@dronecode.org.uk> On 18/09/2010 19:44, michel hummel wrote: > I have checked the code of the clipboard thread and the race condition > you talk about should not be a problem. > Before to start a new clipboard thread, the code waits for the end of > the first thread (pthread_join) then fixe the variable > g_fClipboardLaunched = FALSE; > g_fClipboardStarted = FALSE; > > So the new thread will never be launched before the old one has terminated. > > I have a proposition of modification to make the clipboard thread more robust. > > 1/ Adding a cleanup function which will be automaticaly called at the > end of the thread. > I purpose the use of the macro pthread_cleanup_push() pthread_cleanup_pop() > > 2/ You said that having a long-lived thread will be a good solution to > simplify the code. > I have an other proposition which needs less modification and can > simplify the code : > By using also here the macro pthread_cleanup_push() we can > automaticaly restart the thread on every unexpected exit. > We just have to delete this restart when the exit is expected (ie. > End of the function) > With this solution we don't have to take care about the thread > being killed by anyone, it will be restarted. You will need to have some kind of back-off mechanism (i.e. a delay before retrying to connect) so that that this doesn't constantly try to connect if the server gets into a state where it can't accept the connection or the connection is constantly getting closed. > 3/ An other thing I saw is that when the Xwindow part of the clipboard > is killed by an other application, the thread will still be alive but > the clipboard doesn't work anymore. > A solution can be : > when an winClipboardErrorHandler() is catched, check for > this Xwindow window and whenever this window doesn't exist anymore, > create a new one. Would it not be simpler to restart the clipboard thread in this situation as well, rather than having code to recrate the window? > What do you think about my suggestions ? > > I tested them and they seem to work as expected. > For example, I skipped the wrapper of XQueryTree (actualy needed for > xdmcp) and the clipboard is now working with xdmcp/gdm, etc. > > If you don't like something in my propositions, please tell me what > and I will try to adapt it. > > If you are interested in a patch doing this, I will be happy to give > it after a quick review and a clean That would be great, thank you. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 20 14:21:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 20 Sep 2010 14:21:00 -0000 Subject: CygwinX at MS Terminalserver? In-Reply-To: <4C77DF53.9020802@dronecode.org.uk> References: <4C63A34E.2070901@zone42.org> <4C641B91.60504@dronecode.org.uk> <4C64F0A8.5020400@zone42.org> <4C6527D3.3000303@dronecode.org.uk> <4C68DC4F.2000800@zone42.org> <4C77DF53.9020802@dronecode.org.uk> Message-ID: <4C976DFF.3020709@dronecode.org.uk> On 27/08/2010 16:52, Jon TURNEY wrote: > On 16/08/2010 07:35, Steffen Sledz wrote: >> Am 13.08.2010 13:09, schrieb Jon TURNEY: >>>> Now testuser0002 tries to start another server in parallel. >>>> This gives this error: >>>> >>>> /usr/bin/startxwin: Resource temporarily unavailable (errno 11): Another X >>>> server instance is running on DISPLAY :0 >>> >>> This is expected. As I said, each X server instance must >>> have a unique display number. >>> >>> This can't possibly work any other way. If two users both >>> have an X server with display number 0, to which server should >>> a client started with DISPLAY=:0.0 connect? >> >> That's clear. I thought (or hoped) that starting X server using the "XWin >> Server" menu item automatically searches for an unused display number and >> uses it. I think that would be a good default behaviour. > > I agree it would be useful, and it is on the todo list [1], but there's a > non-trivial problem to solve first: > > How is the display number which the server has allocated communicated to other > processes, so that the users clients appear on the right display? The fedora -displayfd patch seems to have moved and now lives at [1] I've built an Xserver including an updated and modified version of this patch and uploaded it at [2]. Perhaps you could give that a try and see if it works for your purposes? "-displayfd fd specifies a file descriptor in the launching process. Rather than specify a display number, the X server will attempt to listen on successively higher display numbers, and upon finding a free one, will write the display number back on this file descriptor as a newline-terminated string. The -pn option is ignored when using -displayfd." > If you start the X server first and then launch everything from the traymenu, > everything would works fine, as the X server places a correct DISPLAY variable > into the environment inherited by the child process. > > But if you start the X server via xinit/startx/startxwin, the display number > needs to be communicated back to xinit, so that the correct display number is > used for clients which are subsequently started by xinit. I've also patched xinit/startxwin so they transparently handle the -displayfd X server option, uploaded at [3],[4]. They handle the -displayfd option specially to modify the fd number passed to the Xserver so they can read it's output and set the display number correctly for clients which xinit/startxwin starts, then write that display number to the originally specified fd. (Patch to follow. Note that this patch probably won't apply to a stock xinit-1.2.1 as it's based on top of the patch which adds startxwin) > Fedora ships with a patch [2] which adds the -displayfd option, which > allocates a display number and writes it to the specified fd. But to be useful > to us, xinit would needs some code to use that flag (under some circumstances) > and read that display number and use it for the clients it creates. > > There's also the case where the user explicitly sets DISPLAY programmatically > or manually before starting clients. I think with some suitable shell > scripting, -displayfd probably can be used for that also. Something along the lines of adding '-displayfd 3 3>~/.display' to the Xserver invocation, and then 'export DISPLAY=:`cat ~/.display`' to ~/.bashrc might be sufficient. > [1] http://x.cygwin.com/devel/todo.html > [2] > http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.6.0-displayfd.patch [1] http://pkgs.fedoraproject.org/gitweb/?p=xorg-x11-server.git;a=tree [2] ftp://cygwin.com/pub/cygwinx/XWin.20100916-git-df5773ea3927d9c1.exe.bz2 [3] ftp://cygwin.com/pub/cygwinx/startxwin.exe [4] ftp://cygwin.com/pub/cygwinx/xinit.exe -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 20 14:26:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 20 Sep 2010 14:26:00 -0000 Subject: [PATCH] os: Add -displayfd option. In-Reply-To: <4C976DFF.3020709@dronecode.org.uk> References: <4C976DFF.3020709@dronecode.org.uk> Message-ID: <1284992725-844-1-git-send-email-jon.turney@dronecode.org.uk> This option specifies a file descriptor in the launching process. X will scan for an available display number and write that number back to the launching process, at the same time as SIGUSR1 generation. This means display managers don't need to guess at available display numbers. As a consequence, if X fails to start when using -displayfd, it's not because the display was in use, so there's no point in retrying the X launch on a higher display number. Signed-off-by: Adam Jackson Update for current X server Fix null DISPLAY crash when stderr is closed Rearrange init order to avoid null DISPLAY crash and correctly use DISPLAY in default logfile name when logfile isn't specified on command line Don't put '\'n on end of DISPLAY so internal XWin uses work correctly Do a bit more logging about what we are trying to do Signed-off-by: Jon TURNEY --- dix/globals.c | 1 + dix/main.c | 7 +++- doc/Xserver.man.pre | 7 ++++ hw/xwin/InitOutput.c | 10 +++--- include/opaque.h | 1 + os/connection.c | 75 ++++++++++++++++++++++++++++++++++--------------- os/osinit.c | 4 +- os/utils.c | 11 +++++++ 8 files changed, 84 insertions(+), 32 deletions(-) diff --git a/dix/globals.c b/dix/globals.c index c24a94f..19168f4 100644 --- a/dix/globals.c +++ b/dix/globals.c @@ -134,6 +134,7 @@ int defaultColorVisualClass = -1; int monitorResolution = 0; char *display; +int displayfd; char *ConnectionInfo; CARD32 TimeOutValue = DEFAULT_TIMEOUT * MILLI_PER_SECOND; diff --git a/dix/main.c b/dix/main.c index f023536..4e0ec93 100644 --- a/dix/main.c +++ b/dix/main.c @@ -168,8 +168,7 @@ int main(int argc, char *argv[], char *envp[]) DPMSPowerLevel = 0; #endif InitBlockAndWakeupHandlers(); - /* Perform any operating system dependent initializations you'd like */ - OsInit(); + if(serverGeneration == 1) { CreateWellKnownSockets(); @@ -183,6 +182,10 @@ int main(int argc, char *argv[], char *envp[]) } else ResetWellKnownSockets (); + + /* Perform any operating system dependent initializations you'd like */ + OsInit(); + clients[0] = serverClient; currentMaxClients = 1; diff --git a/doc/Xserver.man.pre b/doc/Xserver.man.pre index ce3b3a1..a6bd906 100644 --- a/doc/Xserver.man.pre +++ b/doc/Xserver.man.pre @@ -121,6 +121,13 @@ Not obeyed by all servers. .B \-core causes the server to generate a core dump on fatal errors. .TP 8 +.B \-displayfd \fIfd\fP +specifies a file descriptor in the launching process. Rather than specify +a display number, the X server will attempt to listen on successively higher +display numbers, and upon finding a free one, will write the display number back +on this file descriptor as a newline-terminated string. The \-pn option is +ignored when using \-displayfd. +.TP 8 .B \-deferglyphs \fIwhichfonts\fP specifies the types of fonts for which the server should attempt to use deferred glyph loading. \fIwhichfonts\fP can be all (all fonts), diff --git a/hw/xwin/InitOutput.c b/hw/xwin/InitOutput.c index b144136..295c010 100644 --- a/hw/xwin/InitOutput.c +++ b/hw/xwin/InitOutput.c @@ -700,13 +700,13 @@ OsVendorInit (void) if (!g_fLogInited) { /* keep this order. If LogInit fails it calls Abort which then calls - * ddxGiveUp where LogInit is called again and creates an infinite - * recursion. If we set g_fLogInited to TRUE before the init we - * avoid the second call - */ + * ddxGiveUp where LogInit is called again and creates an infinite + * recursion. If we set g_fLogInited to TRUE before the init we + * avoid the second call + */ g_fLogInited = TRUE; g_pszLogFile = LogInit (g_pszLogFile, NULL); - } + } LogSetParameter (XLOG_FLUSH, 1); LogSetParameter (XLOG_VERBOSITY, g_iLogVerbose); LogSetParameter (XLOG_FILE_VERBOSITY, g_iLogVerbose); diff --git a/include/opaque.h b/include/opaque.h index b3c7c70..ea0ac13 100644 --- a/include/opaque.h +++ b/include/opaque.h @@ -50,6 +50,7 @@ extern _X_EXPORT int ScreenSaverAllowExposures; extern _X_EXPORT int defaultScreenSaverBlanking; extern _X_EXPORT int defaultScreenSaverAllowExposures; extern _X_EXPORT char *display; +extern _X_EXPORT int displayfd; extern _X_EXPORT int defaultBackingStore; extern _X_EXPORT Bool disableBackingStore; diff --git a/os/connection.c b/os/connection.c index 85d0d10..9712729 100644 --- a/os/connection.c +++ b/os/connection.c @@ -146,6 +146,7 @@ Bool NewOutputPending; /* not yet attempted to write some new output */ Bool AnyClientsWriteBlocked; /* true if some client blocked on write */ static Bool RunFromSmartParent; /* send SIGUSR1 to parent process */ +static char dynamic_display[7]; Bool PartialNetwork; /* continue even if unable to bind all addrs */ static Pid_t ParentProcess; @@ -374,9 +375,25 @@ NotifyParentProcess(void) kill (ParentProcess, SIGUSR1); } } + if (dynamic_display[0]) { + write(displayfd, dynamic_display, strlen(dynamic_display)); + write(displayfd, "\n", 1); + } #endif } +static Bool +TryCreateSocket(int num, int *partial) +{ + char port[20]; + + sprintf(port, "%d", num); + + return _XSERVTransMakeAllCOTSServerListeners(port, partial, + &ListenTransCount, + &ListenTransConns); +} + /***************** * CreateWellKnownSockets * At initialization, create the sockets to listen on for new clients. @@ -387,7 +404,6 @@ CreateWellKnownSockets(void) { int i; int partial; - char port[20]; FD_ZERO(&AllSockets); FD_ZERO(&AllClients); @@ -402,32 +418,45 @@ CreateWellKnownSockets(void) FD_ZERO (&WellKnownConnections); - sprintf (port, "%d", atoi (display)); - - if ((_XSERVTransMakeAllCOTSServerListeners (port, &partial, - &ListenTransCount, &ListenTransConns) >= 0) && - (ListenTransCount >= 1)) + if (display) { - if (!PartialNetwork && partial) - { - FatalError ("Failed to establish all listening sockets"); - } - else + if (TryCreateSocket(atoi(display), &partial) && + (ListenTransCount >= 1)) + if (!PartialNetwork && partial) + FatalError ("Failed to establish all listening sockets"); + } + else /* -displayfd */ + { + Bool found = 0; + for (i = 0; i < 65535 - 1024; i++) { - ListenTransFds = xalloc (ListenTransCount * sizeof (int)); - - for (i = 0; i < ListenTransCount; i++) + ErrorF("Trying to create socket for display number %d\n", i); + if (!TryCreateSocket(i, &partial) && !partial) { - int fd = _XSERVTransGetConnectionNumber (ListenTransConns[i]); - - ListenTransFds[i] = fd; - FD_SET (fd, &WellKnownConnections); - - if (!_XSERVTransIsLocal (ListenTransConns[i])) - { - DefineSelf (fd); - } + found = 1; + break; } + else + CloseWellKnownConnections(); + } + if (!found) + FatalError("Failed to find a socket to listen on"); + sprintf(dynamic_display, "%d", i); + display = dynamic_display; + } + + ListenTransFds = xalloc(ListenTransCount * sizeof (int)); + + for (i = 0; i < ListenTransCount; i++) + { + int fd = _XSERVTransGetConnectionNumber (ListenTransConns[i]); + + ListenTransFds[i] = fd; + FD_SET (fd, &WellKnownConnections); + + if (!_XSERVTransIsLocal (ListenTransConns[i])) + { + DefineSelf (fd); } } diff --git a/os/osinit.c b/os/osinit.c index e8fcd45..0043d46 100644 --- a/os/osinit.c +++ b/os/osinit.c @@ -229,8 +229,8 @@ OsInit(void) { FILE *err; - if (strlen (display) + strlen (admpath) + 1 < sizeof fname) - sprintf (fname, admpath, display); + if ((display) && (strlen (display) + strlen (ADMPATH) + 1 < sizeof fname)) + sprintf (fname, ADMPATH, display); else strcpy (fname, devnull); /* diff --git a/os/utils.c b/os/utils.c index 2a73a57..db53099 100644 --- a/os/utils.c +++ b/os/utils.c @@ -670,6 +670,17 @@ ProcessCommandLine(int argc, char *argv[]) else UseMsg(); } + else if (strcmp(argv[i], "-displayfd") == 0) + { + if (++i < argc) + { + displayfd = atoi(argv[i]); + display = NULL; + nolock = TRUE; + } + else + UseMsg(); + } #ifdef DPMSExtension else if ( strcmp( argv[i], "dpms") == 0) /* ignored for compatibility */ ; -- 1.7.1 -- 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/ From jon.turney@dronecode.org.uk Mon Sep 20 14:27:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 20 Sep 2010 14:27:00 -0000 Subject: [PATCH] Handle X server -displayfd option transparently In-Reply-To: <4C976DFF.3020709@dronecode.org.uk> References: <4C976DFF.3020709@dronecode.org.uk> Message-ID: <1284992864-2324-1-git-send-email-jon.turney@dronecode.org.uk> Signed-off-by: Jon TURNEY --- xinit.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 60 insertions(+), 8 deletions(-) diff --git a/xinit.c b/xinit.c index 918f83e..95ba13c 100644 --- a/xinit.c +++ b/xinit.c @@ -168,6 +168,11 @@ int serverpid = -1; int clientpid = -1; volatile int gotSignal = 0; +static int original_displayfd = -1; +static int server_displayfd_read = -1; +static char server_displayfd_write[256]; +static char displayfd_buf[256]; + static void Execute ( char **vec, char **envp ); static Bool waitforserver ( void ); static Bool processTimeout ( int timeout, char *string ); @@ -319,14 +324,40 @@ main(int argc, char *argv[], char *envp[]) } if (argc > 0 && (argv[0][0] == ':' && isdigit(argv[0][1]))) displayNum = *argv; - else - displayNum = *sptr++ = default_display; start_of_server_args = (sptr - server); while (--argc >= 0) { + /* Handle the -displayfd server argument transparently */ + if ((argc > 0) && (strcmp(argv[0],"-displayfd") == 0)) + { + int filedes[2]; + + original_displayfd = atoi(argv[1]); + + if (pipe(filedes) == 0) + { + server_displayfd_read = filedes[0]; + sprintf(server_displayfd_write, "%d", filedes[1]); + argv[1] = server_displayfd_write; + } + else + { + Fatal("pipe() for -displayfd failed"); + } + } + server_args_given++; *sptr++ = *argv++; } + + /* + if there was neither an explicit displayNum nor a + -displayfd option, add the default display number + to server arguments + */ + if ((displayNum == NULL) && (original_displayfd == -1)) + displayNum = *sptr++ = default_display; + #ifdef STARTXWIN *sptr++ = "-multiwindow"; #endif @@ -391,11 +422,6 @@ main(int argc, char *argv[], char *envp[]) #endif /* - * put the display name into the environment - */ - set_environment (); - - /* * Start the server and client. */ #ifdef SIGCHLD @@ -423,7 +449,7 @@ main(int argc, char *argv[], char *envp[]) #endif #endif - if (XOpenDisplay(displayNum)) { + if (displayNum && XOpenDisplay(displayNum)) { Error("Another X server instance is running on DISPLAY %s\r\n", displayNum); exit(ERR_EXIT); } @@ -487,6 +513,32 @@ waitforserver(void) sleep(2); #endif + if (server_displayfd_read != -1) + { + /* wait for the server to write the DISPLAY number to the displayfd pipe */ + int length; + + displayfd_buf[0] = ':'; + length = read(server_displayfd_read, displayfd_buf+1, 255); + + if (length < 0) + Fatal("reading displayfd pipe failed"); + displayfd_buf[length] = '\0'; + + printf("read display number '%s' from X server\n", displayfd_buf); + displayNum = displayfd_buf; + + /* write the DISPLAY received from the server to the original displayfd */ + /* XXX: this should happen after connections are being accepted */ + write(original_displayfd, displayfd_buf+1, length); + write(original_displayfd, "\n", 1); + } + + /* + * put the display name into the environment + */ + set_environment (); + for (cycles = 0; cycles < ncycles; cycles++) { if ((xd = XOpenDisplay(displayNum))) { return(TRUE); -- 1.7.1 -- 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/ From hummel.michel@gmail.com Mon Sep 20 14:49:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Mon, 20 Sep 2010 14:49:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4C9768C1.2050508@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> Message-ID: 2010/9/20 Jon TURNEY : > On 18/09/2010 19:44, michel hummel wrote: >> >> I have checked the code of the clipboard thread and the race condition >> you talk about should not be a problem. >> Before to start a new clipboard thread, the code waits for the end of >> the first thread (pthread_join) then fixe the variable >> g_fClipboardLaunched = FALSE; >> g_fClipboardStarted = FALSE; >> >> So the new thread will never be launched before the old one has >> terminated. >> >> I have a proposition of modification to make the clipboard thread more >> robust. >> >> 1/ Adding a cleanup function which will be automaticaly called at the >> end of the thread. >> I purpose the use of the macro pthread_cleanup_push() >> pthread_cleanup_pop() >> >> 2/ You said that having a long-lived thread will be a good solution to >> simplify the code. >> I have an other proposition which needs less modification and can >> simplify the code : >> By using also here the macro pthread_cleanup_push() we can >> automaticaly restart the thread on every unexpected exit. >> We just have to delete this restart when the exit is expected (ie. >> End of the function) >> With this solution we don't have to take care about the thread >> being killed by anyone, it will be restarted. > > You will need to have some kind of back-off mechanism (i.e. a delay before > retrying to connect) so that that this doesn't constantly try to connect if > the server gets into a state where it can't accept the connection or the > connection is constantly getting closed. Like I?ve implemented it : - The clipboard thread uses the winProcEstablishConnection wrapper to restart and so it?s waiting for a new client connection before trying to reconnect himself. - An other point, the restart mechanism will only be activated if the clipboard thread has successfully been connected, otherwise the clipboard thread will dies and not restarts (this will prevent an infinite loop on connection error) Those two mechanisms and the loop on XOpenDisplay with the sleep (WIN_CONNECT_DELAY) between each retries should do the job isn't it ? But if you think a connection delay is also needed in the restart process can add one without problem > >> 3/ An other thing I saw is that when the Xwindow part of the clipboard >> is killed by an other application, the thread will still be alive but >> the clipboard doesn't work anymore. >> A solution can be : >> when an winClipboardErrorHandler() is catched, check for >> this Xwindow window and whenever this window doesn't exist anymore, >> create a new one. > > Would it not be simpler to restart the clipboard thread in this situation as > well, rather than having code to recrate the window? You are absolutely right, I just have to replace the window creation with a pthread_exit(NULL); > >> What do you think about my suggestions ? >> >> I tested them and they seem to work as expected. >> For example, I skipped the wrapper of XQueryTree (actualy needed for >> xdmcp) and the clipboard is now working with xdmcp/gdm, etc. >> >> If you don't like something in my propositions, please tell me what >> and I will try to adapt it. >> >> If you are interested in a patch doing this, I will be happy to give >> it after a quick review and a clean > > That would be great, thank you. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From JayGoldman@crd.com Mon Sep 20 18:53:00 2010 From: JayGoldman@crd.com (Jay Goldman) Date: Mon, 20 Sep 2010 18:53:00 -0000 Subject: Problems using XWin with remote desktop with latest version Message-ID: <8483108B583CFC4FAEFEE85B95CF015C30A927F2A0@MAIL4.crd.com> I have the following batch file to start xwin: @echo off SET CYGWIN_ROOT= SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% SET XAPPLRESDIR= SET XCMSDB= SET XKEYSYMDB= SET XNLSPATH= %RUN% XWin -multiwindow -clipboard -silent-dup-error IF EXIST %CYGWIN_ROOT%\bin\urxvtd-X.exe? %RUN% %CYGWIN_ROOT%\bin\urxvtd-X.exe This works fine (and has been for a while >year). Occasionally, I have to connect to my machine via windows remote desktop. I've also been doing this for a while. With the latest version of?x-windows; however, when I do so XWin.exe seg faults. I then kill the urxvtd-X.exe process, re-run my batch script, and all is well within the remote desktop session. Then I close the remote desktop session, and when I get back to my machine the x-windows-based command windows are no longer functional. ?I close down Xwin.exe (and urxvtd-X.exe), restart them, and I'm ok again. Any ideas as to what has changed to cause these new issues, (a) XWin.exe seg fault due to remote desktop connection (sorry, I don't have the seg fault info) (b) X-windows based command windows, (i.e., windows started with: urxvtc -g 80x42 -e /bin/bash -l -i) no longer display correctly when I disconnect the remote desktop session - I have to 're-start' xwin.exe (and urxvtd-X.exe) processes. -- 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/ From jon.turney@dronecode.org.uk Tue Sep 21 14:14:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 21 Sep 2010 14:14:00 -0000 Subject: Problems using XWin with remote desktop with latest version In-Reply-To: <8483108B583CFC4FAEFEE85B95CF015C30A927F2A0@MAIL4.crd.com> References: <8483108B583CFC4FAEFEE85B95CF015C30A927F2A0@MAIL4.crd.com> Message-ID: <4C98BDCC.9070407@dronecode.org.uk> On 20/09/2010 19:52, Jay Goldman wrote: > I have the following batch file to start xwin: > @echo off > SET CYGWIN_ROOT= > SET RUN=%CYGWIN_ROOT%\bin\run -p /usr/bin > SET PATH=.;%CYGWIN_ROOT%\bin;%PATH% > > SET XAPPLRESDIR= > SET XCMSDB= > SET XKEYSYMDB= > SET XNLSPATH= > > %RUN% XWin -multiwindow -clipboard -silent-dup-error > IF EXIST %CYGWIN_ROOT%\bin\urxvtd-X.exe %RUN% %CYGWIN_ROOT%\bin\urxvtd-X.exe > > This works fine (and has been for a while>year). > > Occasionally, I have to connect to my machine via windows remote desktop. > I've also been doing this for a while. > > With the latest version of x-windows; however, when I do so XWin.exe seg faults. > I then kill the urxvtd-X.exe process, re-run my batch script, and all is well within the remote desktop session. > > Then I close the remote desktop session, and when I get back to my machine the x-windows-based command windows are no longer functional. I close down Xwin.exe (and urxvtd-X.exe), restart them, and I'm ok again. > > Any ideas as to what has changed to cause these new issues, > (a) XWin.exe seg fault due to remote desktop connection (sorry, I don't have the seg fault info) > (b) X-windows based command windows, (i.e., windows started with: urxvtc -g 80x42 -e /bin/bash -l -i) no longer display correctly when I disconnect the remote desktop session - I have to 're-start' xwin.exe (and urxvtd-X.exe) processes. This is pretty likely to be a known problem with the resize support added in Xserver 1.8.2-1, see [1] Unfortunately, due to a mistake on my part, there is no way to disable resize support in multiwindow mode in that version, so your options for a workaround are limited to: a) Downgrade to the previous Xserver version b) Use the test build provided by me in that thread c) Avoid RDP sessions which change the colour depth of your display (e.g by setting your display to use 16-bit colour, assuming the RDP sessions choose 16-bit for some reason) If your problems persist with the that test build, I'd very much like to hear about it. [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00080.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From richard.evans@datanomic.com Tue Sep 21 14:26:00 2010 From: richard.evans@datanomic.com (Richard Evans) Date: Tue, 21 Sep 2010 14:26:00 -0000 Subject: Setting fonts for remote gnome applications Message-ID: <974066EF77EEA44EB8AED6ADA05DBD0202267622@THHS2EXBE1X.hostedservice2.net> I'm running some gnome applications on a Linux system and displaying on a remote cygwin/X server.? Does anyone know how I configure the fonts used?? The local gnome appearances applet just sets things for the local display.? Are X resources used? I know this is more relevant to a gnome list but I did ask the question there and didn't get any answers.? I'm hoping users here will have more experience with this situation. Richard -- 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/ From moss@cs.umass.edu Tue Sep 21 22:06:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Tue, 21 Sep 2010 22:06:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation Message-ID: <4C992C74.7080708@cs.umass.edu> Dear John -- Using the .bz2 you posted to this thread on Sept 7th or so, I consistently get SIGSEGV on my Windows-7 box whenever I Sleep or Hibernate the system. I include the .log file for your consideration, and the stderr output. Earlier versions seemed to do ok. Is there a simple procedure for winding back? I am on the latest cygwin. Regards -- Eliot Moss Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Snapshot: 20100831-git-5fa9c90425fb1d68 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.10256 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 800 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [332509.922] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 [332509.922] (II) xorg.conf is not supported [332509.922] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [332509.922] LoadPreferences: /home/Eliot/.XWinrc not found [332509.922] LoadPreferences: Loading /etc/X11/system.XWinrc [332509.922] LoadPreferences: Done parsing the configuration file... [332509.922] winGetDisplay: DISPLAY=:0.0 [332509.922] winDetectSupportedEngines - Windows NT/2000/XP [332509.953] winDetectSupportedEngines - DirectDraw installed [332509.953] winDetectSupportedEngines - Allowing PrimaryDD [332509.953] winDetectSupportedEngines - DirectDraw4 installed [332509.953] winDetectSupportedEngines - Returning, supported engines 0000001f [332509.953] winSetEngine - Using Shadow DirectDraw NonLocking [332509.953] winScreenInit - Using Windows display depth of 32 bits per pixel [332509.969] winWindowProc - WM_SIZE - new client area w: 1264 h: 732 [332510.000] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [332510.000] Screen 0 added at virtual desktop coordinate (0,0). [332510.000] MIT-SHM extension disabled due to lack of kernel support [332510.015] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [332510.031] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [332510.031] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [332510.047] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [332510.468] winPointerWarpCursor - Discarding first warp: 640 400 [332510.468] (--) 8 mouse buttons found [332510.468] (--) Setting autorepeat to delay=500, rate=31 [332510.468] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 [332510.468] (--) Found matching XKB configuration "English (USA)" [332510.468] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [332510.468] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [332510.483] winProcEstablishConnection - Hello [332510.639] winInitClipboard () [332510.639] winClipboardProc - Hello [332510.639] DetectUnicodeSupport - Windows NT/2000/XP [332510.639] winProcEstablishConnection - winInitClipboard returned. [332510.639] winGetDisplay: DISPLAY=:0.0 [332510.639] winClipboardProc - DISPLAY=:0.0 [332510.639] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [332511.061] winClipboardFlushXEvents - unexpected event type 34 [332532.557] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332533.556] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332534.554] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332535.553] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332536.551] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332537.550] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332538.564] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332539.578] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332547.237] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. [332550.700] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [332550.700] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [332550.700] winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e [332550.700] Segmentation fault at address 0x0 [332550.700] Fatal server error: [332550.700] Caught signal 11 (Segmentation fault). Server aborting [332550.700] ============================= stderr ============================= xauth: creating new authority file /home/Eliot/.serverauth.10256 xauth: (stdin):2: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):3: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):4: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):5: unknown command "916c7140476585e790ff94e6621730de" 2 [main] XWin 2964 fhandler_console::fixup_after_fork_exec: error opening input console handle for /dev/console after fork/exec, errno 9, Win32 error 6 3014 [main] XWin 2964 fhandler_console::fixup_after_fork_exec: error opening output console handle for /dev/console after fork/exec, errno 9, Win32 error 6 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Snapshot: 20100831-git-5fa9c90425fb1d68 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.10256 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/Eliot/.XWinrc not found LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Done parsing the configuration file... winGetDisplay: DISPLAY=:0.0 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0000001f winSetEngine - Using Shadow DirectDraw NonLocking winScreenInit - Using Windows display depth of 32 bits per pixel winWindowProc - WM_SIZE - new client area w: 1264 h: 732 winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff Screen 0 added at virtual desktop coordinate (0,0). 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 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! winPointerWarpCursor - Discarding first warp: 640 400 (--) 8 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 (--) Found matching XKB configuration "English (USA)" (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" winProcEstablishConnection - Hello winInitClipboard () winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winProcEstablishConnection - winInitClipboard returned. winGetDisplay: DISPLAY=:0.0 winClipboardProc - DISPLAY=:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardFlushXEvents - unexpected event type 34 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e Segmentation fault at address 0x0 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting winDeinitMultiWindowWM - Noting shutdown in progress XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 294 requests (112 known processed) with 0 events remaining. XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 1368 requests (1368 known processed) with 0 events remaining. xemacs: Fatal I/O Error 104 (Connection reset by peer) on display connection ":0.0" after 656 requests (556 known processed) with 0 events remaining. xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0" Eliot: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0" xinit: connection to X server lost. Fatal error (1). Your files have been auto-saved. Use `M-x recover-session' to recover them. [...] -- 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/ From henryptung@gmail.com Wed Sep 22 01:28:00 2010 From: henryptung@gmail.com (Henry Tung) Date: Wed, 22 Sep 2010 01:28:00 -0000 Subject: Cygwin/X bug? suspend-resume issues Message-ID: <4C995B9A.9050102@gmail.com> I've encountered an unusual behavior of Cygwin/X on suspend/resume of Windows. The server is working fine before suspend, but after the first suspend-resume cycle, the characters become single pixels. I have screenshots depicting the effects on an rxvt-unicode window, and an fwbuilder window forwarded over ssh from an Ubuntu VM (though it seems the mailing list rejected the attachments, so please let me know if there's a way I can send them). Windows in existence before the first suspend remain fine after resume, but only as long as they are open; closing and reopening them produces the broken state. The attached XWin.0.log is after two suspend/resume cycles; the two line blocks from each resume seem anomalous (bpp: 0? width: 0? height: 0?). If it helps any, I'm using Win7 x64, updated cygwin rebaseall'd (to deal with STATUS_ACCESS_VIOLATION errors from urxvt before). The X server is being started from the provided start menu link "XWin Server". xterm windows seem to be unaffected by the bug, as are urxvt windows using unaliased fonts (though the log lines still show up even without any windows open). For some reason, this issue doesn't seem to affect my desktop, which should have largely the same setup. If there's any more information I should provide, please let me know, and thanks for reading! Really hope I can get this issue fixed and get Cygwin in working order on my laptop... Also, if this issue has already been reported/fixed, feel free to ignore this. Cheers, Henry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: XWin.0.log URL: -------------- next part -------------- -- 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/ From moss@cs.umass.edu Wed Sep 22 01:59:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Wed, 22 Sep 2010 01:59:00 -0000 Subject: Cygwin/X bug? suspend-resume issues In-Reply-To: <4C995B9A.9050102@gmail.com> References: <4C995B9A.9050102@gmail.com> Message-ID: <4C9962EF.8030301@cs.umass.edu> Interesting that I just posted a report around the same issue. The latest release available through cygwin, and a later made available by John earlier this month, both SIGSEGV upon resuming after Suspend or Hibernate. This is also on a Win 7 x64 box. As for rebaseall, I've not rebased lately because I have not run into the characteristic symptoms that call for it, so I don't think that's it. Regards -- Eliot Moss -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From hummel.michel@gmail.com Wed Sep 22 09:03:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Wed, 22 Sep 2010 09:03:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> Message-ID: Hello, I've modified my patch, to change the restart process. It does not use anymore the winProcEstablishConnection wrapper to restart the clipboard but directly the winInitClipboard function. This allows to restart the clipboard more quickly and if the clipboard thread cannot connects to the server (there is a loop on connection with a delai between retries), it will die. One question : I have written my patch for the git version of the X server and the patch is not working as it on the 1.8.0-1 version. Which version would you like, perhaps the two ? Michel Hummel 2010/9/20 Michel Hummel : > 2010/9/20 Jon TURNEY : >> On 18/09/2010 19:44, michel hummel wrote: >>> >>> I have checked the code of the clipboard thread and the race condition >>> you talk about should not be a problem. >>> Before to start a new clipboard thread, the code waits for the end of >>> the first thread (pthread_join) then fixe the variable >>> g_fClipboardLaunched = FALSE; >>> g_fClipboardStarted = FALSE; >>> >>> So the new thread will never be launched before the old one has >>> terminated. >>> >>> I have a proposition of modification to make the clipboard thread more >>> robust. >>> >>> 1/ Adding a cleanup function which will be automaticaly called at the >>> end of the thread. >>> I purpose the use of the macro pthread_cleanup_push() >>> pthread_cleanup_pop() >>> >>> 2/ You said that having a long-lived thread will be a good solution to >>> simplify the code. >>> I have an other proposition which needs less modification and can >>> simplify the code : >>> By using also here the macro pthread_cleanup_push() we can >>> automaticaly restart the thread on every unexpected exit. >>> We just have to delete this restart when the exit is expected (ie. >>> End of the function) >>> With this solution we don't have to take care about the thread >>> being killed by anyone, it will be restarted. >> >> You will need to have some kind of back-off mechanism (i.e. a delay before >> retrying to connect) so that that this doesn't constantly try to connect if >> the server gets into a state where it can't accept the connection or the >> connection is constantly getting closed. > > Like I?ve implemented it : > - The clipboard thread uses the winProcEstablishConnection wrapper to > restart and so it?s waiting for a new client connection before trying > to reconnect himself. > - An other point, the restart mechanism will only be activated if the > clipboard thread has successfully been connected, otherwise the > clipboard thread will dies and not restarts (this will prevent an > infinite loop on connection error) > Those two mechanisms and the loop on ?XOpenDisplay with the sleep > (WIN_CONNECT_DELAY) between each retries should do the job isn't it ? > But if you think a connection delay is also needed in the restart > process can add one without problem > >> >>> 3/ An other thing I saw is that when the Xwindow part of the clipboard >>> is killed by an other application, the thread will still be alive but >>> the clipboard doesn't work anymore. >>> A solution can be : >>> when an winClipboardErrorHandler() is catched, check for >>> this Xwindow window and whenever this window doesn't exist anymore, >>> create a new one. >> >> Would it not be simpler to restart the clipboard thread in this situation as >> well, rather than having code to recrate the window? > > You are absolutely right, I just have to replace the window creation > with a pthread_exit(NULL); > > >> >>> What do you think about my suggestions ? >>> >>> I tested them and they seem to work as expected. >>> For example, I skipped the wrapper of XQueryTree (actualy needed for >>> xdmcp) and the clipboard is now working with xdmcp/gdm, etc. >>> >>> If you don't like something in my propositions, please tell me what >>> and I will try to adapt it. >>> >>> If you are interested in a patch doing this, I will be happy to give >>> it after a quick review and a clean >> >> That would be great, thank you. >> >> -- >> Jon TURNEY >> Volunteer Cygwin/X X Server maintainer >> > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Wed Sep 22 14:30:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 22 Sep 2010 14:30:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> Message-ID: <4C9A12F9.7050704@dronecode.org.uk> On 22/09/2010 10:03, Michel Hummel wrote: > Hello, > I've modified my patch, to change the restart process. > It does not use anymore the winProcEstablishConnection wrapper to > restart the clipboard but directly the winInitClipboard function. > > This allows to restart the clipboard more quickly and if the clipboard > thread cannot connects to the server (there is a loop on connection > with a delai between retries), it will die. > > One question : > I have written my patch for the git version of the X server and the > patch is not working as it on the 1.8.0-1 version. > Which version would you like, perhaps the two ? A patch against current git master is fine, although I don't think there have been significant changes in this area recently, so why it doesn't work for 1.8.0-1 as well is mysterious. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From d10@justpickone.org Wed Sep 22 15:34:00 2010 From: d10@justpickone.org (David T-G) Date: Wed, 22 Sep 2010 15:34:00 -0000 Subject: gvim tiny font in 1.7.7 Message-ID: <20100922153425.GG26157@justpickone.org> Hi, all -- [Let's see if I can provide all of the details the first time instead of having to go back and forth just for foundation... :-] I have used Cygwin for years and have been using the cygwin gvim (versus the Windows-native vim + gvim) for some time now. I had occasion to do a fresh install of 1.7.7 on a freshly-rebuilt laptop after a hard drive crash and so I don't think that I have any of the upgrade gotchas biting me, but stranger things have happened :-) When I first started gvim after my install, the font was invisibly tiny both for the content and for the menus. [Note that both xterm and rxvt-X are fine.] Using another computer to see where I was going and matching the keystrokes I attempted to set the font to "Lucida Console 12" but found no change. I have manually (a bummer, but I gather from the FAQs that the lack of dependency linking is temporary) added the font-bh-dpi75 and font-bh-lucidatypewriter-dpi75 packages with no effect. I have set the guifont variable in my .vimrc file, and the tiny window was somewhat differently sized but still tiny. Finally, I have of course googled for "cygwin +gvim +font (size or tiny)" and similar to see what others have found, but I haven't matched anything more useful than the guifont setting. What do I need to fix and where to make my gvim readable? TIA & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From cfouts@rti.org Wed Sep 22 17:11:00 2010 From: cfouts@rti.org (Fouts, Christopher) Date: Wed, 22 Sep 2010 17:11:00 -0000 Subject: XWin.exe parms wrapped by startwin.exe In-Reply-To: <4C9A12F9.7050704@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> Message-ID: <93FFFD33A2325C4F80A31038BF3D9DF007D2FE46@RTPWEXC20.RCC_NT.RTI.ORG> I want to run XWin much like startwin does, but with extra parameters (-logfile). What is the exact command+parms line that startwin executes to run XWin? So... Startwin.exe = Xwin.exe parm1 parm2 parm3 etc What are parm1, parm2, parm3, etc...? Thanks, Chris -- 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/ From cgfjgjgjvcgdfb@126.com Thu Sep 23 01:30:00 2010 From: cgfjgjgjvcgdfb@126.com (=?GB2312?B?us7Qocfn?=) Date: Thu, 23 Sep 2010 01:30:00 -0000 Subject: =?GB2312?B?0rXO8Q==?= Message-ID: ???????????????????????????????????????????????? ???????????????????????????????????????????????????????? ????:????????????:1:17%????????????????2:????????????????3:???????????????? ????:????????:1:????????????????2:????????????????????????3:???????????????????????????? ????:????????:1:????????????2:????????????3:????????????????????4:???????????????? 5:????????6:???????????????????????????????????????? ????????????????:???????????????????????????????????????????????????????????????????????????????????????????????????? ???????????????????????????????????????????? ????????.????????.????????.????????.????????.????????.????????.????????.????????.????..... ====????????????????==== ???????????????????????????????????????????????????????????????????????????????????????????????? ???? ???? ????:???????????? ????????????????:15889545405 ???????? Q Q????1322668584 ????????????????:WWW2211sz@163.com -- 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/ From henryptung@gmail.com Thu Sep 23 02:58:00 2010 From: henryptung@gmail.com (Henry Tung) Date: Thu, 23 Sep 2010 02:58:00 -0000 Subject: Cygwin/X bug? suspend-resume issues In-Reply-To: <4C995B9A.9050102@gmail.com> References: <4C995B9A.9050102@gmail.com> Message-ID: <4C9AC250.2080509@gmail.com> I saw the stuff about the SIGSEGV, that's quite interesting. My X server hasn't segfaulted yet, but considering the usability, it might as well have. As an update, I noticed today that my desktop has done it too (also Win 7 x64, same setup), and the corresponding XWin log is attached - seems the bug isn't caused by that odd bpp: 0 stuff after all... Cheers, Henry -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: XWin.0.log URL: -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Thu Sep 23 12:39:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 23 Sep 2010 12:39:00 -0000 Subject: XWin.exe parms wrapped by startwin.exe In-Reply-To: <93FFFD33A2325C4F80A31038BF3D9DF007D2FE46@RTPWEXC20.RCC_NT.RTI.ORG> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> <93FFFD33A2325C4F80A31038BF3D9DF007D2FE46@RTPWEXC20.RCC_NT.RTI.ORG> Message-ID: <4C9B4A8F.4040307@dronecode.org.uk> On 22/09/2010 18:11, Fouts, Christopher wrote: > I want to run XWin much like startwin does, but with extra parameters > (-logfile). What is the exact command+parms line that startwin executes > to run XWin? So... > > Startwin.exe = Xwin.exe parm1 parm2 parm3 etc > > What are parm1, parm2, parm3, etc...? Hmm... It's a bit of an omission from the startxwin man page [1], that it doesn't actually tell you it's adding '-multiwindow' However, reading that man page does tell you the syntax for adding extra server arguments (e.g. -- -logfile file) to your startxwin invokation. Note that invoking the server directly will not do the other things that startxwin does (i.e. waiting until the server is started and then executing ~/.startxwinrc) In future, please start a new email thread, rather than replying to an existing one and changing the subject. [1] http://x.cygwin.com/docs/man1/startxwin.1.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Thu Sep 23 13:10:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 23 Sep 2010 13:10:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C992C74.7080708@cs.umass.edu> References: <4C992C74.7080708@cs.umass.edu> Message-ID: <4C9B51CD.9060701@dronecode.org.uk> On 21/09/2010 23:06, Eliot Moss wrote: > Dear John -- Using the .bz2 you posted to this thread on Sept 7th > or so, I consistently get SIGSEGV on my Windows-7 box whenever > I Sleep or Hibernate the system. I include the .log file for your Thanks for reporting this issue. Does the crash also occur if you don't use -resize? > consideration, and the stderr output. Earlier versions seemed > to do ok. Is there a simple procedure for winding back? If you've installed my snapshot as XWin.exe, the easiest way to get the 1.8.2-1 version back is to reinstall it using setup. [snip] > [332511.061] winClipboardFlushXEvents - unexpected event type 34 > [332532.557] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332533.556] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332534.554] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332535.553] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332536.551] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332537.550] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332538.564] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332539.578] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332547.237] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 > [332549.343] winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message > maximum (10) reached. No more failure messages will be printed. > [332550.700] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 > [332550.700] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 > [332550.700] winCreatePrimarySurfaceShadowDDNL - Could not create primary > surface: 8876024e > [332550.700] Segmentation fault at address 0x0 > [332550.700] > Fatal server error: > [332550.700] Caught signal 11 (Segmentation fault). Server aborting > [332550.700] Unfortunately, I can't reproduce this on my Win7 system, although it is quite possible that this is specific to the display driver or hardware. If you can use gdb to generate a backtrace for this segfault, that would be most helpful. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Thu Sep 23 13:29:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 23 Sep 2010 13:29:00 -0000 Subject: Cygwin/X bug? suspend-resume issues In-Reply-To: <4C995B9A.9050102@gmail.com> References: <4C995B9A.9050102@gmail.com> Message-ID: <4C9B5650.3090004@dronecode.org.uk> On 22/09/2010 02:27, Henry Tung wrote: > I've encountered an unusual behavior of Cygwin/X on suspend/resume of Windows. > The server is working fine before suspend, but after the first > suspend-resume cycle, the characters become single pixels. I have screenshots > depicting the effects on an rxvt-unicode window, and an fwbuilder window > forwarded over ssh from an Ubuntu VM (though it seems the mailing list > rejected the attachments, so please let me know if there's a way I can send > them). Windows in existence before the first suspend remain fine after resume, > but only as long as they are open; closing and reopening them produces the > broken state. The attached XWin.0.log is after two suspend/resume cycles; the > two line blocks from each resume seem anomalous (bpp: 0? width: 0? height: 0?). Thanks for reporting this issue. Would you mind trying the test snapshot [1] to see if this improves matters? You'll need to add the '-resize' option to the X server to reproduce your current behaviour (it is erroneously on all the time in multiwindow mode with 1.8.2-1) If that doesn't help, would you mind uploading a screenshot to your favourite image hosting service? > I saw the stuff about the SIGSEGV, that's quite interesting. My X server > hasn't segfaulted yet, but considering the usability, it might as well > have. Since this seems to be related to the resize support added in 1.8.2-1, using setup.exe to revert to 1.8.0-1 should avoid these problems for the moment. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100916-git-df5773ea3927d9c1.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Thu Sep 23 13:29:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Thu, 23 Sep 2010 13:29:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B51CD.9060701@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> Message-ID: <4C9B563D.9060607@cs.umass.edu> On 9/23/2010 9:10 AM, Jon TURNEY wrote: > On 21/09/2010 23:06, Eliot Moss wrote: [I reported crash on resume after Suspend or Hibernate.] > Does the crash also occur if you don't use -resize? Yes. >> Is there a simple procedure for winding back? > > If you've installed my snapshot as XWin.exe, the easiest way to get the 1.8.2-1 version back is to > reinstall it using setup. Right; sorry I wasn't clear. I was trying the snapshot because 1.8.2-1 fails in the same way. What I meant was: Can I easily go back to a consistent set of X.org files some time *before* that .. > Unfortunately, I can't reproduce this on my Win7 system, although it is > quite possible that this is specific to the display driver or hardware. I have a Toshiba Portege M750. It has Intel Display drivers. But you know what, that got me thinking: I believe those drivers were updated recently and maybe I should try winding *them* back. > If you can use gdb to generate a backtrace for this segfault, that would be > most helpful. I understand gdb generally and all. Can you give a bit of guidance about how to start things (edits to startxwn.bat?) with gdb, to get you that back trace? Thanks for the response, Jon ... -- Eliot Moss -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Thu Sep 23 13:47:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 23 Sep 2010 13:47:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B563D.9060607@cs.umass.edu> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> Message-ID: <4C9B5A6A.6020901@dronecode.org.uk> On 23/09/2010 14:29, Eliot Moss wrote: > On 9/23/2010 9:10 AM, Jon TURNEY wrote: >> On 21/09/2010 23:06, Eliot Moss wrote: > [I reported crash on resume after Suspend or Hibernate.] > >> Does the crash also occur if you don't use -resize? > > Yes. > >>> Is there a simple procedure for winding back? >> >> If you've installed my snapshot as XWin.exe, the easiest way to get the >> 1.8.2-1 version back is to >> reinstall it using setup. > > Right; sorry I wasn't clear. I was trying the snapshot because > 1.8.2-1 fails in the same way. What I meant was: Can I easily > go back to a consistent set of X.org files some time *before* > that .. I see, thanks for the clarification. You should use setup to revert to Xserver 1.8.0-1, then :-) >> Unfortunately, I can't reproduce this on my Win7 system, although it is >> quite possible that this is specific to the display driver or hardware. > > I have a Toshiba Portege M750. It has Intel Display drivers. > But you know what, that got me thinking: I believe those > drivers were updated recently and maybe I should try winding > *them* back. > >> If you can use gdb to generate a backtrace for this segfault, that would be >> most helpful. > > I understand gdb generally and all. Can you give a bit of guidance about how > to start things (edits to startxwn.bat?) with gdb, to get you that back trace? You may find it easiest and most reliable to start XWin normally, and then (in a separate terminal window), use ps to identify the XWin processes PID, then use gdb --pid= to attach to the running XWin process, 'c' at the (gdb) prompt and then reproduce your crash... -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Thu Sep 23 13:56:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Thu, 23 Sep 2010 13:56:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B5A6A.6020901@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> Message-ID: <4C9B5C6F.4050209@cs.umass.edu> Thanks for the tips; here's your stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to thread 9084.0x19c8] 0x004158fe in winShadowUpdateDDNL (pScreen=0x19431c8, pBuf=0x1919050) at winshadddnl.c:699 699 winshadddnl.c: No such file or directory. in winshadddnl.c (gdb) i stack #0 0x004158fe in winShadowUpdateDDNL (pScreen=0x19431c8, pBuf=0x1919050) at winshadddnl.c:699 #1 0x00528e94 in shadowRedisplay (pScreen=0x19431c8) at shadow.c:61 #2 0x00528eba in shadowBlockHandler (data=0x19431c8, pTimeout=0x28cc1c, pRead=0x635800) at shadow.c:71 #3 0x00555391 in BlockHandler (pTimeout=0x28cc1c, pReadmask=0x635800) at dixutils.c:373 #4 0x005c731a in WaitForSomething (pClientsReady=0x1cb9cb8) at WaitFor.c:216 #5 0x0054c30f in Dispatch () at dispatch.c:375 #6 0x005464db in main (argc=7, argv=0x6123a6fc, envp=0x18f00f8) at main.c:286 (gdb) c Continuing. Program exited with code 01. Meanwhile I will get Intel driver info and see if reverting that gets around the problem ... Regards -- Eliot -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Thu Sep 23 14:55:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Thu, 23 Sep 2010 14:55:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B5A6A.6020901@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> Message-ID: <4C9B6A43.7080200@cs.umass.edu> So, some (good? but at least interesting) news: The version of the Intel GMA Drivers affects whether the bad behavior happens. These are GMA (Graphics Media Accelerator) drivers for Windows 7 / Vista x64 for the Intel 4 Series Express chipset. The releases are numbers 8.15.10.nnnn, where nnnn is what I will use to distinguish each one. 2202 (most recent) fails 2189 (latest send around by Windows Update) fails 2182 I have not yet tested 2104 works! 2021 probably also works (did before), but not explicitly tested The good thing is that I can now work with less annoyance. The bad thing is that I can't use the latest drivers. Let me know if there is anything I can do to help push XWin forward in handling whatever "new" it is that the Intel drivers are doing. Regards -- Eliot Moss -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Thu Sep 23 15:56:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 23 Sep 2010 15:56:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B6A43.7080200@cs.umass.edu> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> Message-ID: <4C9B789C.40101@dronecode.org.uk> On 23/09/2010 15:54, Eliot Moss wrote: > So, some (good? but at least interesting) news: > > The version of the Intel GMA Drivers affects whether > the bad behavior happens. > > These are GMA (Graphics Media Accelerator) drivers > for Windows 7 / Vista x64 for the Intel 4 Series Express > chipset. The releases are numbers 8.15.10.nnnn, where > nnnn is what I will use to distinguish each one. > > 2202 (most recent) fails > 2189 (latest send around by Windows Update) fails > 2182 I have not yet tested > 2104 works! > 2021 probably also works (did before), but not explicitly tested > > The good thing is that I can now work with less > annoyance. The bad thing is that I can't use the > latest drivers. > > Let me know if there is anything I can do to help push > XWin forward in handling whatever "new" it is that the > Intel drivers are doing. I've uploaded a new test build at [1] Hopefully this handles this error condition a bit more gracefully. Perhaps you could try it out? [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From henryptung@gmail.com Thu Sep 23 18:39:00 2010 From: henryptung@gmail.com (Henry Tung) Date: Thu, 23 Sep 2010 18:39:00 -0000 Subject: Cygwin/X bug? suspend-resume issues In-Reply-To: <4C9B5650.3090004@dronecode.org.uk> References: <4C995B9A.9050102@gmail.com> <4C9B5650.3090004@dronecode.org.uk> Message-ID: <4C9B9EC6.1090702@gmail.com> Thanks - the new snapshot seems to do the trick. I'll keep testing and report in if any issues arise, but thanks so much! -- 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/ From moss@cs.umass.edu Thu Sep 23 19:35:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Thu, 23 Sep 2010 19:35:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B789C.40101@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> Message-ID: <4C9BABD6.3050701@cs.umass.edu> On 9/23/2010 11:56 AM, Jon TURNEY wrote: > On 23/09/2010 15:54, Eliot Moss wrote: >> These are GMA (Graphics Media Accelerator) drivers >> for Windows 7 / Vista x64 for the Intel 4 Series Express >> chipset. The releases are numbers 8.15.10.nnnn, where >> nnnn is what I will use to distinguish each one. >> >> 2202 (most recent) fails >> 2189 (latest send around by Windows Update) fails >> 2182 I have not yet tested >> 2104 works! >> 2021 probably also works (did before), but not explicitly tested >> > I've uploaded a new test build at [1] > > Hopefully this handles this error condition a bit more gracefully. Perhaps you could try it out? > > [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 Thank you, yes, that no longer causes a SIGSEGV. Thanks! There is a remaining issue -- which was there before but which I had not posted about. If I Suspend/Resume, then on resumption the driver disables the Aero theme and points its finger at XWin.exe as the culprit, saying it did something incompatible with Aero. You probably know about this stuff, but here's the overall blurb anyway: ----------------------------------------- Why are some visual elements being automatically turned off? If you receive a message that some visual elements, such as window frame transparency, have been turned off, or if you receive a message that the theme has been changed to Basic theme, one of the following might have happened: A program that you're running is incompatible with Aero themes. When this happens, some visual elements are automatically turned off. When the program is no longer running, the visual elements that were turned off are turned on again automatically. Your laptop might be running low on battery power. Windows might turn off Aero themes or window transparency to save battery power. Your computer's hardware configuration or screen resolution was changed. If you changed your screen resolution, video card, or monitor setup, your computer might no longer meet the minimum recommendations for running Aero themes. Your computer does not have enough memory to run all of the programs that you have open and also run an Aero theme. If Windows automatically changed your theme to Basic theme, and you want to change it back to an Aero theme, close some windows to free up memory, and then follow the steps below. To run the Aero troubleshooter To try to get visual elements like transparency running again, use the Aero troubleshooter, which can find and fix problems automatically. Click to open the Aero troubleshooter.??? If you are prompted for an administrator password or confirmation, type the password or provide confirmation. To use an Aero theme If the troubleshooter doesn't fix the problem, try changing the theme back to an Aero theme. Click to open Personalization. Under Aero Themes, click a theme to apply it to your desktop. ------------------------------------------------------------ As soon as I exit XWin, Aero reasserts and remains if I restart XWin. This is a minor annoyance compared to SIGSEGV. Recently it has happened on *every* Resume; in the past it seemed to me that it happened only *sometimes*, with a pattern I did not figure out. So this is perhaps of lower priority, but would be nice if it were fixed at some point. Thanks again for your quick response! Regards -- Eliot Moss -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Thu Sep 23 22:08:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Thu, 23 Sep 2010 22:08:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9B789C.40101@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> Message-ID: <4C9BBDE4.20904@cs.umass.edu> On 9/23/2010 11:56 AM, Jon TURNEY wrote: > [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 Some additional evidence: Using the build above, and *not* using -resize I did not get the "Aero theme suppressed on Resume" behavior. Recalling that in some earlier version -resize was always on may explain some of my earlier experiences. So turning off -resize gets around that annoyance. But turning off -resize means that if I change screen resolution, e.g., to use a video projector for my class, then the XWin window size gets shrunk and cannot grow back, while with -resize it survives such resolution changes. Perhaps these pieces of information will help you continue to refine this very useful software! Regards -- Eliot -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From strata_ranger@hotmail.com Fri Sep 24 00:50:00 2010 From: strata_ranger@hotmail.com (Richard Gitschlag) Date: Fri, 24 Sep 2010 00:50:00 -0000 Subject: "Failed to write cache" during install Message-ID: I recently set up Cygwin and XWin on my XP system, but need help with error messages that occured during post-install scripts. My setup log file shows: > 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh > 2010/08/26 10:17:18 abnormal exit: exit code=1 > 2010/08/26 10:17:18 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-alias.sh > 2010/08/26 10:17:44 abnormal exit: exit code=1 > 2010/08/26 10:17:44 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-misc-misc.sh > 2010/08/26 10:17:52 abnormal exit: exit code=1 > 2010/08/26 10:17:52 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/fontconfig.sh > 2010/08/26 10:18:18 abnormal exit: exit code=8 Checking the verbose log shows a common theme of "failed to write cache", e.g: 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh /usr/share/fonts/75dpi: failed to write cache My local cygwin directory resides on a FAT32 drive, if that is related.? Made copies of my setup logs and can supply further information if needed. -- Stratadrake strata_ranger@hotmail.com -------------------- Numbers may not lie, but neither do they tell the whole truth. -- 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/ From s.severus@hima.com Fri Sep 24 07:31:00 2010 From: s.severus@hima.com (Sven Severus) Date: Fri, 24 Sep 2010 07:31:00 -0000 Subject: selection to clipboard in xterm Message-ID: <4C9C534D.9030506@hima.com> Hello, a couple of weeks ago I installed cygwin (1.7.5) on my new Win7-PC. On my old XP-PC the xterm-selection was a highly appreciated function to make some text accessible in the windows clipboard by simply highlighting it with the mouse, but with my new PC that does not work any more. Selections do not affect the content of the clipboard. Checking/unchecking the "Select to Clipboard" item under "VT Options" does not change anything. Any idea what the problem is and how I could get this working? Thanks for any support. Sven -- Mit freundlichen Gr????en Dipl. Inform. Sven Severus Softwareentwicklung ---------------------------------------------------------- HIMA Paul Hildebrandt GmbH + CO KG Abt: Entwicklung Software Albert-Bassermann-Strasse 28 68782 Bruehl Germany Tel: +49 6202 709-289 Fax: +49 6202 709-299 E-Mail: s.severus@hima.com Internet: www.hima.de -- HIMA Paul Hildebrandt GmbH + Co KG, Albert-Bassermann-Str. 28, 68782 Bruehl bei Mannheim Kommanditgesellschaft, Sitz Bruehl, Deutschland - Registergericht Mannheim HRA 421017 Ust-ID: DE 144286400, St.Nr: 43038 00190 Persoenlich haftende Gesellschafterin Paul Hildebrandt Verwaltungsgesellschaft mbH, Sitz Bruehl, Deutschland - Registergericht Mannheim HRB 420588 Geschaeftsfuehrer: Dipl.-Betriebswirt Steffen Philipp -- 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/ From hummel.michel@gmail.com Fri Sep 24 08:15:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Fri, 24 Sep 2010 08:15:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4C9A12F9.7050704@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> Message-ID: Hi Jon, You will find attached to this Email a patch (for the git version) which implements for the clipboard thread : - Auto cleanup function - Auto restart function for unexpected exit of the clipboard or Xerror detection - Deletion of XQuery wrapper (not needed anymore) - Deletion of all the xdmcp related tricks (not needed anymore) One thing, this patch deletes the call to EmptyClipboard () in the winProcSetSelectionOwner function of the winclipboardwrappers.c file when an "owned to not owned transition" has been detected. I don't know why but it was freezing the server for 1 or 2 seconds during clipboard's restart in xdmcp connection. It would be fine if you could tell me, when you think this patch and the previous one ( which makes the reset of the server working correctly with clipboard) will be included to the official X server? Regards, Michel Hummel 2010/9/22 Jon TURNEY > > On 22/09/2010 10:03, Michel Hummel wrote: >> >> Hello, >> I've modified my patch, to change the restart process. >> It does not use anymore the winProcEstablishConnection wrapper to >> restart the clipboard but directly the winInitClipboard function. >> >> This allows to restart the clipboard more quickly and if the clipboard >> thread cannot connects to the server (there is a loop on connection >> with a delai between retries), it will die. >> >> One question : >> I have written my patch for the git version of the X server and the >> patch is not working as it on the 1.8.0-1 version. >> Which version would you like, ?perhaps the two ? > > A patch against current git master is fine, although I don't think there have been significant changes in this area recently, so why it doesn't work for 1.8.0-1 as well is mysterious. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin_patch_restart_clipboard.path Type: application/octet-stream Size: 14770 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From gamejihou@hotmail.com Fri Sep 24 12:13:00 2010 From: gamejihou@hotmail.com (Gery) Date: Fri, 24 Sep 2010 12:13:00 -0000 Subject: selection to clipboard in xterm In-Reply-To: <4C9C534D.9030506@hima.com> References: <4C9C534D.9030506@hima.com> Message-ID: Hallo Sven Did you use the middle button of the mouse to paste the highligthed text? Sent from my iPod. On Sep 24, 2010, at 2:29, Sven Severus wrote: > Hello, > > a couple of weeks ago I installed cygwin (1.7.5) on > my new Win7-PC. > On my old XP-PC the xterm-selection was a highly > appreciated function to make some text accessible > in the windows clipboard by simply highlighting it > with the mouse, but with my new PC that does not > work any more. Selections do not affect the content > of the clipboard. > Checking/unchecking the "Select to Clipboard" item > under "VT Options" does not change anything. > Any idea what the problem is and how I could get > this working? > Thanks for any support. > > Sven > > -- > Mit freundlichen Gr??en > > Dipl. Inform. Sven Severus > Softwareentwicklung > ---------------------------------------------------------- > HIMA Paul Hildebrandt GmbH + CO KG > Abt: Entwicklung Software > Albert-Bassermann-Strasse 28 > 68782 Bruehl > Germany > > Tel: +49 6202 709-289 > Fax: +49 6202 709-299 > E-Mail: s.severus@hima.com > Internet: www.hima.de > > > -- > HIMA Paul Hildebrandt GmbH + Co KG, Albert-Bassermann-Str. 28, 68782 > Bruehl bei Mannheim > Kommanditgesellschaft, Sitz Bruehl, Deutschland - Registergericht > Mannheim HRA 421017 > Ust-ID: DE 144286400, St.Nr: 43038 00190 > > Persoenlich haftende Gesellschafterin Paul Hildebrandt > Verwaltungsgesellschaft mbH, > Sitz Bruehl, Deutschland - Registergericht Mannheim HRB 420588 > > Geschaeftsfuehrer: Dipl.-Betriebswirt Steffen Philipp > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://x.cygwin.com/docs/ > FAQ: http://x.cygwin.com/docs/faq/ > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From hummel.michel@gmail.com Fri Sep 24 15:04:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Fri, 24 Sep 2010 15:04:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> Message-ID: I found an error on the previous patch, the clipboard thread was restarting on every X clipboard error. I changed this by adding a test on the request_code error to restart the thread only if the request_code equals to 24 which is the error code for a BadWindow. It seems to me that this is better like this. This new version of the patch is named V2, Sorry for the trouble. Regards, Michel Hummel 2010/9/24 Michel Hummel > > Hi Jon, > You will find attached to this Email a patch (for the git version) > which implements for the clipboard thread : > ?- Auto cleanup function > ?- Auto restart function for unexpected exit of the clipboard or > Xerror detection > ?- Deletion of XQuery wrapper ?(not needed anymore) > ?- Deletion of all the xdmcp related tricks ?(not needed anymore) > > One thing, this patch deletes the call to EmptyClipboard () in the > winProcSetSelectionOwner function of the winclipboardwrappers.c file > when an "owned to not owned transition" has been detected. I don't > know why but it was freezing the server for 1 or 2 seconds during > clipboard's restart in xdmcp connection. > > It would be fine if you could tell me, when you think this patch and > the previous one ( which makes the reset of the server working > correctly with clipboard) will be included to the official X server? > > Regards, > Michel Hummel > > > 2010/9/22 Jon TURNEY > > > > On 22/09/2010 10:03, Michel Hummel wrote: > >> > >> Hello, > >> I've modified my patch, to change the restart process. > >> It does not use anymore the winProcEstablishConnection wrapper to > >> restart the clipboard but directly the winInitClipboard function. > >> > >> This allows to restart the clipboard more quickly and if the clipboard > >> thread cannot connects to the server (there is a loop on connection > >> with a delai between retries), it will die. > >> > >> One question : > >> I have written my patch for the git version of the X server and the > >> patch is not working as it on the 1.8.0-1 version. > >> Which version would you like, ?perhaps the two ? > > > > A patch against current git master is fine, although I don't think there have been significant changes in this area recently, so why it doesn't work for 1.8.0-1 as well is mysterious. > > > > -- > > Jon TURNEY > > Volunteer Cygwin/X X Server maintainer -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin_patch_restart_clipboardV2.path Type: application/octet-stream Size: 14903 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From frederic.bron@m4x.org Sat Sep 25 18:25:00 2010 From: frederic.bron@m4x.org (=?ISO-8859-1?Q?Fr=E9d=E9ric_Bron?=) Date: Sat, 25 Sep 2010 18:25:00 -0000 Subject: gvim tiny font in 1.7.7 In-Reply-To: <20100922153425.GG26157@justpickone.org> References: <20100922153425.GG26157@justpickone.org> Message-ID: > When I first started gvim after my install, the font was invisibly tiny > both for the content and for the menus. It is funny, I got exactly the same a few days ago. What is funny is that today it works perfectly. Have you tried to restart your X server? Fr?d?ric -- 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/ From cts.private@yahoo.com Sun Sep 26 11:28:00 2010 From: cts.private@yahoo.com (Charles Smith) Date: Sun, 26 Sep 2010 11:28:00 -0000 Subject: fvwm ignores clickToFocus for function keys Message-ID: <297050.63399.qm@web63705.mail.re1.yahoo.com> This conversation was transferred from the cygwin main list because Larry Hall said it was xfree-specific... From: Morgan Gangwere <0 dot fractalus at gmail dot com> > Sounds like something is trashing a buffer... however I'm not entirely > sure. ... > Sounds oddly configuration related... then again, i don't use fvwm on > windows. My suspicion is that it has to do with the cut-buffers/clip-board-mechanism, somehow. I'd said previously that what gets sent (when a function key is pressed but the mouse cursor isn't over the in-focus window) is the unmapped version of the function key. It might also be some earlier contents of the cut-buffer, or something like that. I'm still trying to track it down. Being able to cut-and-paste between windows and cygwin is important, and I'm glad that this evolving capability is so far along... but is it possible to disable it, at least for debugging purposes? -- 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/ From d10@justpickone.org Mon Sep 27 00:51:00 2010 From: d10@justpickone.org (David T-G) Date: Mon, 27 Sep 2010 00:51:00 -0000 Subject: gvim tiny font in 1.7.7 In-Reply-To: <20100922153425.GG26157@justpickone.org> References: <20100922153425.GG26157@justpickone.org> Message-ID: <20100927005130.GA52069@justpickone.org> Hi again, all -- ...and then David T-G said... % % Hi, all -- % ... % When I first started gvim after my install, the font was invisibly tiny % both for the content and for the menus. [Note that both xterm and rxvt-X [snip] Frederic asked if I had restarted my X server. I have logged out and in and even rebooted numerous times since installing but still have the same problem. TIA again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jon.turney@dronecode.org.uk Mon Sep 27 14:54:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 27 Sep 2010 14:54:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4C9BABD6.3050701@cs.umass.edu> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> <4C9BABD6.3050701@cs.umass.edu> Message-ID: <4CA0B006.2060608@dronecode.org.uk> On 23/09/2010 20:34, Eliot Moss wrote: > On 9/23/2010 11:56 AM, Jon TURNEY wrote: >> I've uploaded a new test build at [1] >> >> Hopefully this handles this error condition a bit more gracefully. Perhaps >> you could try it out? >> >> [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 > > Thank you, yes, that no longer causes a SIGSEGV. Thanks! Thanks for testing. > There is a remaining issue -- which was there before but > which I had not posted about. If I Suspend/Resume, then > on resumption the driver disables the Aero theme and > points its finger at XWin.exe as the culprit, saying > it did something incompatible with Aero. You probably > know about this stuff, but here's the overall blurb > anyway: I can't reproduce this, so again, it seems to be driver-specific. I presume some DirectDraw errors are still emitted over a suspend/resume cycle? Can you attach an XWin.0.log showing them? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 27 15:03:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 27 Sep 2010 15:03:00 -0000 Subject: "Failed to write cache" during install In-Reply-To: References: Message-ID: <4CA0B242.9040805@dronecode.org.uk> On 24/09/2010 01:50, Richard Gitschlag wrote: > I recently set up Cygwin and XWin on my XP system, but need help with error messages that occured during post-install scripts. > > My setup log file shows: > >> 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh >> 2010/08/26 10:17:18 abnormal exit: exit code=1 >> 2010/08/26 10:17:18 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-alias.sh >> 2010/08/26 10:17:44 abnormal exit: exit code=1 >> 2010/08/26 10:17:44 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-misc-misc.sh >> 2010/08/26 10:17:52 abnormal exit: exit code=1 >> 2010/08/26 10:17:52 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/fontconfig.sh >> 2010/08/26 10:18:18 abnormal exit: exit code=8 > > Checking the verbose log shows a common theme of "failed to write cache", e.g: > > 2010/08/26 10:17:04 running: F:\cygwin\bin\bash.exe --norc --noprofile /etc/postinstall/font-adobe-dpi75.sh > /usr/share/fonts/75dpi: failed to write cache > > My local cygwin directory resides on a FAT32 drive, if that is related. Made copies of my setup logs and can supply further information if needed. The command which is failing is 'fc-cache -f', and the cache files in question live in /var/cache/fontconfig. You might try running 'strace fc-cache -f' from a shell to see if that sheds any light on why these cache files apparently can't be written. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Mon Sep 27 15:05:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Mon, 27 Sep 2010 15:05:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4CA0B006.2060608@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> <4C9BABD6.3050701@cs.umass.edu> <4CA0B006.2060608@dronecode.org.uk> Message-ID: <4CA0B2BA.9090309@cs.umass.edu> On 9/27/2010 10:53 AM, Jon TURNEY wrote: >> There is a remaining issue -- which was there before but >> which I had not posted about. If I Suspend/Resume, then >> on resumption the driver disables the Aero theme and >> points its finger at XWin.exe as the culprit, saying >> it did something incompatible with Aero. You probably >> know about this stuff, but here's the overall blurb >> anyway: > > I can't reproduce this, so again, it seems to be driver-specific. > > I presume some DirectDraw errors are still emitted over a suspend/resume cycle? Can you attach an > XWin.0.log showing them? Yes, it is driver specific and at this point I have gone back to an earlier driver where it tends not to happen. I can try putting in a recent driver and capturing error message for you when I have a little chunk of time to mess with rebooting my system N times :-) .................. Thanks, Jon -- Eliot -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 27 15:05:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 27 Sep 2010 15:05:00 -0000 Subject: gvim tiny font in 1.7.7 In-Reply-To: <20100922153425.GG26157@justpickone.org> References: <20100922153425.GG26157@justpickone.org> Message-ID: <4CA0B2D2.8050203@dronecode.org.uk> On 22/09/2010 16:34, David T-G wrote: > Hi, all -- > > [Let's see if I can provide all of the details the first time instead of > having to go back and forth just for foundation... :-] Can you attach your /var/log/XWin.0.log, please? > I have used Cygwin for years and have been using the cygwin gvim (versus > the Windows-native vim + gvim) for some time now. I had occasion to do a > fresh install of 1.7.7 on a freshly-rebuilt laptop after a hard drive > crash and so I don't think that I have any of the upgrade gotchas biting > me, but stranger things have happened :-) > > When I first started gvim after my install, the font was invisibly tiny > both for the content and for the menus. [Note that both xterm and rxvt-X > are fine.] Using another computer to see where I was going and matching > the keystrokes I attempted to set the font to "Lucida Console 12" but > found no change. I have manually (a bummer, but I gather from the FAQs > that the lack of dependency linking is temporary) added the font-bh-dpi75 > and font-bh-lucidatypewriter-dpi75 packages with no effect. I have set > the guifont variable in my .vimrc file, and the tiny window was somewhat > differently sized but still tiny. Finally, I have of course googled for > "cygwin +gvim +font (size or tiny)" and similar to see what others have > found, but I haven't matched anything more useful than the guifont > setting. > > What do I need to fix and where to make my gvim readable? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 27 15:21:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 27 Sep 2010 15:21:00 -0000 Subject: Running Java application with drag and drop support in cygwin In-Reply-To: References: <15fe165d0910272257x18264be8sadf9d778e15d8f25@mail.gmail.com> <4AE9A9A3.7090704@dronecode.org.uk> <15fe165d0910300206n2fad7c58p9c9e69ccb5fae959@mail.gmail.com> <4AFD73A0.5030407@dronecode.org.uk> <15fe165d0912132242h3626f4f2k7eccb1e652300a63@mail.gmail.com> <15fe165d0912172153o5c48e300s63d80704d0c504c8@mail.gmail.com> <15fe165d0912230456uc64b0fenfd4bf808c8dcecd2@mail.gmail.com> Message-ID: <4CA0B655.8060809@dronecode.org.uk> On 20/09/2010 11:31, Dees wrote: > Any update? > > On Wed, Dec 23, 2009 at 6:26 PM, Dees wrote: >> >> People, any clue? Struggling really hard. >> >> On Fri, Dec 18, 2009 at 11:23 AM, Dees wrote: >>> Hi Jon, >>> >>> Did you get a chance to look at this? >>> From whatever posts available online, I could not get a clue what is >>> going wrong. >>> Please respond. >>> >>> Thanks, >>> Shefali >>> >>> On Mon, Dec 14, 2009 at 12:12 PM, Dees wrote: >>>> On Fri, Nov 13, 2009 at 8:26 PM, Jon TURNEY wrote: >>>>> On 30/10/2009 09:06, Dees wrote: >>>>>> >>>>>> Your reply is much appreciated Jon. I will try to be more specific >>>>>> about the problem in further mails. >>>>>> >>>>>> On Thu, Oct 29, 2009 at 8:11 PM, Jon TURNEY >>>>>> wrote: >>>>>>> >>>>>>> On 28/10/2009 05:57, Dees wrote: >>>>>>>> >>>>>>>> I have developed a Java application involving jTree with extensive >>>>>>>> drag and drop support, which runs correctly in my Linux box. However, >>>>>>>> when I switch to a windows box and access the same Linux box using >>>>>>>> cygwin x-server, the drag and drop in jTree stops working. >>>>>>>> Interestingly, rest of the application still works fine. After >>>>>>>> analyzing a bit I found that x-server is able to recognize the drag >>>>>>>> event but fails to recognize a drop event. >>>>>>> >>>>>>> Details? >>>>>> >>>>>> OS : Suse Linux Enterprise Server 10 (i586) >>>>>> Version : 10 >>>>>> Patch level : 3 >>>>>> Other version information: >>>>>> Java : JDK 5 >>>>>> Cygwin setup-version: 2.573.2.3 >>>>>> Also tried using Xming 6.9.0.31 ssh same Linux setup from Windows, but >>>>>> that also doesn't solve the problem. >>>>>> >>>>>>> >>>>>>>> Is there any setting, which should be done prior to running the Java >>>>>>>> swing applications? >>>>>>>> >>>>>>>> Here is a sample code which behaves in exactly same way. >>>>>>>> http://www.java2s.com/Code/Java/Swing-JFC/TreeDragandDrop.htm >>>>>>> >>>>>>> I have no idea how to use that java code to reproduce the problem you are >>>>>>> seeing. >>>>>> >>>>>> Using the above java code in Linux: >>>>>> 1. Download and Install Java Development Toolkit on your Linux box >>>>>> (Java sun download site: >>>>>> http://java.sun.com/javase/downloads/index.jsp), if you do not have it >>>>>> already. >>>>>> 2. Save the sample code in the above link with the file name >>>>>> TreeTester.java, say in /home/user/ >>>>>> 3. Navigate to TreeTester.java from shell, and compile the java code: >>>>>> # cd /home/user/ >>>>>> # /usr/java/jdk1.5.0_14/bin/javac TreeTester.java >>>>>> Ignore any warnings of deprecated APIs. >>>>>> 4. This will create a few .class files in /home/user/ directory. Final >>>>>> step is to run the Java code, using: >>>>>> # /usr/java/jdk1.5.0_14/bin/java -classpath . TreeTester >>>>>> This will open up a GUI, with a jTree each on left and right pane. >>>>>> You can drag and drop any of the leaf nodes from one jTree to the root >>>>>> node of the other jTree and this should add a new node in the other >>>>>> jTree. You will get messages on console for the operations being >>>>>> performed. Now ssh the same box using cygwin/xming from any other >>>>>> windows box, and run the application using command in step 4. You >>>>>> should be able to drag (a small icon will come under cursor indicating >>>>>> that something is being dragged) but when you will drop it, the new >>>>>> node would not be added to the tree. Thats where lies my problem!!! >>>>> >>>>> Thanks for the test case and instructions, this makes it much easier for me >>>>> to try it out. >>>>> >>>>> However, this testcase and your jar archive both work fine for me (using >>>>> Xserver 1.7.1-3)! Given that the test case works for me, but not for you, I suspect this going to be another Java bug (e.g. [1],[2]), which is fixed in the JDK I am using. If this isn't fixed with the latest Xserver, I guess it might be possible to put another workaround into the Xserver, if I knew what the problem was, but since JDK 5 was EOL November 2009 [3], I'm not sure if it's worth the effort. Looking at that, you don't seem to be using the last update (update 22), either. [1] http://cygwin.com/ml/cygwin-xfree/2010-07/msg00034.html [2] http://sourceware.org/bugzilla/show_bug.cgi?id=9848 [3] http://www.oracle.com/technetwork/java/javase/downloads/index-jdk5-jsp-142662.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jon.turney@dronecode.org.uk Mon Sep 27 15:26:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 27 Sep 2010 15:26:00 -0000 Subject: fvwm ignores clickToFocus for function keys In-Reply-To: <297050.63399.qm@web63705.mail.re1.yahoo.com> References: <297050.63399.qm@web63705.mail.re1.yahoo.com> Message-ID: <4CA0B7BE.5060701@dronecode.org.uk> On 26/09/2010 12:28, Charles Smith wrote: > This conversation was transferred from the cygwin main list because Larry Hall said it was xfree-specific... > > From: Morgan Gangwere<0 dot fractalus at gmail dot com> >> Sounds like something is trashing a buffer... however I'm not entirely >> sure. > ... >> Sounds oddly configuration related... then again, i don't use fvwm on >> windows. > > My suspicion is that it has to do with the cut-buffers/clip-board-mechanism, somehow. > > I'd said previously that what gets sent (when a function key is pressed but the mouse cursor isn't over the in-focus window) is the unmapped version of the function key. It might also be some earlier contents of the cut-buffer, or something like that. I'm still trying to track it down. > > Being able to cut-and-paste between windows and cygwin is important, and I'm glad that this evolving capability is so far along... but is it possible to disable it, at least for debugging purposes? 'man XWin' [1] documents the -noclipboard option. [1] http://x.cygwin.com/docs/man1/XWin.1.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From hummel.michel@gmail.com Mon Sep 27 15:43:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Mon, 27 Sep 2010 15:43:00 -0000 Subject: Git version, XWin dies in cygwin but not in Windows Message-ID: I am testing the git version of the XWin server (I don't know if it is the good place to talk about this version) and I am experiencing a problem (May be it is also a problem on the official Xwin). Sometime ( I can not make a reproducible test case) when the server stops, the Xwin process disappears from Cygwin (as expected) but the Windows process XWin.exe still be alive. After some investigations (I'm not a good Windows hacker) it seems that the process hangs on the call to PostQuitMessage (0); of the function ddxGiveUp of the file InitOutput.c I can't tell why (Like I said, I'm not a good Windows hacker) but my tests seems to show that delete this call fixes the bug (may be there is no link ). Is it possible that this problem lies to the fact that the main window is destroyed before the call to PostQuitMessage (So the WM_QUIT message can't be treated isn't it ?) Well It's a question more than a notice. Thanks, Michel Hummel -- 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/ From moss@cs.umass.edu Mon Sep 27 20:52:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Mon, 27 Sep 2010 20:52:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4CA0B006.2060608@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> <4C9BABD6.3050701@cs.umass.edu> <4CA0B006.2060608@dronecode.org.uk> Message-ID: <4CA10414.1090500@cs.umass.edu> It turned out to be easy to get a log where the Aero mode got turned off after a resume. Here it is (stderr comes after it). Thanks -- Eliot Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Snapshot: 20100923-git-2172af4d1ea713f1 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.8420 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - primary monitor w 1280 h 800 winInitializeDefaultScreens - native DPI x 96 y 96 winInitializeDefaultScreens - Returning [ 6203.270] winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 [ 6203.270] (II) xorg.conf is not supported [ 6203.270] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 6203.270] LoadPreferences: /home/Eliot/.XWinrc not found [ 6203.270] LoadPreferences: Loading /etc/X11/system.XWinrc [ 6203.270] LoadPreferences: Done parsing the configuration file... [ 6203.270] winGetDisplay: DISPLAY=:0.0 [ 6203.270] winDetectSupportedEngines - Windows NT/2000/XP [ 6203.286] winDetectSupportedEngines - DirectDraw installed [ 6203.286] winDetectSupportedEngines - Allowing PrimaryDD [ 6203.286] winDetectSupportedEngines - DirectDraw4 installed [ 6203.286] winDetectSupportedEngines - Returning, supported engines 0000001f [ 6203.286] winSetEngine - Using Shadow DirectDraw NonLocking [ 6203.286] winScreenInit - Using Windows display depth of 32 bits per pixel [ 6203.317] winWindowProc - WM_SIZE - new client area w: 1264 h: 732 [ 6203.332] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff [ 6203.332] Screen 0 added at virtual desktop coordinate (0,0). [ 6203.332] MIT-SHM extension disabled due to lack of kernel support [ 6203.348] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 6203.364] (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so [ 6203.364] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 6203.379] [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! [ 6203.800] winPointerWarpCursor - Discarding first warp: 640 400 [ 6203.800] (--) 8 mouse buttons found [ 6203.800] (--) Setting autorepeat to delay=500, rate=31 [ 6203.800] (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 [ 6203.800] (--) Found matching XKB configuration "English (USA)" [ 6203.800] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 6203.800] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" [ 6203.816] winProcEstablishConnection - Hello [ 6203.956] winInitClipboard () [ 6203.956] winClipboardProc - Hello [ 6203.956] DetectUnicodeSupport - Windows NT/2000/XP [ 6203.956] winProcEstablishConnection - winInitClipboard returned. [ 6203.956] winGetDisplay: DISPLAY=:0.0 [ 6203.956] winClipboardProc - DISPLAY=:0.0 [ 6203.956] winClipboardProc - XOpenDisplay () returned and successfully opened the display. [ 6204.409] winClipboardFlushXEvents - unexpected event type 34 [ 6206.952] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [ 12055.835] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 12055.835] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 13684.064] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 13684.064] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 16856.313] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 16856.313] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 20387.614] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 20387.614] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 21698.584] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 21698.584] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 56138.285] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 56138.285] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 61047.949] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 61047.949] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 66152.832] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 66152.832] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 67952.225] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 67952.225] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 71279.150] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71279.742] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71279.852] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.054] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.678] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.819] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71280.990] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71281.614] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71281.833] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71281.926] winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 [ 71281.926] winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. [ 95677.955] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 95679.984] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [ 95680.951] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [ 95680.951] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [108155.633] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [108155.633] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [140787.860] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [140787.907] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [149078.954] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [149078.954] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [151271.033] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [151271.189] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [154936.901] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [154936.901] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [156990.124] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [156990.124] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [167162.184] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [167162.184] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [167493.671] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [167493.671] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [185029.385] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [185029.385] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [186032.783] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [186032.783] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [191662.422] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [191662.422] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [192626.212] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [192626.212] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [195477.614] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [195477.614] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [229389.330] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [229389.330] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [235670.975] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [235670.975] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [255421.092] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [255421.092] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [266483.544] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [266483.544] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [268633.331] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [268633.331] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [277715.990] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [277715.990] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [280569.779] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [280569.779] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [315299.267] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [315299.267] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [320272.673] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [320272.673] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [329780.762] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [329780.762] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [336836.344] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [336836.407] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [341544.844] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [341544.844] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [341623.734] winWindowProc - WM_SIZE - new client area w: 1280 h: 778 [341635.777] winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 [341635.777] winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 800 [341638.429] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [341765.913] winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 [341765.913] winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 768 [341766.210] winWindowProc - WM_SIZE - new client area w: 1024 h: 716 [346074.895] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 [346074.957] winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 2 [346447.909] winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 [346447.909] winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 800 [346448.096] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [347468.000] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [347468.000] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 [347582.146] winWindowProc - WM_SIZE - new client area w: 1280 h: 748 [350773.536] winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 [350773.536] winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 ... and here is the XWin.0.stderr file: xauth: creating new authority file /home/Eliot/.serverauth.8420 xauth: (stdin):2: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):3: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):4: unknown command "916c7140476585e790ff94e6621730de" xauth: (stdin):5: unknown command "916c7140476585e790ff94e6621730de" 1661 [main] XWin 7332 fhandler_console::fixup_after_fork_exec: error opening input console handle for /dev/console after fork/exec, errno 9, Win32 error 6 3135 [main] XWin 7332 fhandler_console::fixup_after_fork_exec: error opening output console handle for /dev/console after fork/exec, errno 9, Win32 error 6 Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.8.2.0 (10802000) Snapshot: 20100923-git-2172af4d1ea713f1 XWin was started with the following command line: /usr/bin/X :0 -unixkill -clipboard -multimonitors -resize -auth /home/Eliot/.serverauth.8420 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 (II) xorg.conf is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information LoadPreferences: /home/Eliot/.XWinrc not found LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Done parsing the configuration file... winGetDisplay: DISPLAY=:0.0 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0000001f winSetEngine - Using Shadow DirectDraw NonLocking winScreenInit - Using Windows display depth of 32 bits per pixel winWindowProc - WM_SIZE - new client area w: 1264 h: 732 winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff Screen 0 added at virtual desktop coordinate (0,0). 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 (II) AIGLX: Loaded and initialized /usr/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 [dix] Could not init font path element /usr/share/fonts/OTF/, removing from list! winPointerWarpCursor - Discarding first warp: 640 400 (--) 8 mouse buttons found (--) Setting autorepeat to delay=500, rate=31 (--) Windows keyboard layout: "00000409" (00000409) "US", type 4 (--) Found matching XKB configuration "English (USA)" (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none" Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none" winProcEstablishConnection - Hello winInitClipboard () winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winProcEstablishConnection - winInitClipboard returned. winGetDisplay: DISPLAY=:0.0 winClipboardProc - DISPLAY=:0.0 winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardFlushXEvents - unexpected event type 34 winWindowProc - WM_SIZE - new client area w: 1280 h: 748 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_SIZE - new client area w: 1280 h: 778 winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 800 winWindowProc - WM_SIZE - new client area w: 1280 h: 748 winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 768 winWindowProc - WM_SIZE - new client area w: 1024 h: 716 winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 1 winBltExposedRegionsShadowDDNL - IDirectDrawSurface4_Blt reported that the primary surface was lost, trying to restore, retry: 2 winWindowProc - WM_DISPLAYCHANGE - new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 800 winWindowProc - WM_SIZE - new client area w: 1280 h: 748 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 winWindowProc - WM_SIZE - new client area w: 1280 h: 748 winWindowProc - WM_DISPLAYCHANGE - new bpp: 0 winWindowProc - WM_DISPLAYCHANGE - new width: 0 new height: 0 -------- End of email -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From moss@cs.umass.edu Mon Sep 27 21:04:00 2010 From: moss@cs.umass.edu (Eliot Moss) Date: Mon, 27 Sep 2010 21:04:00 -0000 Subject: SIGSEGV in xorg-1.8.2.0 during -resize operation In-Reply-To: <4CA0B006.2060608@dronecode.org.uk> References: <4C992C74.7080708@cs.umass.edu> <4C9B51CD.9060701@dronecode.org.uk> <4C9B563D.9060607@cs.umass.edu> <4C9B5A6A.6020901@dronecode.org.uk> <4C9B6A43.7080200@cs.umass.edu> <4C9B789C.40101@dronecode.org.uk> <4C9BABD6.3050701@cs.umass.edu> <4CA0B006.2060608@dronecode.org.uk> Message-ID: <4CA106C0.70701@cs.umass.edu> A small suggestion: I have twice been bitten by the fact that I cannot just send an XWin log to the cygwin-xfree list. This is because the log contains an email address, so the cygwin email serve bounces the message. If the format of the email address in the log used " at " rather than a literal at-sign, then I probably *could* email a log. Something to think about ... Regards -- EM -- 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/ From s.severus@hima.com Tue Sep 28 07:06:00 2010 From: s.severus@hima.com (Sven Severus) Date: Tue, 28 Sep 2010 07:06:00 -0000 Subject: selection to clipboard in xterm Message-ID: <4CA19319.1050704@hima.com> Hallo Gery, thanks for your reply. Inside xterm the middle button works fine to paste, but what I need is to paste in arbitrary windows applications - just by using the windows clipboard. And that does not work. Sven > Hallo Sven > > Did you use the middle button of the mouse to paste the highligthed text? > > Sent from my iPod. -- Mit freundlichen Gr????en Dipl. Inform. Sven Severus Softwareentwicklung ---------------------------------------------------------- HIMA Paul Hildebrandt GmbH + CO KG Abt: Entwicklung Software Albert-Bassermann-Strasse 28 68782 Bruehl Germany Tel: +49 6202 709-289 Fax: +49 6202 709-299 E-Mail: s.severus@hima.com Internet: www.hima.de -- HIMA Paul Hildebrandt GmbH + Co KG, Albert-Bassermann-Str. 28, 68782 Bruehl bei Mannheim Kommanditgesellschaft, Sitz Bruehl, Deutschland - Registergericht Mannheim HRA 421017 Ust-ID: DE 144286400, St.Nr: 43038 00190 Persoenlich haftende Gesellschafterin Paul Hildebrandt Verwaltungsgesellschaft mbH, Sitz Bruehl, Deutschland - Registergericht Mannheim HRB 420588 Geschaeftsfuehrer: Dipl.-Betriebswirt Steffen Philipp -- 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/ From jon.turney@dronecode.org.uk Tue Sep 28 14:39:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 28 Sep 2010 14:39:00 -0000 Subject: Git version, XWin dies in cygwin but not in Windows In-Reply-To: References: Message-ID: <4CA1FE2F.2010903@dronecode.org.uk> On 27/09/2010 16:43, Michel Hummel wrote: > I am testing the git version of the XWin server (I don't know if it is > the good place to talk about this version) This is absolutely the right place :-) I presume by 'git version' you mean the X.Org master tree. > and I am experiencing a > problem (May be it is also a problem on the official Xwin). > Sometime ( I can not make a reproducible test case) when the server > stops, the Xwin process disappears from Cygwin (as expected) but the > Windows process XWin.exe still be alive. There are currently quite a few patches applied on top of the X.Org releases to make the cygwin released version (cygwin releases are tagged in [1]), at least one of which is related to stability during shutdown [5]. If you want a tree with those patches forward ported to xserver 1.9, take a look at [2] Sorry that the contributors guide documentation is somewhat out of date and doesn't contain this information. > After some investigations (I'm not a good Windows hacker) it seems > that the process hangs on the call to PostQuitMessage (0); of the > function ddxGiveUp of the file InitOutput.c > > I can't tell why (Like I said, I'm not a good Windows hacker) but my > tests seems to show that delete this call fixes the bug (may be there > is no link ). > > Is it possible that this problem lies to the fact that the main window > is destroyed before the call to PostQuitMessage (So the WM_QUIT > message can't be treated isn't it ?) That shouldn't be the case, PostMessage() [3] functions are supposed to by asynchronous (unlike SendMessage() [4] which is synchronous, waiting for the message to be processed before returning) [1] http://cgit.freedesktop.org/~yselkowitz/xserver/ [2] http://cgit.freedesktop.org/~jturney/xserver/log/?h=cygwin-1.9-testing [3] http://msdn.microsoft.com/en-us/library/ms644945%28VS.85%29.aspx [4] http://msdn.microsoft.com/en-us/library/ms644950%28VS.85%29.aspx [5] http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8&id=9cbbc1e8aefc6111f6ccdc73c061337508061996 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jjreisert@alum.mit.edu Tue Sep 28 16:31:00 2010 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Tue, 28 Sep 2010 16:31:00 -0000 Subject: selection to clipboard in xterm In-Reply-To: <4CA19319.1050704@hima.com> References: <4CA19319.1050704@hima.com> Message-ID: On Tue, Sep 28, 2010 at 1:02 AM, Sven Severus wrote: > thanks for your reply. > Inside xterm the middle button works fine to paste, > but what I need is to paste in arbitrary windows > applications - just by using the windows clipboard. > And that does not work. Have you tried SHIFT+INSERT to paste text into those windows? -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From jon.turney@dronecode.org.uk Tue Sep 28 20:12:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 28 Sep 2010 20:12:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> Message-ID: <4CA24C35.8010001@dronecode.org.uk> On 24/09/2010 09:15, Michel Hummel wrote: > Hi Jon, Firstly, thanks very much for looking at this. > You will find attached to this Email a patch (for the git version) > which implements for the clipboard thread : > - Auto cleanup function > - Auto restart function for unexpected exit of the clipboard or > Xerror detection > - Deletion of XQuery wrapper (not needed anymore) > - Deletion of all the xdmcp related tricks (not needed anymore) For purposes of review it would be easier to split this patch into two separate patches, (i) the clipboard thread changes and (ii) removing the unneeded xdmcp tricks. > One thing, this patch deletes the call to EmptyClipboard () in the > winProcSetSelectionOwner function of the winclipboardwrappers.c file > when an "owned to not owned transition" has been detected. I don't > know why but it was freezing the server for 1 or 2 seconds during > clipboard's restart in xdmcp connection. Hmmm... I wonder if that's something to do with how we process the WM_DESTROYCLIPBOARD message? In any case, this should not be happening. > It would be fine if you could tell me, when you think this patch and > the previous one ( which makes the reset of the server working > correctly with clipboard) will be included to the official X server? We don't have a regular release cycle for the cygwin X server, so I can't answer that question accurately. I shall put your previous patch into the next release and assuming it works well, be pushing it upstream sometime before xserver 1.10 I think this patch needs a little more work. I'm still a little concerned that there is no rate-limiting on the clipboard restart mechanism, so in a pathological case (e.g. where some unanticipated error causes the clipboard to constantly get disconnected), this will spin using all available CPU. Some detailed comments below. > --- /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/InitInput.c 2010-08-18 22:10:54.000000000 +0200 > +++ hw/xwin/InitInput.c 2010-09-17 17:03:08.611244200 +0200 > @@ -127,12 +127,6 @@ InitInput (int argc, char *argv[]) > winProcEstablishConnectionOrig = InitialVector[2]; > InitialVector[2] = winProcEstablishConnection; > } > - if (g_fXdmcpEnabled > - && ProcVector[X_QueryTree] != winProcQueryTree) > - { > - winProcQueryTreeOrig = ProcVector[X_QueryTree]; > - ProcVector[X_QueryTree] = winProcQueryTree; > - } > #endif > > g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE); > --- /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin//winclipboardthread.c 2010-08-18 22:10:54.000000000 +0200 > +++ hw/xwin/winclipboardthread.c 2010-09-24 16:48:20.689125100 +0200 > @@ -48,6 +48,8 @@ > extern Bool g_fUnicodeClipboard; > extern unsigned long serverGeneration; > extern Bool g_fClipboardStarted; > +extern Bool g_fClipboardLaunched; > +extern Bool g_fClipboard; > extern HWND g_hwndClipboard; > extern void *g_pClipboardDisplay; > extern Window g_iClipboardWindow; > @@ -72,8 +74,113 @@ winClipboardErrorHandler (Display *pDisp > static int > winClipboardIOErrorHandler (Display *pDisplay); > > +static void > +restartClipboardThread(void *pvNotUsed); > + > +static void > +winClipboardCleanup(void *vfdMessageQueue); > + > > /* > + * restartClipboardThread activate the ProcEstablishConnection wrapper which will start > + * the thread after next client connection > + */ This comment doesn't appear to be correct. winInitClipboard() starts the thread itself. It looks like this could fight with the ProcEstablishConnection wrapper, which will call winInitClipboard() once for each server generation. > + > +static void restartClipboardThread(void *pvNotUsed) > +{ > + winDebug("restartClipboardThread - enter \n"); > + if (g_fClipboard) > + { > + ErrorF("restartClipboardThread - trying to restart clipboard thread \n"); > + /* Create the clipboard client thread */ > + if (!winInitClipboard ()) > + { > + ErrorF ("restartClipboardThread - winClipboardInit " > + "failed.\n"); > + return; > + } > + > + winDebug ("restartClipboardThread - winInitClipboard returned.\n"); > + /* Flag that clipboard client has been launched */ > + g_fClipboardLaunched = TRUE; > + } > + else > + { > + ErrorF ("restartClipboardThread - Clipboard disabled - Exit from server \n"); > + return; > + } > + return; > +} > + > +/* > + * winClipboardCleanup clean thread before exit > + */ > + > +static void winClipboardCleanup(void *vfdMessageQueue) > +{ > + int iReturn; > + int fdMessageQueue = (int) vfdMessageQueue; > + > + winDebug("winClipboardCleanup - Enter \n"); > + CloseClipboard(); > + /* Close our Windows window */ > + if (g_hwndClipboard ) > + { > + /* Destroy the Window window (hwnd) */ > + winDebug("winClipboardCleanup - Destroy Windows window\n"); > + PostMessage (g_hwndClipboard,WM_DESTROY, 0, 0); > + winClipboardFlushWindowsMessageQueue(g_hwndClipboard); > + } > + > + /* Close our X window */ > + if (g_pClipboardDisplay && g_iClipboardWindow) > + { > + iReturn = XDestroyWindow (g_pClipboardDisplay, g_iClipboardWindow); > + if (iReturn == BadWindow) > + ErrorF ("winClipboardCleanup - XDestroyWindow returned BadWindow.\n"); > + else > + winDebug ("winClipboardCleanup - winClipboardProc - XDestroyWindow succeeded.\n"); > + } > + > + > +#ifdef HAS_DEVWINDOWS > + /* Close our Win32 message handle */ > + if (fdMessageQueue) > + close (fdMessageQueue); > +#endif > + > +#if 0 > + /* > + * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. The > + * XSync and XSelectInput calls did not help. > + */ > + > + /* Discard any remaining events */ > + XSync (g_pClipboardDisplay, TRUE); > + > + /* Select event types to watch */ > + XSelectInput (g_pClipboardDisplay, > + DefaultRootWindow (g_pClipboardDisplay), > + None); > + > + /* Close our X display */ > + if (g_pClipboardDisplay) > + { > + XCloseDisplay (g_pClipboardDisplay); > + } > +#endif > + > + /* global clipboard variable reset */ > + g_fClipboardLaunched = FALSE; > + g_fClipboardStarted = FALSE; > + g_iClipboardWindow = None; > + g_hwndClipboard = NULL; > + g_fUnicodeClipboard = FALSE; > + g_pClipboardDisplay = NULL; > + winDebug("winClipboardCleanup - Exit \n"); > + > +} Rather than 2 separate functions which we pthread_cleanup_push separately, but never use independently, can these be combined? Or create a cleanup fn which calls both of them, and push that? > +/* > * Main thread function > */ > > @@ -84,9 +191,8 @@ winClipboardProc (void *pvNotUsed) > int iReturn; > HWND hwnd = NULL; > int iConnectionNumber = 0; > -#ifdef HAS_DEVWINDOWS > int fdMessageQueue = 0; > -#else > +#ifndef HAS_DEVWINDOWS > struct timeval tvTimeout; > #endif > fd_set fdsRead; > @@ -122,24 +228,6 @@ winClipboardProc (void *pvNotUsed) > ErrorF ("winClipboardProc - Warning: Locale not supported by X.\n"); > } > > - /* Set jump point for Error exits */ > - iReturn = setjmp (g_jmpEntry); > - > - /* Check if we should continue operations */ > - if (iReturn != WIN_JMP_ERROR_IO > - && iReturn != WIN_JMP_OKAY) > - { > - /* setjmp returned an unknown value, exit */ > - ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", > - iReturn); > - pthread_exit (NULL); > - } > - else if (iReturn == WIN_JMP_ERROR_IO) > - { > - /* TODO: Cleanup the Win32 window and free any allocated memory */ > - ErrorF ("winClipboardProc - setjmp returned for IO Error Handler.\n"); > - pthread_exit (NULL); > - } > > /* Use our generated cookie for authentication */ > winSetAuthorization(); > @@ -216,6 +304,25 @@ winClipboardProc (void *pvNotUsed) > iMaxDescriptor = iConnectionNumber + 1; > #endif > > + /* Adding a cleanup process for thread exit > + * Warning : A call to pthread_cleanup_push() implies a call to pthread_cleanup_pop() at the same code level (function) > + * We also use it to automaticaly restart the thread on unexpected exit (ie. pthread_exit() when g_pClipboard != TRUE ) > + * this is a LIFO stack ( Last In First Out ) so adding "restart" then "clean" > + */ > + /* Install the restart function to be called */ > + pthread_cleanup_push(restartClipboardThread, NULL); > + /* install the cleanup function to be called at thread exit */ > + pthread_cleanup_push(winClipboardCleanup, (void*) &fdMessageQueue); > + /* The only way to exit from this loop is to : > + * 1/ Exit before the installation this cleanup process > + * 2/ Doing the "expected" Exit (ie. End of the function) which disable the restart > + * by setting g_pClipboard to FALSE; > + * before calling the cleanup handler : > + * pthread_cleanup_pop(1); > + * then the restart handler which will be an Exit handler because g_pClipboard != TRUE : > + * pthread_cleanup_pop(1); > + */ > + > /* Create atoms */ > atomClipboard = XInternAtom (pDisplay, "CLIPBOARD", False); > atomClipboardManager = XInternAtom (pDisplay, "CLIPBOARD_MANAGER", False); > @@ -292,6 +399,26 @@ winClipboardProc (void *pvNotUsed) > /* Signal that the clipboard client has started */ > g_fClipboardStarted = TRUE; > > + > + /* Set jump point for Error exits */ > + iReturn = setjmp (g_jmpEntry); > + > + /* Check if we should continue operations */ > + if (iReturn != WIN_JMP_ERROR_IO > + && iReturn != WIN_JMP_OKAY) > + { > + /* setjmp returned an unknown value, exit */ > + ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", > + iReturn); > + pthread_exit (NULL); > + } > + else if (iReturn == WIN_JMP_ERROR_IO) > + { > + /* TODO: Cleanup the Win32 window and free any allocated memory */ > + ErrorF ("winClipboardProc - setjmp returned for IO Error Handler.\n"); > + pthread_exit (NULL); > + } > + > /* Loop for X events */ > while (1) > { > @@ -377,47 +504,10 @@ winClipboardProc (void *pvNotUsed) > } > } > > - /* Close our X window */ > - if (pDisplay && iWindow) > - { > - iReturn = XDestroyWindow (pDisplay, iWindow); > - if (iReturn == BadWindow) > - ErrorF ("winClipboardProc - XDestroyWindow returned BadWindow.\n"); > - else > - ErrorF ("winClipboardProc - XDestroyWindow succeeded.\n"); > - } > - > - > -#ifdef HAS_DEVWINDOWS > - /* Close our Win32 message handle */ > - if (fdMessageQueue) > - close (fdMessageQueue); > -#endif > - > -#if 0 > - /* > - * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. The > - * XSync and XSelectInput calls did not help. > - */ > - > - /* Discard any remaining events */ > - XSync (pDisplay, TRUE); > - > - /* Select event types to watch */ > - XSelectInput (pDisplay, > - DefaultRootWindow (pDisplay), > - None); > - > - /* Close our X display */ > - if (pDisplay) > - { > - XCloseDisplay (pDisplay); > - } > -#endif > - > - g_iClipboardWindow = None; > - g_pClipboardDisplay = NULL; > - g_hwndClipboard = NULL; > + /* disable the clipboard means thread restart function will kill the server */ > + g_fClipboard = FALSE; > + pthread_cleanup_pop(1); > + pthread_cleanup_pop(1); The use of pthread_cleanup really obscures what's going on here. It would be clearer just to have a label error_exit: here and goto it from the various places which pthread_exit... > > return NULL; > } > @@ -431,7 +521,7 @@ static int > winClipboardErrorHandler (Display *pDisplay, XErrorEvent *pErr) > { > char pszErrorMsg[100]; > - > + No unnecessary whitespace changes, please. > XGetErrorText (pDisplay, > pErr->error_code, > pszErrorMsg, > @@ -442,6 +532,13 @@ winClipboardErrorHandler (Display *pDisp > pErr->serial, > pErr->request_code, > pErr->minor_code); > + > + /* If the Xerror is BadWindow Error, restart the thread */ > + if ( pErr->request_code == 24 ) > + { > + ErrorF("winClipboardErrorHandler - Badwindow detected, restarting clipboard thread\n"); > + pthread_exit(NULL); > + } How do we get into this situation? Window has been deleted by someone else, but we are still connected to the server? > return 0; > } > > --- /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/winclipboardwrappers.c 2010-08-18 22:10:54.000000000 +0200 > +++ hw/xwin/winclipboardwrappers.c 2010-09-22 10:06:00.232451900 +0200 > @@ -53,7 +53,6 @@ > */ > > DISPATCH_PROC(winProcEstablishConnection); > -DISPATCH_PROC(winProcQueryTree); > DISPATCH_PROC(winProcSetSelectionOwner); > > > @@ -79,104 +78,6 @@ extern winDispatchProcPtr winProcSetSele > > > /* > - * Wrapper for internal QueryTree function. > - * Hides the clipboard client when it is the only client remaining. > - */ > - > -int > -winProcQueryTree (ClientPtr client) > -{ > - int iReturn; > - > - ErrorF ("winProcQueryTree - Hello\n"); > - > - /* > - * This procedure is only used for initialization. > - * We can unwrap the original procedure at this point > - * so that this function is no longer called until the > - * server resets and the function is wrapped again. > - */ > - ProcVector[X_QueryTree] = winProcQueryTreeOrig; > - > - /* > - * Call original function and bail if it fails. > - * NOTE: We must do this first, since we need XdmcpOpenDisplay > - * to be called before we initialize our clipboard client. > - */ > - iReturn = (*winProcQueryTreeOrig) (client); > - if (iReturn != 0) > - { > - ErrorF ("winProcQueryTree - ProcQueryTree failed, bailing.\n"); > - return iReturn; > - } > - > - /* Make errors more obvious */ > - winProcQueryTreeOrig = NULL; > - > - /* Do nothing if clipboard is not enabled */ > - if (!g_fClipboard) > - { > - ErrorF ("winProcQueryTree - Clipboard is not enabled, " > - "returning.\n"); > - return iReturn; > - } > - > - /* If the clipboard client has already been started, abort */ > - if (g_fClipboardLaunched) > - { > - ErrorF ("winProcQueryTree - Clipboard client already " > - "launched, returning.\n"); > - return iReturn; > - } > - > - /* Startup the clipboard client if clipboard mode is being used */ > - if (g_fXdmcpEnabled && g_fClipboard) > - { > - /* > - * NOTE: The clipboard client is started here for a reason: > - * 1) Assume you are using XDMCP (e.g. XWin -query %hostname%) > - * 2) If the clipboard client attaches during X Server startup, > - * then it becomes the "magic client" that causes the X Server > - * to reset if it exits. > - * 3) XDMCP calls KillAllClients when it starts up. > - * 4) The clipboard client is a client, so it is killed. > - * 5) The clipboard client is the "magic client", so the X Server > - * resets itself. > - * 6) This repeats ad infinitum. > - * 7) We avoid this by waiting until at least one client (could > - * be XDM, could be another client) connects, which makes it > - * almost certain that the clipboard client will not connect > - * until after XDM when using XDMCP. > - * 8) Unfortunately, there is another problem. > - * 9) XDM walks the list of windows with XQueryTree, > - * killing any client it finds with a window. > - * 10)Thus, when using XDMCP we wait until the first call > - * to ProcQueryTree before we startup the clipboard client. > - * This should prevent XDM from finding the clipboard client, > - * since it has not yet created a window. > - * 11)Startup when not using XDMCP is handled in > - * winProcEstablishConnection. > - */ > - > - /* Create the clipboard client thread */ > - if (!winInitClipboard ()) > - { > - ErrorF ("winProcQueryTree - winClipboardInit " > - "failed.\n"); > - return iReturn; > - } > - > - ErrorF ("winProcQueryTree - winInitClipboard returned.\n"); > - } > - > - /* Flag that clipboard client has been launched */ > - g_fClipboardLaunched = TRUE; > - > - return iReturn; > -} > - > - > -/* > * Wrapper for internal EstablishConnection function. > * Initializes internal clients that must not be started until > * an external client has connected. > @@ -217,18 +118,6 @@ winProcEstablishConnection (ClientPtr cl > /* Increment call count */ > ++s_iCallCount; > > - /* Wait for CLIP_NUM_CALLS when Xdmcp is enabled */ > - if (g_fXdmcpEnabled > - && !g_fClipboardLaunched > - && s_iCallCount < CLIP_NUM_CALLS) > - { > - if (s_iCallCount == 1) ErrorF ("winProcEstablishConnection - Xdmcp, waiting to " > - "start clipboard client until %dth call", CLIP_NUM_CALLS); > - if (s_iCallCount == CLIP_NUM_CALLS - 1) ErrorF (".\n"); > - else ErrorF ("."); > - return (*winProcEstablishConnectionOrig) (client); > - } > - > /* > * This procedure is only used for initialization. > * We can unwrap the original procedure at this point > @@ -279,13 +168,6 @@ winProcEstablishConnection (ClientPtr cl > * be XDM, could be another client) connects, which makes it > * almost certain that the clipboard client will not connect > * until after XDM when using XDMCP. > - * 8) Unfortunately, there is another problem. > - * 9) XDM walks the list of windows with XQueryTree, > - * killing any client it finds with a window. > - * 10)Thus, when using XDMCP we wait until CLIP_NUM_CALLS > - * to ProcEstablishCeonnection before we startup the clipboard > - * client. This should prevent XDM from finding the clipboard > - * client, since it has not yet created a window. > */ > > /* Create the clipboard client thread */ > @@ -442,7 +324,8 @@ winProcSetSelectionOwner (ClientPtr clie > > /* Release ownership of the Windows clipboard */ > OpenClipboard (NULL); > - EmptyClipboard (); > + /* on clipboard restart EmptyClipboard (); makes the X server to freeze for 1 or 2 seconds and I don't know why */ > + /* EmptyClipboard (); */ > CloseClipboard (); > > goto winProcSetSelectionOwner_Done; -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From jjreisert@alum.mit.edu Tue Sep 28 21:28:00 2010 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Tue, 28 Sep 2010 21:28:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4CA24C35.8010001@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> <4CA24C35.8010001@dronecode.org.uk> Message-ID: On Tue, Sep 28, 2010 at 2:12 PM, Jon TURNEY wrote: > You will find attached to this Email a patch (for the git version) > which implements for the clipboard thread : Hi Jon, Can I assume that when you announce a patched version of XWin.exe for testing, that the test version includes all of the prior patches, up to and including the one being tested? Thanks - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From donaldfagan@gmail.com Tue Sep 28 23:51:00 2010 From: donaldfagan@gmail.com (Donald Fagan) Date: Tue, 28 Sep 2010 23:51:00 -0000 Subject: Commercial Use In-Reply-To: References: Message-ID: Hi, I can't seem to find on your site if cygwin-x can be used commercially. If it can is there any cost for a licence. I intend to used it as a possible replacement for reflection x to access an old HP-UX server. Thanks, Donald -- 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/ From mark@maxrnd.com Wed Sep 29 02:36:00 2010 From: mark@maxrnd.com (Mark Geisert) Date: Wed, 29 Sep 2010 02:36:00 -0000 Subject: Commercial Use References: Message-ID: Donald Fagan writes: > Hi, > > I can't seem to find on your site if cygwin-x can be used > commercially. If it can is there any cost for a licence. > I intend to used it as a possible replacement for reflection x to > access an old HP-UX server. Have a look at . Basically, any kind of use is OK, it's further distribution that requires attention to licensing. ..mark -- 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/ From s.severus@hima.com Wed Sep 29 06:28:00 2010 From: s.severus@hima.com (Sven Severus) Date: Wed, 29 Sep 2010 06:28:00 -0000 Subject: selection to clipboard in xterm Message-ID: <4CA2DB7F.4080801@hima.com> Thanks to your Reply, Jim. Yes, I tried SHIFT+INSERT (which I know from XEmacs) to paste, but I never get pasted into a windows application what I highlighted in my xterm earlier on. Nevertheless, from one xterm to another xterm this works fine... One additional remark: When I highlight a piece of text in my xterm, the content of the windows clipboard does not remain unaffected: it is cleared (reset to the empty string). Even harder for me to understand ;-> ... Greetings, Sven Jim Reisert wrote: >Have you tried SHIFT+INSERT to paste text into those windows? -- Mit freundlichen Gr????en Dipl. Inform. Sven Severus Softwareentwicklung ---------------------------------------------------------- HIMA Paul Hildebrandt GmbH + CO KG Abt: Entwicklung Software Albert-Bassermann-Strasse 28 68782 Bruehl Germany Tel: +49 6202 709-289 Fax: +49 6202 709-299 E-Mail: s.severus@hima.com Internet: www.hima.de -- 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/ From hummel.michel@gmail.com Wed Sep 29 08:59:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Wed, 29 Sep 2010 08:59:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: <4CA24C35.8010001@dronecode.org.uk> References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> <4CA24C35.8010001@dronecode.org.uk> Message-ID: Thank you for your comments, I really want to help you on this part of the X server. I will now do : 1/ Adapt the patch to be cygwin Xorg compatible 1/ Split the patch into two separate patches 2/ Publish as soon as possible a new patches version which will take into account your comments : *a) WM_DESTROYCLIPBOARD message (Could you be a little more precise concerning this, I'm not sure to realy understand the issue *b) Adding a rate-limit on "clipboard_generation" with a static variable for example ? and a restart delay (500 Milliseconds should be enough isn't it ?) *c) Change the comment about ProcEstablishConnection wrapper and inInitClipboard *d) Merge the cleanup and the restart function into one *e) Concerning the use of pthread_cleanup_pop at winClipboardProc end, do you mean : Replace all pthread_exit() call's by a goto error_exit label which will call pthread_cleanup_pop(1) (The parameter "1" means that we have to execute it) *f) Delete the unnecessary whitespace changes *g) Concerning the winClipboardErrorHandler tricks, This is for the situation you said : "Window has been deleted by someone else, but we are still connected to the server" I will add a comment in the sources Michel Hummel 2010/9/28 Jon TURNEY : > On 24/09/2010 09:15, Michel Hummel wrote: >> >> Hi Jon, > > Firstly, thanks very much for looking at this. > >> You will find attached to this Email a patch (for the git version) >> which implements for the clipboard thread : >> ?- Auto cleanup function >> ?- Auto restart function for unexpected exit of the clipboard or >> Xerror detection >> ?- Deletion of XQuery wrapper ?(not needed anymore) >> ?- Deletion of all the xdmcp related tricks ?(not needed anymore) > > For purposes of review it would be easier to split this patch into two > separate patches, (i) the clipboard thread changes and (ii) removing the > unneeded xdmcp tricks. > >> One thing, this patch deletes the call to EmptyClipboard () in the >> winProcSetSelectionOwner function of the winclipboardwrappers.c file >> when an "owned to not owned transition" has been detected. I don't >> know why but it was freezing the server for 1 or 2 seconds during >> clipboard's restart in xdmcp connection. > > Hmmm... I wonder if that's something to do with how we process the > WM_DESTROYCLIPBOARD message? ?In any case, this should not be happening. > >> It would be fine if you could tell me, when you think this patch and >> the previous one ( which makes the reset of the server working >> correctly with clipboard) will be included to the official X server? > > We don't have a regular release cycle for the cygwin X server, so I can't > answer that question accurately. > > I shall put your previous patch into the next release and assuming it works > well, be pushing it upstream sometime before xserver 1.10 > > I think this patch needs a little more work. > > I'm still a little concerned that there is no rate-limiting on the clipboard > restart mechanism, so in a pathological case (e.g. where some unanticipated > error causes the clipboard to constantly get disconnected), this will spin > using all available CPU. > > Some detailed comments below. > >> --- >> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/InitInput.c >> ? ? ?2010-08-18 22:10:54.000000000 +0200 >> +++ hw/xwin/InitInput.c 2010-09-17 17:03:08.611244200 +0200 >> @@ -127,12 +127,6 @@ InitInput (int argc, char *argv[]) >> ? ? ? winProcEstablishConnectionOrig = InitialVector[2]; >> ? ? ? InitialVector[2] = winProcEstablishConnection; >> ? ? } >> - ?if (g_fXdmcpEnabled >> - ? ? ?&& ProcVector[X_QueryTree] != winProcQueryTree) >> - ? ?{ >> - ? ? ?winProcQueryTreeOrig = ProcVector[X_QueryTree]; >> - ? ? ?ProcVector[X_QueryTree] = winProcQueryTree; >> - ? ?} >> ?#endif >> >> ? g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE); >> --- >> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin//winclipboardthread.c >> ? ?2010-08-18 22:10:54.000000000 +0200 >> +++ hw/xwin/winclipboardthread.c ? ? ? ?2010-09-24 16:48:20.689125100 >> +0200 >> @@ -48,6 +48,8 @@ >> ?extern Bool ? ? ? ? ? ?g_fUnicodeClipboard; >> ?extern unsigned long ? serverGeneration; >> ?extern Bool ? ? ? ? ? ?g_fClipboardStarted; >> +extern Bool ? ? ? ? ? ? g_fClipboardLaunched; >> +extern Bool ? ? ? ? ? ? g_fClipboard; >> ?extern HWND ? ? ? ? ? ?g_hwndClipboard; >> ?extern void ? ? ? ? ? ?*g_pClipboardDisplay; >> ?extern Window ? ? ? ? ?g_iClipboardWindow; >> @@ -72,8 +74,113 @@ winClipboardErrorHandler (Display *pDisp >> ?static int >> ?winClipboardIOErrorHandler (Display *pDisplay); >> >> +static void >> +restartClipboardThread(void *pvNotUsed); >> + >> +static void >> +winClipboardCleanup(void *vfdMessageQueue); >> + >> >> ?/* >> + * restartClipboardThread activate the ProcEstablishConnection wrapper >> which will start >> + * the thread after next client connection >> + */ > > This comment doesn't appear to be correct. ?winInitClipboard() starts the > thread itself. > > It looks like this could fight with the ProcEstablishConnection wrapper, > which will call winInitClipboard() once for each server generation. > >> + >> +static void restartClipboardThread(void *pvNotUsed) >> +{ >> + ?winDebug("restartClipboardThread - enter \n"); >> + ?if (g_fClipboard) >> + ? ?{ >> + ? ? ?ErrorF("restartClipboardThread - trying to restart clipboard thread >> \n"); >> + ? ? ?/* Create the clipboard client thread */ >> + ? ? ?if (!winInitClipboard ()) >> + ? ? ? ?{ >> + ? ? ? ? ?ErrorF ("restartClipboardThread - winClipboardInit " >> + ? ? ? ? ? ? ? ? ?"failed.\n"); >> + ? ? ? ? ?return; >> + ? ? ? ?} >> + >> + ? ? ?winDebug ("restartClipboardThread - winInitClipboard returned.\n"); >> + ? ? ?/* Flag that clipboard client has been launched */ >> + ? ? ?g_fClipboardLaunched = TRUE; >> + ? ?} >> + ?else >> + ? ?{ >> + ? ? ?ErrorF ("restartClipboardThread - Clipboard disabled ?- Exit from >> server \n"); >> + ? ? ?return; >> + ? ?} >> + ?return; >> +} >> + >> +/* >> + * winClipboardCleanup clean thread before exit >> + */ >> + >> +static void winClipboardCleanup(void *vfdMessageQueue) >> +{ >> + ?int iReturn; >> + ?int fdMessageQueue = (int) vfdMessageQueue; >> + >> + ?winDebug("winClipboardCleanup - Enter \n"); >> + ?CloseClipboard(); >> + ?/* Close our Windows window */ >> + ?if (g_hwndClipboard ) >> + ? ?{ >> + ? ? ?/* Destroy the Window window (hwnd) */ >> + ? ? ?winDebug("winClipboardCleanup - Destroy Windows window\n"); >> + ? ? ?PostMessage (g_hwndClipboard,WM_DESTROY, 0, 0); >> + ? ? ?winClipboardFlushWindowsMessageQueue(g_hwndClipboard); >> + ? ?} >> + >> + ?/* Close our X window */ >> + ?if (g_pClipboardDisplay && g_iClipboardWindow) >> + ? ?{ >> + ? ? ?iReturn = XDestroyWindow (g_pClipboardDisplay, g_iClipboardWindow); >> + ? ? ?if (iReturn == BadWindow) >> + ? ? ? ErrorF ("winClipboardCleanup - XDestroyWindow returned >> BadWindow.\n"); >> + ? ? ?else >> + ? ? ? winDebug ("winClipboardCleanup - winClipboardProc - XDestroyWindow >> succeeded.\n"); >> + ? ?} >> + >> + >> +#ifdef HAS_DEVWINDOWS >> + ?/* Close our Win32 message handle */ >> + ?if (fdMessageQueue) >> + ? ?close (fdMessageQueue); >> +#endif >> + >> +#if 0 >> + ?/* >> + ? * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. ?The >> + ? * XSync and XSelectInput calls did not help. >> + ? */ >> + >> + ?/* Discard any remaining events */ >> + ?XSync (g_pClipboardDisplay, TRUE); >> + >> + ?/* Select event types to watch */ >> + ?XSelectInput (g_pClipboardDisplay, >> + ? ? ? ? ? ? ? DefaultRootWindow (g_pClipboardDisplay), >> + ? ? ? ? ? ? ? None); >> + >> + ?/* Close our X display */ >> + ?if (g_pClipboardDisplay) >> + ? ?{ >> + ? ? ?XCloseDisplay (g_pClipboardDisplay); >> + ? ?} >> +#endif >> + >> + ?/* global clipboard variable reset */ >> + ?g_fClipboardLaunched = FALSE; >> + ?g_fClipboardStarted = FALSE; >> + ?g_iClipboardWindow = None; >> + ?g_hwndClipboard = NULL; >> + ?g_fUnicodeClipboard = FALSE; >> + ?g_pClipboardDisplay = NULL; >> + ?winDebug("winClipboardCleanup - Exit \n"); >> + >> +} > > Rather than 2 separate functions which we pthread_cleanup_push separately, > but never use independently, can these be combined? ?Or create a cleanup fn > which calls both of them, and push that? > >> +/* >> ?* Main thread function >> ?*/ >> >> @@ -84,9 +191,8 @@ winClipboardProc (void *pvNotUsed) >> ? int ? ? ? ? ? ? ? ? ?iReturn; >> ? HWND ? ? ? ? ? ? ? ? hwnd = NULL; >> ? int ? ? ? ? ? ? ? ? ?iConnectionNumber = 0; >> -#ifdef HAS_DEVWINDOWS >> ? int ? ? ? ? ? ? ? ? ?fdMessageQueue = 0; >> -#else >> +#ifndef HAS_DEVWINDOWS >> ? struct timeval ? ? ? ?tvTimeout; >> ?#endif >> ? fd_set ? ? ? ? ? ? ? fdsRead; >> @@ -122,24 +228,6 @@ winClipboardProc (void *pvNotUsed) >> ? ? ? ErrorF ("winClipboardProc - Warning: Locale not supported by X.\n"); >> ? ? } >> >> - ?/* Set jump point for Error exits */ >> - ?iReturn = setjmp (g_jmpEntry); >> - >> - ?/* Check if we should continue operations */ >> - ?if (iReturn != WIN_JMP_ERROR_IO >> - ? ? ?&& iReturn != WIN_JMP_OKAY) >> - ? ?{ >> - ? ? ?/* setjmp returned an unknown value, exit */ >> - ? ? ?ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", >> - ? ? ? ? ? ? iReturn); >> - ? ? ?pthread_exit (NULL); >> - ? ?} >> - ?else if (iReturn == WIN_JMP_ERROR_IO) >> - ? ?{ >> - ? ? ?/* TODO: Cleanup the Win32 window and free any allocated memory */ >> - ? ? ?ErrorF ("winClipboardProc - setjmp returned for IO Error >> Handler.\n"); >> - ? ? ?pthread_exit (NULL); >> - ? ?} >> >> ? /* Use our generated cookie for authentication */ >> ? winSetAuthorization(); >> @@ -216,6 +304,25 @@ winClipboardProc (void *pvNotUsed) >> ? iMaxDescriptor = iConnectionNumber + 1; >> ?#endif >> >> + ?/* Adding a cleanup process for thread exit >> + ? * Warning : A call to pthread_cleanup_push() implies a call to >> pthread_cleanup_pop() at the same code level (function) >> + ? * We also use it to automaticaly restart the thread on unexpected exit >> (ie. pthread_exit() when g_pClipboard != TRUE ) >> + ? * this is a LIFO stack ( Last In First Out ) so adding "restart" then >> "clean" >> + ? */ >> + ?/* Install the restart function ?to be called */ >> + ?pthread_cleanup_push(restartClipboardThread, ?NULL); >> + ?/* ?install the cleanup function to be called at thread exit */ >> + ?pthread_cleanup_push(winClipboardCleanup, (void*) &fdMessageQueue); >> + ?/* The only way to exit from this loop is to : >> + ? * 1/ Exit before the installation this cleanup process >> + ? * 2/ Doing the "expected" Exit (ie. End of the function) which disable >> the restart >> + ? * ? ?by setting g_pClipboard to FALSE; >> + ? * ? ?before calling the cleanup handler : >> + ? * ?pthread_cleanup_pop(1); >> + ? * ? ?then the restart handler which will be an Exit handler because >> g_pClipboard != TRUE : >> + ? * ?pthread_cleanup_pop(1); >> + ? */ >> + >> ? /* Create atoms */ >> ? atomClipboard = XInternAtom (pDisplay, "CLIPBOARD", False); >> ? atomClipboardManager = XInternAtom (pDisplay, "CLIPBOARD_MANAGER", >> False); >> @@ -292,6 +399,26 @@ winClipboardProc (void *pvNotUsed) >> ? /* Signal that the clipboard client has started */ >> ? g_fClipboardStarted = TRUE; >> >> + >> + ?/* Set jump point for Error exits */ >> + ?iReturn = setjmp (g_jmpEntry); >> + >> + ?/* Check if we should continue operations */ >> + ?if (iReturn != WIN_JMP_ERROR_IO >> + ? ? ?&& iReturn != WIN_JMP_OKAY) >> + ? ?{ >> + ? ? ?/* setjmp returned an unknown value, exit */ >> + ? ? ?ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", >> + ? ? ? ? ? ? iReturn); >> + ? ? ?pthread_exit (NULL); >> + ? ?} >> + ?else if (iReturn == WIN_JMP_ERROR_IO) >> + ? ?{ >> + ? ? ?/* TODO: Cleanup the Win32 window and free any allocated memory */ >> + ? ? ?ErrorF ("winClipboardProc - setjmp returned for IO Error >> Handler.\n"); >> + ? ? ?pthread_exit (NULL); >> + ? ?} >> + >> ? /* Loop for X events */ >> ? while (1) >> ? ? { >> @@ -377,47 +504,10 @@ winClipboardProc (void *pvNotUsed) >> ? ? ? ?} >> ? ? } >> >> - ?/* Close our X window */ >> - ?if (pDisplay && iWindow) >> - ? ?{ >> - ? ? ?iReturn = XDestroyWindow (pDisplay, iWindow); >> - ? ? ?if (iReturn == BadWindow) >> - ? ? ? ErrorF ("winClipboardProc - XDestroyWindow returned >> BadWindow.\n"); >> - ? ? ?else >> - ? ? ? ErrorF ("winClipboardProc - XDestroyWindow succeeded.\n"); >> - ? ?} >> - >> - >> -#ifdef HAS_DEVWINDOWS >> - ?/* Close our Win32 message handle */ >> - ?if (fdMessageQueue) >> - ? ?close (fdMessageQueue); >> -#endif >> - >> -#if 0 >> - ?/* >> - ? * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. ?The >> - ? * XSync and XSelectInput calls did not help. >> - ? */ >> - >> - ?/* Discard any remaining events */ >> - ?XSync (pDisplay, TRUE); >> - >> - ?/* Select event types to watch */ >> - ?XSelectInput (pDisplay, >> - ? ? ? ? ? ? ? DefaultRootWindow (pDisplay), >> - ? ? ? ? ? ? ? None); >> - >> - ?/* Close our X display */ >> - ?if (pDisplay) >> - ? ?{ >> - ? ? ?XCloseDisplay (pDisplay); >> - ? ?} >> -#endif >> - >> - ?g_iClipboardWindow = None; >> - ?g_pClipboardDisplay = NULL; >> - ?g_hwndClipboard = NULL; >> + ?/* disable the clipboard means thread restart function will kill the >> server */ >> + ?g_fClipboard = FALSE; >> + ?pthread_cleanup_pop(1); >> + ?pthread_cleanup_pop(1); > > The use of pthread_cleanup really obscures what's going on here. ?It would > be clearer just to have a label error_exit: here and goto it from the > various places which pthread_exit... > >> >> ? return NULL; >> ?} >> @@ -431,7 +521,7 @@ static int >> ?winClipboardErrorHandler (Display *pDisplay, XErrorEvent *pErr) >> ?{ >> ? char pszErrorMsg[100]; >> - >> + > > No unnecessary whitespace changes, please. > >> ? XGetErrorText (pDisplay, >> ? ? ? ? ? ? ? ? pErr->error_code, >> ? ? ? ? ? ? ? ? pszErrorMsg, >> @@ -442,6 +532,13 @@ winClipboardErrorHandler (Display *pDisp >> ? ? ? ? ?pErr->serial, >> ? ? ? ? ?pErr->request_code, >> ? ? ? ? ?pErr->minor_code); >> + >> + ?/* If the Xerror is BadWindow Error, restart the thread */ >> + ?if ( pErr->request_code == 24 ) >> + ? { >> + ? ? ErrorF("winClipboardErrorHandler - Badwindow detected, restarting >> clipboard thread\n"); >> + ? ? pthread_exit(NULL); >> + ? } > > How do we get into this situation? ?Window has been deleted by someone else, > but we are still connected to the server? > >> ? return 0; >> ?} >> >> --- >> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/winclipboardwrappers.c >> ? 2010-08-18 22:10:54.000000000 +0200 >> +++ hw/xwin/winclipboardwrappers.c ? ? ?2010-09-22 10:06:00.232451900 >> +0200 >> @@ -53,7 +53,6 @@ >> ?*/ >> >> ?DISPATCH_PROC(winProcEstablishConnection); >> -DISPATCH_PROC(winProcQueryTree); >> ?DISPATCH_PROC(winProcSetSelectionOwner); >> >> >> @@ -79,104 +78,6 @@ extern winDispatchProcPtr ? winProcSetSele >> >> >> ?/* >> - * Wrapper for internal QueryTree function. >> - * Hides the clipboard client when it is the only client remaining. >> - */ >> - >> -int >> -winProcQueryTree (ClientPtr client) >> -{ >> - ?int ? ? ? ? ? ? ? ? ?iReturn; >> - >> - ?ErrorF ("winProcQueryTree - Hello\n"); >> - >> - ?/* >> - ? * This procedure is only used for initialization. >> - ? * We can unwrap the original procedure at this point >> - ? * so that this function is no longer called until the >> - ? * server resets and the function is wrapped again. >> - ? */ >> - ?ProcVector[X_QueryTree] = winProcQueryTreeOrig; >> - >> - ?/* >> - ? * Call original function and bail if it fails. >> - ? * NOTE: We must do this first, since we need XdmcpOpenDisplay >> - ? * to be called before we initialize our clipboard client. >> - ? */ >> - ?iReturn = (*winProcQueryTreeOrig) (client); >> - ?if (iReturn != 0) >> - ? ?{ >> - ? ? ?ErrorF ("winProcQueryTree - ProcQueryTree failed, bailing.\n"); >> - ? ? ?return iReturn; >> - ? ?} >> - >> - ?/* Make errors more obvious */ >> - ?winProcQueryTreeOrig = NULL; >> - >> - ?/* Do nothing if clipboard is not enabled */ >> - ?if (!g_fClipboard) >> - ? ?{ >> - ? ? ?ErrorF ("winProcQueryTree - Clipboard is not enabled, " >> - ? ? ? ? ? ? "returning.\n"); >> - ? ? ?return iReturn; >> - ? ?} >> - >> - ?/* If the clipboard client has already been started, abort */ >> - ?if (g_fClipboardLaunched) >> - ? ?{ >> - ? ? ?ErrorF ("winProcQueryTree - Clipboard client already " >> - ? ? ? ? ? ? "launched, returning.\n"); >> - ? ? ?return iReturn; >> - ? ?} >> - >> - ?/* Startup the clipboard client if clipboard mode is being used */ >> - ?if (g_fXdmcpEnabled && g_fClipboard) >> - ? ?{ >> - ? ? ?/* >> - ? ? ? * NOTE: The clipboard client is started here for a reason: >> - ? ? ? * 1) Assume you are using XDMCP (e.g. XWin -query %hostname%) >> - ? ? ? * 2) If the clipboard client attaches during X Server startup, >> - ? ? ? * ? ?then it becomes the "magic client" that causes the X Server >> - ? ? ? * ? ?to reset if it exits. >> - ? ? ? * 3) XDMCP calls KillAllClients when it starts up. >> - ? ? ? * 4) The clipboard client is a client, so it is killed. >> - ? ? ? * 5) The clipboard client is the "magic client", so the X Server >> - ? ? ? * ? ?resets itself. >> - ? ? ? * 6) This repeats ad infinitum. >> - ? ? ? * 7) We avoid this by waiting until at least one client (could >> - ? ? ? * ? ?be XDM, could be another client) connects, which makes it >> - ? ? ? * ? ?almost certain that the clipboard client will not connect >> - ? ? ? * ? ?until after XDM when using XDMCP. >> - ? ? ? * 8) Unfortunately, there is another problem. >> - ? ? ? * 9) XDM walks the list of windows with XQueryTree, >> - ? ? ? * ? ?killing any client it finds with a window. >> - ? ? ? * 10)Thus, when using XDMCP we wait until the first call >> - ? ? ? * ? ?to ProcQueryTree before we startup the clipboard client. >> - ? ? ? * ? ?This should prevent XDM from finding the clipboard client, >> - ? ? ? * ? ?since it has not yet created a window. >> - ? ? ? * 11)Startup when not using XDMCP is handled in >> - ? ? ? * ? ?winProcEstablishConnection. >> - ? ? ? */ >> - >> - ? ? ?/* Create the clipboard client thread */ >> - ? ? ?if (!winInitClipboard ()) >> - ? ? ? { >> - ? ? ? ? ErrorF ("winProcQueryTree - winClipboardInit " >> - ? ? ? ? ? ? ? ? "failed.\n"); >> - ? ? ? ? return iReturn; >> - ? ? ? } >> - >> - ? ? ?ErrorF ("winProcQueryTree - winInitClipboard returned.\n"); >> - ? ?} >> - >> - ?/* Flag that clipboard client has been launched */ >> - ?g_fClipboardLaunched = TRUE; >> - >> - ?return iReturn; >> -} >> - >> - >> -/* >> ?* Wrapper for internal EstablishConnection function. >> ?* Initializes internal clients that must not be started until >> ?* an external client has connected. >> @@ -217,18 +118,6 @@ winProcEstablishConnection (ClientPtr cl >> ? /* Increment call count */ >> ? ++s_iCallCount; >> >> - ?/* Wait for CLIP_NUM_CALLS when Xdmcp is enabled */ >> - ?if (g_fXdmcpEnabled >> - ? ? ?&& !g_fClipboardLaunched >> - ? ? ?&& s_iCallCount < CLIP_NUM_CALLS) >> - ? ?{ >> - ? ? ?if (s_iCallCount == 1) ErrorF ("winProcEstablishConnection - Xdmcp, >> waiting to " >> - ? ? ? ? ? ? "start clipboard client until %dth call", CLIP_NUM_CALLS); >> - ? ? ?if (s_iCallCount == CLIP_NUM_CALLS - 1) ErrorF (".\n"); >> - ? ? ?else ErrorF ("."); >> - ? ? ?return (*winProcEstablishConnectionOrig) (client); >> - ? ?} >> - >> ? /* >> ? ?* This procedure is only used for initialization. >> ? ?* We can unwrap the original procedure at this point >> @@ -279,13 +168,6 @@ winProcEstablishConnection (ClientPtr cl >> ? ? ? ?* ? ?be XDM, could be another client) connects, which makes it >> ? ? ? ?* ? ?almost certain that the clipboard client will not connect >> ? ? ? ?* ? ?until after XDM when using XDMCP. >> - ? ? ? * 8) Unfortunately, there is another problem. >> - ? ? ? * 9) XDM walks the list of windows with XQueryTree, >> - ? ? ? * ? ?killing any client it finds with a window. >> - ? ? ? * 10)Thus, when using XDMCP we wait until CLIP_NUM_CALLS >> - ? ? ? * ? ?to ProcEstablishCeonnection before we startup the clipboard >> - ? ? ? * ? ?client. ?This should prevent XDM from finding the clipboard >> - ? ? ? * ? ?client, since it has not yet created a window. >> ? ? ? ?*/ >> >> ? ? ? /* Create the clipboard client thread */ >> @@ -442,7 +324,8 @@ winProcSetSelectionOwner (ClientPtr clie >> >> ? ? ? /* Release ownership of the Windows clipboard */ >> ? ? ? OpenClipboard (NULL); >> - ? ? ?EmptyClipboard (); >> + ? ? ?/* on clipboard restart ?EmptyClipboard (); makes the X server to >> freeze ?for 1 or 2 seconds and I don't know why */ >> + ? ? ?/* EmptyClipboard (); */ >> ? ? ? CloseClipboard (); >> >> ? ? ? goto winProcSetSelectionOwner_Done; > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From frederic.bron@m4x.org Wed Sep 29 10:36:00 2010 From: frederic.bron@m4x.org (=?ISO-8859-1?Q?Fr=E9d=E9ric_Bron?=) Date: Wed, 29 Sep 2010 10:36:00 -0000 Subject: No scrollbar with MSC Mentat Message-ID: I am using cygwin 1.7.7 to get connectted to a local server (x86_64) running RHE5: $ ssh -X myserver (same issue with -Y) Then I launch a finite-element pre-processor called MSC Mentat: $ mentat2007r1& With this piece of software, the scrollbars are displayed for a very tiny time (0.1 seconds maybe) and disappear. When using the X server of the server (using vncserver for example and a vncviewer), the scrollbars appear normally. Cygwin 1.5 did the same. Regards, Fr?d?ric Bron -- 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/ From hummel.michel@gmail.com Wed Sep 29 14:05:00 2010 From: hummel.michel@gmail.com (Michel Hummel) Date: Wed, 29 Sep 2010 14:05:00 -0000 Subject: XWin crash after the launch of startkde on a remote Red Hat 5 machine In-Reply-To: References: <4C5EADBB.5000009@dronecode.org.uk> <4C950885.5080205@gmail.com> <4C9768C1.2050508@dronecode.org.uk> <4C9A12F9.7050704@dronecode.org.uk> <4CA24C35.8010001@dronecode.org.uk> Message-ID: You will find attached to this Email the modifications you asked. The X server doesn't freeze anymore when clipboard restarts on xdmcp, certainly fixed by the cygwin patches. I added a rate-limit of clipboard_generation which disables restart after XWIN_CLIPBOARD_RETRIES retries (defined to 40 in winclipboard.h) and a sleep(XWIN_CLIPBOARD_DELAY) before retries (defined to 1 in winclipboard.h) I hope you will like this new version, Thank you Michel Hummel 2010/9/29 Michel Hummel : > Thank you for your comments, I really want to help you on this part of > the X server. > ?I will now do : > 1/ Adapt the patch to be cygwin Xorg compatible > 1/ Split the patch into two separate patches > 2/ Publish as soon as possible a new patches version which will take > into account your comments : > *a) WM_DESTROYCLIPBOARD message (Could you be a little more precise > concerning this, I'm not sure to realy understand the issue > *b) Adding a rate-limit on "clipboard_generation" with a static > variable for example ? and a restart delay (500 Milliseconds should be > enough isn't it ?) > *c) Change the comment about ProcEstablishConnection wrapper and inInitClipboard > *d) Merge the cleanup and the restart function into one > *e) Concerning the use of pthread_cleanup_pop at winClipboardProc end, > do you mean : Replace all pthread_exit() call's by a goto error_exit > label which will call pthread_cleanup_pop(1) (The parameter "1" means > that we have to execute it) > *f) Delete the unnecessary whitespace changes > *g) Concerning the winClipboardErrorHandler tricks, This is for the > situation you said : "Window has been deleted by someone else, but we > are still connected to the server" I will add a comment in the sources > > Michel Hummel > > > 2010/9/28 Jon TURNEY : >> On 24/09/2010 09:15, Michel Hummel wrote: >>> >>> Hi Jon, >> >> Firstly, thanks very much for looking at this. >> >>> You will find attached to this Email a patch (for the git version) >>> which implements for the clipboard thread : >>> ?- Auto cleanup function >>> ?- Auto restart function for unexpected exit of the clipboard or >>> Xerror detection >>> ?- Deletion of XQuery wrapper ?(not needed anymore) >>> ?- Deletion of all the xdmcp related tricks ?(not needed anymore) >> >> For purposes of review it would be easier to split this patch into two >> separate patches, (i) the clipboard thread changes and (ii) removing the >> unneeded xdmcp tricks. >> >>> One thing, this patch deletes the call to EmptyClipboard () in the >>> winProcSetSelectionOwner function of the winclipboardwrappers.c file >>> when an "owned to not owned transition" has been detected. I don't >>> know why but it was freezing the server for 1 or 2 seconds during >>> clipboard's restart in xdmcp connection. >> >> Hmmm... I wonder if that's something to do with how we process the >> WM_DESTROYCLIPBOARD message? ?In any case, this should not be happening. >> >>> It would be fine if you could tell me, when you think this patch and >>> the previous one ( which makes the reset of the server working >>> correctly with clipboard) will be included to the official X server? >> >> We don't have a regular release cycle for the cygwin X server, so I can't >> answer that question accurately. >> >> I shall put your previous patch into the next release and assuming it works >> well, be pushing it upstream sometime before xserver 1.10 >> >> I think this patch needs a little more work. >> >> I'm still a little concerned that there is no rate-limiting on the clipboard >> restart mechanism, so in a pathological case (e.g. where some unanticipated >> error causes the clipboard to constantly get disconnected), this will spin >> using all available CPU. >> >> Some detailed comments below. >> >>> --- >>> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/InitInput.c >>> ? ? ?2010-08-18 22:10:54.000000000 +0200 >>> +++ hw/xwin/InitInput.c 2010-09-17 17:03:08.611244200 +0200 >>> @@ -127,12 +127,6 @@ InitInput (int argc, char *argv[]) >>> ? ? ? winProcEstablishConnectionOrig = InitialVector[2]; >>> ? ? ? InitialVector[2] = winProcEstablishConnection; >>> ? ? } >>> - ?if (g_fXdmcpEnabled >>> - ? ? ?&& ProcVector[X_QueryTree] != winProcQueryTree) >>> - ? ?{ >>> - ? ? ?winProcQueryTreeOrig = ProcVector[X_QueryTree]; >>> - ? ? ?ProcVector[X_QueryTree] = winProcQueryTree; >>> - ? ?} >>> ?#endif >>> >>> ? g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE); >>> --- >>> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin//winclipboardthread.c >>> ? ?2010-08-18 22:10:54.000000000 +0200 >>> +++ hw/xwin/winclipboardthread.c ? ? ? ?2010-09-24 16:48:20.689125100 >>> +0200 >>> @@ -48,6 +48,8 @@ >>> ?extern Bool ? ? ? ? ? ?g_fUnicodeClipboard; >>> ?extern unsigned long ? serverGeneration; >>> ?extern Bool ? ? ? ? ? ?g_fClipboardStarted; >>> +extern Bool ? ? ? ? ? ? g_fClipboardLaunched; >>> +extern Bool ? ? ? ? ? ? g_fClipboard; >>> ?extern HWND ? ? ? ? ? ?g_hwndClipboard; >>> ?extern void ? ? ? ? ? ?*g_pClipboardDisplay; >>> ?extern Window ? ? ? ? ?g_iClipboardWindow; >>> @@ -72,8 +74,113 @@ winClipboardErrorHandler (Display *pDisp >>> ?static int >>> ?winClipboardIOErrorHandler (Display *pDisplay); >>> >>> +static void >>> +restartClipboardThread(void *pvNotUsed); >>> + >>> +static void >>> +winClipboardCleanup(void *vfdMessageQueue); >>> + >>> >>> ?/* >>> + * restartClipboardThread activate the ProcEstablishConnection wrapper >>> which will start >>> + * the thread after next client connection >>> + */ >> >> This comment doesn't appear to be correct. ?winInitClipboard() starts the >> thread itself. >> >> It looks like this could fight with the ProcEstablishConnection wrapper, >> which will call winInitClipboard() once for each server generation. >> >>> + >>> +static void restartClipboardThread(void *pvNotUsed) >>> +{ >>> + ?winDebug("restartClipboardThread - enter \n"); >>> + ?if (g_fClipboard) >>> + ? ?{ >>> + ? ? ?ErrorF("restartClipboardThread - trying to restart clipboard thread >>> \n"); >>> + ? ? ?/* Create the clipboard client thread */ >>> + ? ? ?if (!winInitClipboard ()) >>> + ? ? ? ?{ >>> + ? ? ? ? ?ErrorF ("restartClipboardThread - winClipboardInit " >>> + ? ? ? ? ? ? ? ? ?"failed.\n"); >>> + ? ? ? ? ?return; >>> + ? ? ? ?} >>> + >>> + ? ? ?winDebug ("restartClipboardThread - winInitClipboard returned.\n"); >>> + ? ? ?/* Flag that clipboard client has been launched */ >>> + ? ? ?g_fClipboardLaunched = TRUE; >>> + ? ?} >>> + ?else >>> + ? ?{ >>> + ? ? ?ErrorF ("restartClipboardThread - Clipboard disabled ?- Exit from >>> server \n"); >>> + ? ? ?return; >>> + ? ?} >>> + ?return; >>> +} >>> + >>> +/* >>> + * winClipboardCleanup clean thread before exit >>> + */ >>> + >>> +static void winClipboardCleanup(void *vfdMessageQueue) >>> +{ >>> + ?int iReturn; >>> + ?int fdMessageQueue = (int) vfdMessageQueue; >>> + >>> + ?winDebug("winClipboardCleanup - Enter \n"); >>> + ?CloseClipboard(); >>> + ?/* Close our Windows window */ >>> + ?if (g_hwndClipboard ) >>> + ? ?{ >>> + ? ? ?/* Destroy the Window window (hwnd) */ >>> + ? ? ?winDebug("winClipboardCleanup - Destroy Windows window\n"); >>> + ? ? ?PostMessage (g_hwndClipboard,WM_DESTROY, 0, 0); >>> + ? ? ?winClipboardFlushWindowsMessageQueue(g_hwndClipboard); >>> + ? ?} >>> + >>> + ?/* Close our X window */ >>> + ?if (g_pClipboardDisplay && g_iClipboardWindow) >>> + ? ?{ >>> + ? ? ?iReturn = XDestroyWindow (g_pClipboardDisplay, g_iClipboardWindow); >>> + ? ? ?if (iReturn == BadWindow) >>> + ? ? ? ErrorF ("winClipboardCleanup - XDestroyWindow returned >>> BadWindow.\n"); >>> + ? ? ?else >>> + ? ? ? winDebug ("winClipboardCleanup - winClipboardProc - XDestroyWindow >>> succeeded.\n"); >>> + ? ?} >>> + >>> + >>> +#ifdef HAS_DEVWINDOWS >>> + ?/* Close our Win32 message handle */ >>> + ?if (fdMessageQueue) >>> + ? ?close (fdMessageQueue); >>> +#endif >>> + >>> +#if 0 >>> + ?/* >>> + ? * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. ?The >>> + ? * XSync and XSelectInput calls did not help. >>> + ? */ >>> + >>> + ?/* Discard any remaining events */ >>> + ?XSync (g_pClipboardDisplay, TRUE); >>> + >>> + ?/* Select event types to watch */ >>> + ?XSelectInput (g_pClipboardDisplay, >>> + ? ? ? ? ? ? ? DefaultRootWindow (g_pClipboardDisplay), >>> + ? ? ? ? ? ? ? None); >>> + >>> + ?/* Close our X display */ >>> + ?if (g_pClipboardDisplay) >>> + ? ?{ >>> + ? ? ?XCloseDisplay (g_pClipboardDisplay); >>> + ? ?} >>> +#endif >>> + >>> + ?/* global clipboard variable reset */ >>> + ?g_fClipboardLaunched = FALSE; >>> + ?g_fClipboardStarted = FALSE; >>> + ?g_iClipboardWindow = None; >>> + ?g_hwndClipboard = NULL; >>> + ?g_fUnicodeClipboard = FALSE; >>> + ?g_pClipboardDisplay = NULL; >>> + ?winDebug("winClipboardCleanup - Exit \n"); >>> + >>> +} >> >> Rather than 2 separate functions which we pthread_cleanup_push separately, >> but never use independently, can these be combined? ?Or create a cleanup fn >> which calls both of them, and push that? >> >>> +/* >>> ?* Main thread function >>> ?*/ >>> >>> @@ -84,9 +191,8 @@ winClipboardProc (void *pvNotUsed) >>> ? int ? ? ? ? ? ? ? ? ?iReturn; >>> ? HWND ? ? ? ? ? ? ? ? hwnd = NULL; >>> ? int ? ? ? ? ? ? ? ? ?iConnectionNumber = 0; >>> -#ifdef HAS_DEVWINDOWS >>> ? int ? ? ? ? ? ? ? ? ?fdMessageQueue = 0; >>> -#else >>> +#ifndef HAS_DEVWINDOWS >>> ? struct timeval ? ? ? ?tvTimeout; >>> ?#endif >>> ? fd_set ? ? ? ? ? ? ? fdsRead; >>> @@ -122,24 +228,6 @@ winClipboardProc (void *pvNotUsed) >>> ? ? ? ErrorF ("winClipboardProc - Warning: Locale not supported by X.\n"); >>> ? ? } >>> >>> - ?/* Set jump point for Error exits */ >>> - ?iReturn = setjmp (g_jmpEntry); >>> - >>> - ?/* Check if we should continue operations */ >>> - ?if (iReturn != WIN_JMP_ERROR_IO >>> - ? ? ?&& iReturn != WIN_JMP_OKAY) >>> - ? ?{ >>> - ? ? ?/* setjmp returned an unknown value, exit */ >>> - ? ? ?ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", >>> - ? ? ? ? ? ? iReturn); >>> - ? ? ?pthread_exit (NULL); >>> - ? ?} >>> - ?else if (iReturn == WIN_JMP_ERROR_IO) >>> - ? ?{ >>> - ? ? ?/* TODO: Cleanup the Win32 window and free any allocated memory */ >>> - ? ? ?ErrorF ("winClipboardProc - setjmp returned for IO Error >>> Handler.\n"); >>> - ? ? ?pthread_exit (NULL); >>> - ? ?} >>> >>> ? /* Use our generated cookie for authentication */ >>> ? winSetAuthorization(); >>> @@ -216,6 +304,25 @@ winClipboardProc (void *pvNotUsed) >>> ? iMaxDescriptor = iConnectionNumber + 1; >>> ?#endif >>> >>> + ?/* Adding a cleanup process for thread exit >>> + ? * Warning : A call to pthread_cleanup_push() implies a call to >>> pthread_cleanup_pop() at the same code level (function) >>> + ? * We also use it to automaticaly restart the thread on unexpected exit >>> (ie. pthread_exit() when g_pClipboard != TRUE ) >>> + ? * this is a LIFO stack ( Last In First Out ) so adding "restart" then >>> "clean" >>> + ? */ >>> + ?/* Install the restart function ?to be called */ >>> + ?pthread_cleanup_push(restartClipboardThread, ?NULL); >>> + ?/* ?install the cleanup function to be called at thread exit */ >>> + ?pthread_cleanup_push(winClipboardCleanup, (void*) &fdMessageQueue); >>> + ?/* The only way to exit from this loop is to : >>> + ? * 1/ Exit before the installation this cleanup process >>> + ? * 2/ Doing the "expected" Exit (ie. End of the function) which disable >>> the restart >>> + ? * ? ?by setting g_pClipboard to FALSE; >>> + ? * ? ?before calling the cleanup handler : >>> + ? * ?pthread_cleanup_pop(1); >>> + ? * ? ?then the restart handler which will be an Exit handler because >>> g_pClipboard != TRUE : >>> + ? * ?pthread_cleanup_pop(1); >>> + ? */ >>> + >>> ? /* Create atoms */ >>> ? atomClipboard = XInternAtom (pDisplay, "CLIPBOARD", False); >>> ? atomClipboardManager = XInternAtom (pDisplay, "CLIPBOARD_MANAGER", >>> False); >>> @@ -292,6 +399,26 @@ winClipboardProc (void *pvNotUsed) >>> ? /* Signal that the clipboard client has started */ >>> ? g_fClipboardStarted = TRUE; >>> >>> + >>> + ?/* Set jump point for Error exits */ >>> + ?iReturn = setjmp (g_jmpEntry); >>> + >>> + ?/* Check if we should continue operations */ >>> + ?if (iReturn != WIN_JMP_ERROR_IO >>> + ? ? ?&& iReturn != WIN_JMP_OKAY) >>> + ? ?{ >>> + ? ? ?/* setjmp returned an unknown value, exit */ >>> + ? ? ?ErrorF ("winClipboardProc - setjmp returned: %d exiting\n", >>> + ? ? ? ? ? ? iReturn); >>> + ? ? ?pthread_exit (NULL); >>> + ? ?} >>> + ?else if (iReturn == WIN_JMP_ERROR_IO) >>> + ? ?{ >>> + ? ? ?/* TODO: Cleanup the Win32 window and free any allocated memory */ >>> + ? ? ?ErrorF ("winClipboardProc - setjmp returned for IO Error >>> Handler.\n"); >>> + ? ? ?pthread_exit (NULL); >>> + ? ?} >>> + >>> ? /* Loop for X events */ >>> ? while (1) >>> ? ? { >>> @@ -377,47 +504,10 @@ winClipboardProc (void *pvNotUsed) >>> ? ? ? ?} >>> ? ? } >>> >>> - ?/* Close our X window */ >>> - ?if (pDisplay && iWindow) >>> - ? ?{ >>> - ? ? ?iReturn = XDestroyWindow (pDisplay, iWindow); >>> - ? ? ?if (iReturn == BadWindow) >>> - ? ? ? ErrorF ("winClipboardProc - XDestroyWindow returned >>> BadWindow.\n"); >>> - ? ? ?else >>> - ? ? ? ErrorF ("winClipboardProc - XDestroyWindow succeeded.\n"); >>> - ? ?} >>> - >>> - >>> -#ifdef HAS_DEVWINDOWS >>> - ?/* Close our Win32 message handle */ >>> - ?if (fdMessageQueue) >>> - ? ?close (fdMessageQueue); >>> -#endif >>> - >>> -#if 0 >>> - ?/* >>> - ? * FIXME: XCloseDisplay hangs if we call it, as of 2004/03/26. ?The >>> - ? * XSync and XSelectInput calls did not help. >>> - ? */ >>> - >>> - ?/* Discard any remaining events */ >>> - ?XSync (pDisplay, TRUE); >>> - >>> - ?/* Select event types to watch */ >>> - ?XSelectInput (pDisplay, >>> - ? ? ? ? ? ? ? DefaultRootWindow (pDisplay), >>> - ? ? ? ? ? ? ? None); >>> - >>> - ?/* Close our X display */ >>> - ?if (pDisplay) >>> - ? ?{ >>> - ? ? ?XCloseDisplay (pDisplay); >>> - ? ?} >>> -#endif >>> - >>> - ?g_iClipboardWindow = None; >>> - ?g_pClipboardDisplay = NULL; >>> - ?g_hwndClipboard = NULL; >>> + ?/* disable the clipboard means thread restart function will kill the >>> server */ >>> + ?g_fClipboard = FALSE; >>> + ?pthread_cleanup_pop(1); >>> + ?pthread_cleanup_pop(1); >> >> The use of pthread_cleanup really obscures what's going on here. ?It would >> be clearer just to have a label error_exit: here and goto it from the >> various places which pthread_exit... >> >>> >>> ? return NULL; >>> ?} >>> @@ -431,7 +521,7 @@ static int >>> ?winClipboardErrorHandler (Display *pDisplay, XErrorEvent *pErr) >>> ?{ >>> ? char pszErrorMsg[100]; >>> - >>> + >> >> No unnecessary whitespace changes, please. >> >>> ? XGetErrorText (pDisplay, >>> ? ? ? ? ? ? ? ? pErr->error_code, >>> ? ? ? ? ? ? ? ? pszErrorMsg, >>> @@ -442,6 +532,13 @@ winClipboardErrorHandler (Display *pDisp >>> ? ? ? ? ?pErr->serial, >>> ? ? ? ? ?pErr->request_code, >>> ? ? ? ? ?pErr->minor_code); >>> + >>> + ?/* If the Xerror is BadWindow Error, restart the thread */ >>> + ?if ( pErr->request_code == 24 ) >>> + ? { >>> + ? ? ErrorF("winClipboardErrorHandler - Badwindow detected, restarting >>> clipboard thread\n"); >>> + ? ? pthread_exit(NULL); >>> + ? } >> >> How do we get into this situation? ?Window has been deleted by someone else, >> but we are still connected to the server? >> >>> ? return 0; >>> ?} >>> >>> --- >>> /home/hummelm/xserver-fc091936e2bddbbab9c9a501edc5a5f08388617e-org/hw/xwin/winclipboardwrappers.c >>> ? 2010-08-18 22:10:54.000000000 +0200 >>> +++ hw/xwin/winclipboardwrappers.c ? ? ?2010-09-22 10:06:00.232451900 >>> +0200 >>> @@ -53,7 +53,6 @@ >>> ?*/ >>> >>> ?DISPATCH_PROC(winProcEstablishConnection); >>> -DISPATCH_PROC(winProcQueryTree); >>> ?DISPATCH_PROC(winProcSetSelectionOwner); >>> >>> >>> @@ -79,104 +78,6 @@ extern winDispatchProcPtr ? winProcSetSele >>> >>> >>> ?/* >>> - * Wrapper for internal QueryTree function. >>> - * Hides the clipboard client when it is the only client remaining. >>> - */ >>> - >>> -int >>> -winProcQueryTree (ClientPtr client) >>> -{ >>> - ?int ? ? ? ? ? ? ? ? ?iReturn; >>> - >>> - ?ErrorF ("winProcQueryTree - Hello\n"); >>> - >>> - ?/* >>> - ? * This procedure is only used for initialization. >>> - ? * We can unwrap the original procedure at this point >>> - ? * so that this function is no longer called until the >>> - ? * server resets and the function is wrapped again. >>> - ? */ >>> - ?ProcVector[X_QueryTree] = winProcQueryTreeOrig; >>> - >>> - ?/* >>> - ? * Call original function and bail if it fails. >>> - ? * NOTE: We must do this first, since we need XdmcpOpenDisplay >>> - ? * to be called before we initialize our clipboard client. >>> - ? */ >>> - ?iReturn = (*winProcQueryTreeOrig) (client); >>> - ?if (iReturn != 0) >>> - ? ?{ >>> - ? ? ?ErrorF ("winProcQueryTree - ProcQueryTree failed, bailing.\n"); >>> - ? ? ?return iReturn; >>> - ? ?} >>> - >>> - ?/* Make errors more obvious */ >>> - ?winProcQueryTreeOrig = NULL; >>> - >>> - ?/* Do nothing if clipboard is not enabled */ >>> - ?if (!g_fClipboard) >>> - ? ?{ >>> - ? ? ?ErrorF ("winProcQueryTree - Clipboard is not enabled, " >>> - ? ? ? ? ? ? "returning.\n"); >>> - ? ? ?return iReturn; >>> - ? ?} >>> - >>> - ?/* If the clipboard client has already been started, abort */ >>> - ?if (g_fClipboardLaunched) >>> - ? ?{ >>> - ? ? ?ErrorF ("winProcQueryTree - Clipboard client already " >>> - ? ? ? ? ? ? "launched, returning.\n"); >>> - ? ? ?return iReturn; >>> - ? ?} >>> - >>> - ?/* Startup the clipboard client if clipboard mode is being used */ >>> - ?if (g_fXdmcpEnabled && g_fClipboard) >>> - ? ?{ >>> - ? ? ?/* >>> - ? ? ? * NOTE: The clipboard client is started here for a reason: >>> - ? ? ? * 1) Assume you are using XDMCP (e.g. XWin -query %hostname%) >>> - ? ? ? * 2) If the clipboard client attaches during X Server startup, >>> - ? ? ? * ? ?then it becomes the "magic client" that causes the X Server >>> - ? ? ? * ? ?to reset if it exits. >>> - ? ? ? * 3) XDMCP calls KillAllClients when it starts up. >>> - ? ? ? * 4) The clipboard client is a client, so it is killed. >>> - ? ? ? * 5) The clipboard client is the "magic client", so the X Server >>> - ? ? ? * ? ?resets itself. >>> - ? ? ? * 6) This repeats ad infinitum. >>> - ? ? ? * 7) We avoid this by waiting until at least one client (could >>> - ? ? ? * ? ?be XDM, could be another client) connects, which makes it >>> - ? ? ? * ? ?almost certain that the clipboard client will not connect >>> - ? ? ? * ? ?until after XDM when using XDMCP. >>> - ? ? ? * 8) Unfortunately, there is another problem. >>> - ? ? ? * 9) XDM walks the list of windows with XQueryTree, >>> - ? ? ? * ? ?killing any client it finds with a window. >>> - ? ? ? * 10)Thus, when using XDMCP we wait until the first call >>> - ? ? ? * ? ?to ProcQueryTree before we startup the clipboard client. >>> - ? ? ? * ? ?This should prevent XDM from finding the clipboard client, >>> - ? ? ? * ? ?since it has not yet created a window. >>> - ? ? ? * 11)Startup when not using XDMCP is handled in >>> - ? ? ? * ? ?winProcEstablishConnection. >>> - ? ? ? */ >>> - >>> - ? ? ?/* Create the clipboard client thread */ >>> - ? ? ?if (!winInitClipboard ()) >>> - ? ? ? { >>> - ? ? ? ? ErrorF ("winProcQueryTree - winClipboardInit " >>> - ? ? ? ? ? ? ? ? "failed.\n"); >>> - ? ? ? ? return iReturn; >>> - ? ? ? } >>> - >>> - ? ? ?ErrorF ("winProcQueryTree - winInitClipboard returned.\n"); >>> - ? ?} >>> - >>> - ?/* Flag that clipboard client has been launched */ >>> - ?g_fClipboardLaunched = TRUE; >>> - >>> - ?return iReturn; >>> -} >>> - >>> - >>> -/* >>> ?* Wrapper for internal EstablishConnection function. >>> ?* Initializes internal clients that must not be started until >>> ?* an external client has connected. >>> @@ -217,18 +118,6 @@ winProcEstablishConnection (ClientPtr cl >>> ? /* Increment call count */ >>> ? ++s_iCallCount; >>> >>> - ?/* Wait for CLIP_NUM_CALLS when Xdmcp is enabled */ >>> - ?if (g_fXdmcpEnabled >>> - ? ? ?&& !g_fClipboardLaunched >>> - ? ? ?&& s_iCallCount < CLIP_NUM_CALLS) >>> - ? ?{ >>> - ? ? ?if (s_iCallCount == 1) ErrorF ("winProcEstablishConnection - Xdmcp, >>> waiting to " >>> - ? ? ? ? ? ? "start clipboard client until %dth call", CLIP_NUM_CALLS); >>> - ? ? ?if (s_iCallCount == CLIP_NUM_CALLS - 1) ErrorF (".\n"); >>> - ? ? ?else ErrorF ("."); >>> - ? ? ?return (*winProcEstablishConnectionOrig) (client); >>> - ? ?} >>> - >>> ? /* >>> ? ?* This procedure is only used for initialization. >>> ? ?* We can unwrap the original procedure at this point >>> @@ -279,13 +168,6 @@ winProcEstablishConnection (ClientPtr cl >>> ? ? ? ?* ? ?be XDM, could be another client) connects, which makes it >>> ? ? ? ?* ? ?almost certain that the clipboard client will not connect >>> ? ? ? ?* ? ?until after XDM when using XDMCP. >>> - ? ? ? * 8) Unfortunately, there is another problem. >>> - ? ? ? * 9) XDM walks the list of windows with XQueryTree, >>> - ? ? ? * ? ?killing any client it finds with a window. >>> - ? ? ? * 10)Thus, when using XDMCP we wait until CLIP_NUM_CALLS >>> - ? ? ? * ? ?to ProcEstablishCeonnection before we startup the clipboard >>> - ? ? ? * ? ?client. ?This should prevent XDM from finding the clipboard >>> - ? ? ? * ? ?client, since it has not yet created a window. >>> ? ? ? ?*/ >>> >>> ? ? ? /* Create the clipboard client thread */ >>> @@ -442,7 +324,8 @@ winProcSetSelectionOwner (ClientPtr clie >>> >>> ? ? ? /* Release ownership of the Windows clipboard */ >>> ? ? ? OpenClipboard (NULL); >>> - ? ? ?EmptyClipboard (); >>> + ? ? ?/* on clipboard restart ?EmptyClipboard (); makes the X server to >>> freeze ?for 1 or 2 seconds and I don't know why */ >>> + ? ? ?/* EmptyClipboard (); */ >>> ? ? ? CloseClipboard (); >>> >>> ? ? ? goto winProcSetSelectionOwner_Done; >> >> -- >> Jon TURNEY >> Volunteer Cygwin/X X Server maintainer >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin_patch_restart_clipboard1.9.patch Type: application/octet-stream Size: 9246 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: XWin_patch_remove_xdmcp_tricks1.9.patch Type: application/octet-stream Size: 6250 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From kevin-dated-1293298850.62e27e@omegacrash.net Wed Sep 29 16:49:00 2010 From: kevin-dated-1293298850.62e27e@omegacrash.net (Kevin Goodsell) Date: Wed, 29 Sep 2010 16:49:00 -0000 Subject: XWin crashes with DirectX apps Message-ID: <4CA36DFD.4050309@omegacrash.net> I am seeing a 100% reproducible crash in XWin from xorg-server-1.8.2-1. I first saw it when I ran a full-screen DirectX game while the server was running, but I'm also able to reproduce it with the dxdiag tool. Here are the steps: 1) Start the X server. The exact method of starting it hasn't had any affect on my testing. Starting either with the installed Start menu shortcut or just running XWin.exe without arguments produces the same results. 2) In Start -> Run..., enter dxdiag to run the DirectX Diagnostic tool. 3) In dxdiag, select the Display tab. 4) Click the button labeled "Test Direct3D" (the button labeled "Test DirectDraw" also triggers the crash, but takes longer). XWin crashes when the first full-screen test begins. I rebuilt the X server with debugging enabled and got the following backtrace: $ gdb hw/xwin/XWin.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe [New thread 3084.0xc20] [New thread 3084.0xda8] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 3084.0xa68] [New thread 3084.0xd38] Program received signal SIGSEGV, Segmentation fault. 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 560 IDirectDrawSurface4_SetClipper (pScreenPriv->pddsPrimary4, (gdb) bt #0 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d0, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 #2 0x0041a369 in winWindowProc (hwnd=0x1c023c, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #4 0x001c023c in ?? () #5 0x0000007e in ?? () #6 0x00000010 in ?? () #7 0x01e00280 in ?? () #8 0x00419bcc in winReshapeRootless () #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #10 0x00419bcc in winReshapeRootless () #11 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #12 0x00000000 in ?? () (gdb) p pScreenPriv->pddsPrimary4 $1 = (LPDIRECTDRAWSURFACE4) 0x0 (gdb) Using the option -engine 2 also crashes, but produces a slightly different backtrace: (gdb) run -engine 2 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe -engine 2 [New thread 2208.0x904] [New thread 2208.0x664] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 2208.0x350] [New thread 2208.0x39c] Program received signal SIGSEGV, Segmentation fault. 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 528 IDirectDrawSurface2_SetClipper (pScreenPriv->pddsPrimary, (gdb) bt #0 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d8, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 #2 0x0041a369 in winWindowProc (hwnd=0x6b00f2, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #4 0x006b00f2 in ?? () #5 0x0000007e in ?? () #6 0x00000010 in ?? () #7 0x01e00280 in ?? () #8 0x00419bcc in winReshapeRootless () #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #10 0x00419bcc in winReshapeRootless () #11 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #12 0x00000000 in ?? () (gdb) p pScreenPriv->pddsPrimary $2 = (LPDIRECTDRAWSURFACE2) 0x0 (gdb) It looks like these are both the result of some bad code copied and pasted in winshaddd.c and winshadddnl.c. From winshadddnl.c, in winFreeFBShadowDDNL: /* Detach the clipper from the primary surface and release the clipper. */ if (pScreenPriv->pddcPrimary) { /* Detach the clipper */ IDirectDrawSurface4_SetClipper (pScreenPriv->pddsPrimary4, NULL); /* Release the clipper object */ IDirectDrawClipper_Release (pScreenPriv->pddcPrimary); pScreenPriv->pddcPrimary = NULL; } /* Release the primary surface, if there is one */ if (pScreenPriv->pddsPrimary4) { IDirectDrawSurface4_Release (pScreenPriv->pddsPrimary4); ... The call to IDirectDrawSurface4_SetClipper appears to be passed a pointer that may be invalid (as suggested by the same variable being explicitly checked before being used a few lines later). Printing the value of the pointer confirms it is null at the time of the crash. Unfortunately, this is only the first problem. I patched the code to check the validity of the pointer before this call, and the crash simply moved to another section of the code. Here's the next backtrace, after patching (and adding a debug build of pixman): $ gdb ./hw/xwin/XWin.exe GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe [New thread 2200.0x430] [New thread 2200.0x758] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 2200.0xfb0] [New thread 2200.0xbbc] Program received signal SIGSEGV, Segmentation fault. 0x6fc4d664 in pixman_fill_sse2 (bits=0x7f8c0008, stride=6376, bpp=32, x=0, y=0, width=640, height=479, data=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:4025 4025 *(uint32_t *)d = data; (gdb) bt #0 0x6fc4d664 in pixman_fill_sse2 (bits=0x7f8c0008, stride=6376, bpp=32, x=0, y=0, width=640, height=479, data=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:4025 #1 0x6fc651c5 in sse2_fill (imp=0x10087730, bits=0x7f8c0008, stride=1594, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:5888 #2 0x6fb57724 in _pixman_implementation_fill (imp=0x10087730, bits=0x7f8c0008, stride=1594, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-implementation.c:225 #3 0x6fb7cab5 in pixman_fill (bits=0x7f8c0008, stride=1594, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman.c:864 #4 0x004492c7 in fbFill (pDrawable=0x10087b38, pGC=0x10086ac0, x=0, y=0, width=640, height=480) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfill.c:48 #5 0x004474eb in fbPolyFillRect (pDrawable=0x10087b38, pGC=0x10086ac0, nrect=0, prect=0x10291860) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfillrect.c:77 #6 0x0052730b in damagePolyFillRect (pDrawable=0x10087b38, pGC=0x10086ac0, nRects=1, pRects=0x10291858) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/miext/damage/damage.c:1404 #7 0x005b1f44 in miPaintWindow (pWin=0x10087b38, prgn=0x10291838, what=0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:673 #8 0x005b1a5c in miWindowExposures (pWin=0x10087b38, prgn=0x10291838, other_exposed=0x0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:504 #9 0x005b76fd in miHandleValidateExposures (pWin=0x10087b38) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miwindow.c:246 #10 0x0042f874 in xf86SetRootClip (pScreen=0x1008c1b8, enable=1) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:164 #11 0x0042f9a9 in winDoRandRScreenSetSize (pScreen=0x1008c1b8, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:212 #12 0x0041a375 in winWindowProc (hwnd=0x370184, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #13 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #14 0x00370184 in ?? () #15 0x0000007e in ?? () #16 0x00000010 in ?? () #17 0x01e00280 in ?? () #18 0x00419bd8 in winReshapeRootless () #19 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #20 0x00419bd8 in winReshapeRootless () #21 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #22 0x00000000 in ?? () (gdb) p d $1 = (uint8_t *) 0x7f8c0008
(gdb) The backtrace is similar for the patched version using -engine 2 (Shadow DirectDraw locking). At this point, I should mention yet another case: -engine 1 (Shadow GDI) has also been crashing all along with a backtrace that is somewhat similar to the ones seen with the patched DirectDraw engines. Here's that backtrace: (gdb) run -engine 1 The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe -engine 1 [New thread 2920.0xb04] [New thread 2920.0xce4] warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at 76d31000 [New thread 2920.0xf40] [New thread 2920.0x654] Program received signal SIGSEGV, Segmentation fault. 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b90000, stride=1280, bpp=32, x=0, y=0, width=640, height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 699 *__P = __B; (gdb) bt #0 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b90000, stride=1280, bpp=32, x=0, y=0, width=640, height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 #1 0x6fc651c5 in sse2_fill (imp=0x10087b78, bits=0x2b90000, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:5888 #2 0x6fb57724 in _pixman_implementation_fill (imp=0x10087b78, bits=0x2b90000, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-implementation.c:225 #3 0x6fb7cab5 in pixman_fill (bits=0x2b90000, stride=320, bpp=32, x=0, y=0, width=640, height=480, xor=0) at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman.c:864 #4 0x004492c7 in fbFill (pDrawable=0x10087f80, pGC=0x10086f80, x=0, y=0, width=640, height=480) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfill.c:48 #5 0x004474eb in fbPolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, nrect=0, prect=0x1011a8f0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfillrect.c:77 #6 0x0052730b in damagePolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, nRects=1, pRects=0x1011a8e8) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/miext/damage/damage.c:1404 #7 0x005b1f44 in miPaintWindow (pWin=0x10087f80, prgn=0x10291c30, what=0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:673 #8 0x005b1a5c in miWindowExposures (pWin=0x10087f80, prgn=0x10291c30, other_exposed=0x0) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:504 #9 0x005b76fd in miHandleValidateExposures (pWin=0x10087f80) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miwindow.c:246 #10 0x0042f874 in xf86SetRootClip (pScreen=0x1008c1c0, enable=1) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:164 #11 0x0042f9a9 in winDoRandRScreenSetSize (pScreen=0x1008c1c0, width=640, height=480, mmWidth=3435973836, mmHeight=1080233164) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:212 #12 0x0041a375 in winWindowProc (hwnd=0x1b02a0, message=126, wParam=16, lParam=31457920) at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 #13 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #14 0x001b02a0 in ?? () #15 0x0000007e in ?? () #16 0x00000010 in ?? () #17 0x01e00280 in ?? () #18 0x00419bd8 in winReshapeRootless () #19 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll #20 0x00419bd8 in winReshapeRootless () #21 0x7e428ea0 in USER32!DefWindowProcW () from /cygdrive/c/WINDOWS/system32/user32.dll #22 0x00000000 in ?? () (gdb) At this point I'm a bit stuck. It looks like fbFill might be passing an invalid pointer to pixman_fill, but the code is hard to follow due to macros and unfamiliar APIs so I don't know where the root problem is. I may continue to investigate. By the way, another backtrace similar to this one showed up in the mailing list archives from last month: http://cygwin.com/ml/cygwin-xfree/2010-08/msg00068.html -Kevin -- 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/ From jon.turney@dronecode.org.uk Wed Sep 29 17:21:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 29 Sep 2010 17:21:00 -0000 Subject: XWin crashes with DirectX apps In-Reply-To: <4CA36DFD.4050309@omegacrash.net> References: <4CA36DFD.4050309@omegacrash.net> Message-ID: <4CA3759F.7020308@dronecode.org.uk> On 29/09/2010 17:49, Kevin Goodsell wrote: > I am seeing a 100% reproducible crash in XWin from xorg-server-1.8.2-1. > I first saw it when I ran a full-screen DirectX game while the server > was running, but I'm also able to reproduce it with the dxdiag tool. > Here are the steps: > > 1) Start the X server. The exact method of starting it hasn't had any > affect on my testing. Starting either with the installed Start menu > shortcut or just running XWin.exe without arguments produces the same > results. > > 2) In Start -> Run..., enter dxdiag to run the DirectX Diagnostic tool. > > 3) In dxdiag, select the Display tab. > > 4) Click the button labeled "Test Direct3D" (the button labeled "Test > DirectDraw" also triggers the crash, but takes longer). > > XWin crashes when the first full-screen test begins. > > I rebuilt the X server with debugging enabled and got the following > backtrace: Thanks for the detailed problem report. Since I've recently fixed a few crash bugs in this area, introduced with the new -resize functionality, you might like to test the latest snapshot [1] to see if you still have this problem, the source is available at [2]. [1] ftp://cygwin.com/pub/cygwinx/XWin.20100923-git-2172af4d1ea713f1.exe.bz2 [2] http://cgit.freedesktop.org/~jturney/xserver/log/?h=snapshot > $ gdb hw/xwin/XWin.exe > GNU gdb 6.8.0.20080328-cvs (cygwin-special) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) run > Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe > [New thread 3084.0xc20] > [New thread 3084.0xda8] > warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at > 76d31000 > [New thread 3084.0xa68] > [New thread 3084.0xd38] > > Program received signal SIGSEGV, Segmentation fault. > 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 > 560 IDirectDrawSurface4_SetClipper (pScreenPriv->pddsPrimary4, > (gdb) bt > #0 0x00415677 in winFreeFBShadowDDNL (pScreen=0x1008c1d0) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshadddnl.c:560 > #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d0, width=640, > height=480, > mmWidth=3435973836, mmHeight=1080233164) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 > #2 0x0041a369 in winWindowProc (hwnd=0x1c023c, message=126, wParam=16, > lParam=31457920) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 > #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #4 0x001c023c in ?? () > #5 0x0000007e in ?? () > #6 0x00000010 in ?? () > #7 0x01e00280 in ?? () > #8 0x00419bcc in winReshapeRootless () > #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #10 0x00419bcc in winReshapeRootless () > #11 0x7e428ea0 in USER32!DefWindowProcW () from > /cygdrive/c/WINDOWS/system32/user32.dll > #12 0x00000000 in ?? () > (gdb) p pScreenPriv->pddsPrimary4 > $1 = (LPDIRECTDRAWSURFACE4) 0x0 > (gdb) > > Using the option -engine 2 also crashes, but produces a slightly > different backtrace: > > (gdb) run -engine 2 > The program being debugged has been started already. > Start it from the beginning? (y or n) y > > Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe > -engine 2 > [New thread 2208.0x904] > [New thread 2208.0x664] > warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at > 76d31000 > [New thread 2208.0x350] > [New thread 2208.0x39c] > > Program received signal SIGSEGV, Segmentation fault. > 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 > 528 IDirectDrawSurface2_SetClipper (pScreenPriv->pddsPrimary, > (gdb) bt > #0 0x00413586 in winFreeFBShadowDD (pScreen=0x1008c1d8) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winshaddd.c:528 > #1 0x0042f917 in winDoRandRScreenSetSize (pScreen=0x1008c1d8, width=640, > height=480, > mmWidth=3435973836, mmHeight=1080233164) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:191 > #2 0x0041a369 in winWindowProc (hwnd=0x6b00f2, message=126, wParam=16, > lParam=31457920) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 > #3 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #4 0x006b00f2 in ?? () > #5 0x0000007e in ?? () > #6 0x00000010 in ?? () > #7 0x01e00280 in ?? () > #8 0x00419bcc in winReshapeRootless () > #9 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #10 0x00419bcc in winReshapeRootless () > #11 0x7e428ea0 in USER32!DefWindowProcW () from > /cygdrive/c/WINDOWS/system32/user32.dll > #12 0x00000000 in ?? () > (gdb) p pScreenPriv->pddsPrimary > $2 = (LPDIRECTDRAWSURFACE2) 0x0 > (gdb) > > It looks like these are both the result of some bad code copied and > pasted in winshaddd.c and winshadddnl.c. From winshadddnl.c, in > winFreeFBShadowDDNL: > > /* Detach the clipper from the primary surface and release the clipper. */ > if (pScreenPriv->pddcPrimary) > { > /* Detach the clipper */ > IDirectDrawSurface4_SetClipper (pScreenPriv->pddsPrimary4, > NULL); > > /* Release the clipper object */ > IDirectDrawClipper_Release (pScreenPriv->pddcPrimary); > pScreenPriv->pddcPrimary = NULL; > } > > /* Release the primary surface, if there is one */ > if (pScreenPriv->pddsPrimary4) > { > IDirectDrawSurface4_Release (pScreenPriv->pddsPrimary4); > ... > > The call to IDirectDrawSurface4_SetClipper appears to be passed a > pointer that may be invalid (as suggested by the same variable being > explicitly checked before being used a few lines later). Printing the > value of the pointer confirms it is null at the time of the crash. > > Unfortunately, this is only the first problem. I patched the code to > check the validity of the pointer before this call, and the crash simply > moved to another section of the code. Here's the next backtrace, after > patching (and adding a debug build of pixman): > > $ gdb ./hw/xwin/XWin.exe > GNU gdb 6.8.0.20080328-cvs (cygwin-special) > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-cygwin"... > (gdb) run > Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe > [New thread 2200.0x430] > [New thread 2200.0x758] > warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at > 76d31000 > [New thread 2200.0xfb0] > [New thread 2200.0xbbc] > > Program received signal SIGSEGV, Segmentation fault. > 0x6fc4d664 in pixman_fill_sse2 (bits=0x7f8c0008, stride=6376, bpp=32, x=0, > y=0, width=640, > height=479, data=0) at > /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:4025 > 4025 *(uint32_t *)d = data; > (gdb) bt > #0 0x6fc4d664 in pixman_fill_sse2 (bits=0x7f8c0008, stride=6376, bpp=32, x=0, > y=0, width=640, > height=479, data=0) at > /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:4025 > #1 0x6fc651c5 in sse2_fill (imp=0x10087730, bits=0x7f8c0008, stride=1594, > bpp=32, x=0, y=0, > width=640, height=480, xor=0) > at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:5888 > #2 0x6fb57724 in _pixman_implementation_fill (imp=0x10087730, bits=0x7f8c0008, > stride=1594, > bpp=32, x=0, y=0, width=640, height=480, xor=0) > at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-implementation.c:225 > #3 0x6fb7cab5 in pixman_fill (bits=0x7f8c0008, stride=1594, bpp=32, x=0, y=0, > width=640, > height=480, xor=0) at > /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman.c:864 > #4 0x004492c7 in fbFill (pDrawable=0x10087b38, pGC=0x10086ac0, x=0, y=0, > width=640, height=480) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfill.c:48 > #5 0x004474eb in fbPolyFillRect (pDrawable=0x10087b38, pGC=0x10086ac0, > nrect=0, prect=0x10291860) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfillrect.c:77 > #6 0x0052730b in damagePolyFillRect (pDrawable=0x10087b38, pGC=0x10086ac0, > nRects=1, > pRects=0x10291858) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/miext/damage/damage.c:1404 > > #7 0x005b1f44 in miPaintWindow (pWin=0x10087b38, prgn=0x10291838, what=0) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:673 > #8 0x005b1a5c in miWindowExposures (pWin=0x10087b38, prgn=0x10291838, > other_exposed=0x0) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:504 > #9 0x005b76fd in miHandleValidateExposures (pWin=0x10087b38) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miwindow.c:246 > #10 0x0042f874 in xf86SetRootClip (pScreen=0x1008c1b8, enable=1) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:164 > #11 0x0042f9a9 in winDoRandRScreenSetSize (pScreen=0x1008c1b8, width=640, > height=480, > mmWidth=3435973836, mmHeight=1080233164) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:212 > #12 0x0041a375 in winWindowProc (hwnd=0x370184, message=126, wParam=16, > lParam=31457920) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 > #13 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #14 0x00370184 in ?? () > #15 0x0000007e in ?? () > #16 0x00000010 in ?? () > #17 0x01e00280 in ?? () > #18 0x00419bd8 in winReshapeRootless () > #19 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #20 0x00419bd8 in winReshapeRootless () > #21 0x7e428ea0 in USER32!DefWindowProcW () from > /cygdrive/c/WINDOWS/system32/user32.dll > #22 0x00000000 in ?? () > (gdb) p d > $1 = (uint8_t *) 0x7f8c0008
> (gdb) > > The backtrace is similar for the patched version using -engine 2 (Shadow > DirectDraw locking). At this point, I should mention yet another case: > -engine 1 (Shadow GDI) has also been crashing all along with a backtrace > that is somewhat similar to the ones seen with the patched DirectDraw > engines. Here's that backtrace: > > (gdb) run -engine 1 > The program being debugged has been started already. > Start it from the beginning? (y or n) y > > Starting program: /usr/src/xorg-server-1.8.2-1/build/xwin-ddx/hw/xwin/XWin.exe > -engine 1 > [New thread 2920.0xb04] > [New thread 2920.0xce4] > warning: Lowest section in /cygdrive/c/WINDOWS/system32/wmi.dll is .text at > 76d31000 > [New thread 2920.0xf40] > [New thread 2920.0x654] > > Program received signal SIGSEGV, Segmentation fault. > 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b90000, stride=1280, bpp=32, x=0, y=0, > width=640, > height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 > 699 *__P = __B; > (gdb) bt > #0 0x6fc4d707 in pixman_fill_sse2 (bits=0x2b90000, stride=1280, bpp=32, x=0, > y=0, width=640, > height=0, data=0) at /usr/lib/gcc/i686-pc-cygwin/4.3.4/include/emmintrin.h:699 > #1 0x6fc651c5 in sse2_fill (imp=0x10087b78, bits=0x2b90000, stride=320, > bpp=32, x=0, y=0, > width=640, height=480, xor=0) > at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-sse2.c:5888 > #2 0x6fb57724 in _pixman_implementation_fill (imp=0x10087b78, bits=0x2b90000, > stride=320, bpp=32, > x=0, y=0, width=640, height=480, xor=0) > at /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman-implementation.c:225 > #3 0x6fb7cab5 in pixman_fill (bits=0x2b90000, stride=320, bpp=32, x=0, y=0, > width=640, > height=480, xor=0) at > /usr/src/pixman-0.18.2-1/src/pixman-0.18.2/pixman/pixman.c:864 > #4 0x004492c7 in fbFill (pDrawable=0x10087f80, pGC=0x10086f80, x=0, y=0, > width=640, height=480) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfill.c:48 > #5 0x004474eb in fbPolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, > nrect=0, prect=0x1011a8f0) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/fb/fbfillrect.c:77 > #6 0x0052730b in damagePolyFillRect (pDrawable=0x10087f80, pGC=0x10086f80, > nRects=1, > pRects=0x1011a8e8) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/miext/damage/damage.c:1404 > > #7 0x005b1f44 in miPaintWindow (pWin=0x10087f80, prgn=0x10291c30, what=0) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:673 > #8 0x005b1a5c in miWindowExposures (pWin=0x10087f80, prgn=0x10291c30, > other_exposed=0x0) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miexpose.c:504 > #9 0x005b76fd in miHandleValidateExposures (pWin=0x10087f80) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/mi/miwindow.c:246 > #10 0x0042f874 in xf86SetRootClip (pScreen=0x1008c1c0, enable=1) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:164 > #11 0x0042f9a9 in winDoRandRScreenSetSize (pScreen=0x1008c1c0, width=640, > height=480, > mmWidth=3435973836, mmHeight=1080233164) > at /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winrandr.c:212 > #12 0x0041a375 in winWindowProc (hwnd=0x1b02a0, message=126, wParam=16, > lParam=31457920) > at > /usr/src/xorg-server-1.8.2-1/src/xserver-cygwin-1.8.2-1/hw/xwin/winwndproc.c:344 > #13 0x7e418734 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #14 0x001b02a0 in ?? () > #15 0x0000007e in ?? () > #16 0x00000010 in ?? () > #17 0x01e00280 in ?? () > #18 0x00419bd8 in winReshapeRootless () > #19 0x7e418816 in USER32!GetDC () from /cygdrive/c/WINDOWS/system32/user32.dll > #20 0x00419bd8 in winReshapeRootless () > #21 0x7e428ea0 in USER32!DefWindowProcW () from > /cygdrive/c/WINDOWS/system32/user32.dll > #22 0x00000000 in ?? () > (gdb) > > At this point I'm a bit stuck. It looks like fbFill might be passing an > invalid pointer to pixman_fill, but the code is hard to follow due to > macros and unfamiliar APIs so I don't know where the root problem is. I > may continue to investigate. > > By the way, another backtrace similar to this one showed up in the > mailing list archives from last month: > > http://cygwin.com/ml/cygwin-xfree/2010-08/msg00068.html These pixman crashes are possibly the result of trying to draw outside the screen pixmap. -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From roland.cassard@gmail.com Thu Sep 30 14:28:00 2010 From: roland.cassard@gmail.com (rolandc) Date: Thu, 30 Sep 2010 14:28:00 -0000 Subject: "Paste" from clipboard can failed (XWin bug) Message-ID: Hi, >From X application, I select some text. I switch on Windows application and I try to paste the text. I do "Ctrl-V" => nothing happens I do a second "Ctrl-V" => the text is pasted This problem depends on the X application When a "paste" occurs, XWin receives a WM_RENDERFORMAT message : (cf. winClipboardWindowProc()) step 1/ XWin try to get the selection in COMPOUND_TEXT format (cf. winProcessXEventsTimeout() calls XConvertSelection("COMPOUND_TEXT ")) step 2/ If the owner of the selection (the X app) can't handle COMPOUND_TEXT format, XWin try to get the selection in UTF8_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with "event.xselection.property == None", XWin calls XConvertSelection("UTF8_STRING")) step 3/ If the owner of the selection (the X app) can't handle UTF8_STRING format, XWin try to get the selection in XA_STRING format (cf. winClipboardFlushXEvents(), on receive an SelectionNotify event with "event.xselection.property == None", XWin calls XConvertSelection("XA_STRING")) But there is a bug in XWin : XWin calls winProcessXEventsTimeout() only twice. If the X app handles only handles XA_STRING format, the "step 3" is never invoked ! As the result, XWin can't get "paste data" and log the message: "winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY" XWin.log with my comment: ... (receive WM_RENDER_FORMAT message) winClipboardWindowProc - WM_RENDER*FORMAT - Hello. (call XConvertSelection("COMPOUND_TEXT ")) (first call winProcessXEventsTimeout()) winClipboardFlushXEvents - SelectionNotify winClipboardFlushXEvents - SelectionNotify - ATOM: PRIMARY (receive event.xselection.target == atomCompoundText aka COMPOUND_TEXT) (the X app can't handle COMPOUND_TEXT format) winClipboardFlushXEvents - SelectionNotify - Requesting conversion of CompoundText target. (call XConvertSelection("UTF8_STRING") and return) (second call winProcessXEventsTimeout()) winClipboardFlushXEvents - SelectionNotify winClipboardFlushXEvents - SelectionNotify - ATOM: PRIMARY (receive event.xselection.target == atomUTF8String aka UTF8_STRING) (the X app can't handle UTF8_STRING format) winClipboardFlushXEvents - SelectionNotify - Requesting conversion of UTF8 target. (call XConvertSelection("XA_STRING") and return) (XWin can't get paste data, also it logs an error :) (and reset the clipboard => SetClipboardData (CF_UNICODETEXT, NULL);SetClipboardData (CF_TEXT, NULL);) winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY ... Solution 1 : Call a third time the function winProcessXEventsTimeout() (see paste_bug_solution1.patch file attached) but this is not a very elegant solution ... Solution 2 : call winProcessXEventsTimeout() only one time winProcessXEventsTimeout() must process all notification until * time out expired * getting the paste data * error occurred (see paste_bug_solution2.patch file attached) note: the actual timeout is set to 1 second. Greetings, -------------- next part -------------- A non-text attachment was scrubbed... Name: paste_bug_solution1.patch Type: application/octet-stream Size: 709 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: paste_bug_solution2.patch Type: application/octet-stream Size: 1572 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From jon.turney@dronecode.org.uk Thu Sep 30 15:33:00 2010 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 30 Sep 2010 15:33:00 -0000 Subject: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST) Message-ID: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.9.0-1 *** xorg-server-dmx-1.9.0-1 This package contains XWin and the other X.Org X11 servers. This is the first official release of the xserver 1.9 series. It is currently available as a test release, and will be made stable in approximately one week if no major regressions are reported. In addition to the usual upstream fixes and improvements, this contains the following cygwin-specific changes: * fix a drawing crash, which could occur after moving a window in multiwindow mode, caused by incorrect initialization of composite position data * fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) * added Turkish keyboard layout detection * add -displayfd option (experimental), which may be useful in Terminal Server environments, see [1] for a discussion of how and why you might want to use this * various crash fixes for -resize. Also fix -resize from turning itself on in multiwindow mode even when not asked for. -resize will be enabled by default in multiwindow mode after more testing. * enable WGL AIGLX code and -wgl option which has been merged upstream, and various GLX fixes Server-side Hardware Accelerated OpenGL (AIGLX) =============================================== This release adds experimental support for hardware accelerated OpenGL rendering in the X server using the native WGL interface. * You need to provide the command line option '-wgl' to the X server to turn on the use of native Windows OpenGL to implement GLX. If you don't use this option, the server will carry on using software rendering. * The currently shipped cygwin mesa libGL is built in such a way that it does not support indirect rendering (rendering takes place on the server), only client-side rendering. ONLY REMOTE CLIENTS FROM UNIX SYSTEMS WILL WORK CURRENTLY. An updated libGL will be made available at some point in the future. * mesa's libGL prefers to use client-side rendering and transfer the image to the server using xlib. To force the use of GLX, so rendering is indirect (takes place on the server), and thus can be accelerated, you must export the environment variable LIBGL_ALWAYS_INDIRECT with a non-zero value before starting the client application. * If you have set things up successfully, 'glxinfo | grep OpenGL' should return something mentioning your graphics card vendor. If it mentions Mesa, you still have software rendering * As before, only multiwindow/mwextwm modes are supported. Software rendering is always used on screens which do not have 1 native window per X window. Removing this restriction requires a way to tell the native OpenGL to transform/clip to the portion of the native window occupied by the X window in the single native window modes. [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00040.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ From hummel.michel@gmail.com Thu Sep 30 19:03:00 2010 From: hummel.michel@gmail.com (michel hummel) Date: Thu, 30 Sep 2010 19:03:00 -0000 Subject: [ANNOUNCEMENT] Updated: xorg-server-1.9.0-1 (TEST) In-Reply-To: References: Message-ID: <4CA4DF1D.7050802@gmail.com> Hi jon, I was surprised to see in the Changelog of this test release : "* fix a clipboard-related crash which could occur during XDMCP session startup (thanks to Michel Hummel for the patch) " It would be very cool if this version included my patch about xdmcp and clipboard auto-restart but I don't think so, isn't it ? I think this version only includes the patch about : clipboard crash on server reset isn't it ? Thanks for your work, Michel Hummel Le 30/09/2010 17:26, Jon TURNEY a ??crit : > The following packages have been updated in the Cygwin distribution: > > *** xorg-server-1.9.0-1 > *** xorg-server-dmx-1.9.0-1 > > This package contains XWin and the other X.Org X11 servers. > > This is the first official release of the xserver 1.9 series. It is > currently available as a test release, and will be made stable in > approximately one week if no major regressions are reported. > > In addition to the usual upstream fixes and improvements, this > contains the following cygwin-specific changes: > > * fix a drawing crash, which could occur after moving a window in > multiwindow mode, caused by incorrect initialization of composite > position data > * fix a clipboard-related crash which could occur during XDMCP session > startup (thanks to Michel Hummel for the patch) > * added Turkish keyboard layout detection > * add -displayfd option (experimental), which may be useful in > Terminal Server environments, see [1] for a discussion of how and why > you might want to use this > * various crash fixes for -resize. Also fix -resize from turning > itself on in multiwindow mode even when not asked for. -resize will > be enabled by default in multiwindow mode after more testing. > * enable WGL AIGLX code and -wgl option which has been merged > upstream, and various GLX fixes > > Server-side Hardware Accelerated OpenGL (AIGLX) > =============================================== > > This release adds experimental support for hardware accelerated OpenGL > rendering in the X server using the native WGL interface. > > * You need to provide the command line option '-wgl' to the X server > to turn on the use of native Windows OpenGL to implement GLX. If you > don't use this option, the server will carry on using software rendering. > > * The currently shipped cygwin mesa libGL is built in such a way that > it does not support indirect rendering (rendering takes place on the > server), only client-side rendering. ONLY REMOTE CLIENTS FROM UNIX > SYSTEMS WILL WORK CURRENTLY. An updated libGL will be made available > at some point in the future. > > * mesa's libGL prefers to use client-side rendering and transfer the > image to the server using xlib. To force the use of GLX, so rendering > is indirect (takes place on the server), and thus can be accelerated, > you must export the environment variable LIBGL_ALWAYS_INDIRECT with a > non-zero value before starting the client application. > > * If you have set things up successfully, 'glxinfo | grep OpenGL' > should return something mentioning your graphics card vendor. If it > mentions Mesa, you still have software rendering > > * As before, only multiwindow/mwextwm modes are supported. Software > rendering is always used on screens which do not have 1 native window > per X window. Removing this restriction requires a way to tell the > native OpenGL to transform/clip to the portion of the native window > occupied by the X window in the single native window modes. > > [1] http://cygwin.com/ml/cygwin-xfree/2010-09/msg00040.html > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/