New clipboard handling notes (XFree86-xserv-4.3.0-31)
Here are my notes that I put together to convince myself that the new clipboard handling was complete and would not cause infinite loops. Please examine the notes if you are interested in the new code or if you would like to double-check my logic for errors. Please review the steps and post to the list if you think you have found an error. Also, if you find a bug or a crash, look at these steps and try to identify the approximate location of your problem so that we can do a better job of debugging. Harold Copy in X11 === 1) winProcSetSelectionOwner gets called and takes ownership of the Win32 clipboard (OpenClipboard, EmptyClipboard, SetClipboardData (foo, NULL)). 2) Selection is owned by another X11 client (the one that called XSetSelectionOwner). 3) EmptyClipboard() in step #1 files WM_DRAWCLIPBOARD message, which is ignored since hwnd == GetClipboardOwner (). 4) Paste in X11 a) Owning X11 client handles SelectionRequest events. b) Item is pasted within X11 without round-trip to Win32. 5) Paste in Win32 a) WM_RENDERFORMAT fires. b) SelectionRequest is sent, conversion from X11 to Win32 is done. c) SetClipboardData is called, passing converted text. 6) Copy in X11 (different app) a) Goto Step #1. 7) Copy in Win32 a) Clipboard is emptied and owned by the other application. b) WM_DRAWCLIPBOARD fires, XSetSelectionOwner is called, owning the selection for the clipboard integration manager. Copy in Win32 = 1) WM_DRAWCLIPBOARD fires, calls XSetSelectionOwner for itself. 2) winProcSetSelectionOwner gets called, does nothing since clipboard X11 window is the window that is taking ownership. 3) Paste in Win32 a) Clipboard owning Win32 app handles GetClipboardData call. b) Item is pasted without round-trip to X11. 4) Paste in X11 a) Clipboard integration manager receives SelectionRequest. b) GetClipboardData is called, returning Win32 clipboard contents. c) Conversion from Win32 to X11 is done and text is pasted. 5) Copy in X11 a) winProcSetSelectionOwner is called. b) Clipboard integration manager takes ownership of Win32 clipboard. c) WM_DRAWCLIPBOARD fires and is ignored since hwnd == GetClipboardOwner (). 6) Copy in Win32 (different app) a) Goto Step #1.
Re: Fix to stop xwinclip from clobbering remote clipboard
On Tue, 23 Dec 2003, Øyvind Harboe wrote: I'm going out on a limb here, as my experience with xfree86 is extremely limited. Perhaps there is an option to achieve what I'm suggesting here. Did you ever find out of that strange unicode-problem when copying from OpenOffice? The \x023 problem. -- Daniel
Re: Updated: XFree86-xserv-4.3.0-31
Harold == Harold L Hunt writes: Harold 1) General - Everything up to the last three entries describes the Harold new clipboard handling system that does not steal ownership of the X11 Harold selection each time that something is selected; this seems to work Harold fine, but it needs to be tested. Hi Harold You made my day The selection ownership problem really went away. I'm running the X version of XEmacs since half a day now and no problems with selection and copy/paste between X and Windows. Ciao Volker
Re: New clipboard handling notes (XFree86-xserv-4.3.0-31)
On Mon, 5 Jan 2004, Harold L Hunt II wrote: Here are my notes that I put together to convince myself that the new clipboard handling was complete and would not cause infinite loops. Please examine the notes if you are interested in the new code or if you would like to double-check my logic for errors. Please review the steps and post to the list if you think you have found an error. Also, if you find a bug or a crash, look at these steps and try to identify the approximate location of your problem so that we can do a better job of debugging. Harold Copy in X11 === 1) winProcSetSelectionOwner gets called and takes ownership of the Win32 clipboard (OpenClipboard, EmptyClipboard, SetClipboardData (foo, NULL)). 2) Selection is owned by another X11 client (the one that called XSetSelectionOwner). 3) EmptyClipboard() in step #1 files WM_DRAWCLIPBOARD message, which is ignored since hwnd == GetClipboardOwner (). 4) Paste in X11 a) Owning X11 client handles SelectionRequest events. b) Item is pasted within X11 without round-trip to Win32. 5) Paste in Win32 a) WM_RENDERFORMAT fires. b) SelectionRequest is sent, conversion from X11 to Win32 is done. c) SetClipboardData is called, passing converted text. 6) Copy in X11 (different app) a) Goto Step #1. 7) Copy in Win32 a) Clipboard is emptied and owned by the other application. b) WM_DRAWCLIPBOARD fires, XSetSelectionOwner is called, owning the selection for the clipboard integration manager. Copy in Win32 = 1) WM_DRAWCLIPBOARD fires, calls XSetSelectionOwner for itself. 2) winProcSetSelectionOwner gets called, does nothing since clipboard X11 window is the window that is taking ownership. 3) Paste in Win32 a) Clipboard owning Win32 app handles GetClipboardData call. b) Item is pasted without round-trip to X11. 4) Paste in X11 a) Clipboard integration manager receives SelectionRequest. b) GetClipboardData is called, returning Win32 clipboard contents. c) Conversion from Win32 to X11 is done and text is pasted. 5) Copy in X11 a) winProcSetSelectionOwner is called. b) Clipboard integration manager takes ownership of Win32 clipboard. c) WM_DRAWCLIPBOARD fires and is ignored since hwnd == GetClipboardOwner (). 6) Copy in Win32 (different app) a) Goto Step #1. Looks good to me. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
where can I get instruction for installation the xemacs on cgwin threw startx
RE: Updated: XFree86-xserv-4.3.0-31
I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harold L Hunt II Sent: Monday, January 05, 2004 2:09 AM To: cygxannounce Subject: Updated: XFree86-xserv-4.3.0-31 Announcement The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin distribution. Links = Server source, direct link: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0 105.tar.bz2 (131 KiB) xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29 (yes, the file has the wrong name, just live with it) source code: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t o-4.3.0-31.diff (39 KiB) xc/programs/Xserver/Imakefile diff against XFree86 CVS: http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse rver-Imakefile-20040105-0105.diff (1 KiB) Changes === 1) General - Everything up to the last three entries describes the new clipboard handling system that does not steal ownership of the X11 selection each time that something is selected; this seems to work fine, but it needs to be tested. The last three entries describe my nearly complete attempt at generating a MIT-MAGIC-COOKIE-1, adding it to the list of cookies that the X Server recognizes, and using it when the clipboard client tries to connect during an XDMCP connection. This authentication approach should work, but I need a break from trying to figure out which of the function calls has a minor error in its parameters; thus, it does not currently work. However, feel free to examine the source code and let me know if any of my calls to GenerateAuthorization, AddResource, or XauWriteAuth are incorrect. I would really like to get this automatic authorization working as soon as possible. Until then I will mark this release (and all releases based upon it) as 'test'. 2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap the generic function ProcVector[X_SetSelectionOwner] with it. This allows us to get a notification each time the selection (clipboard) owner changes. Call SetClipboardData (foo, NULL) so that the WM_RENDERFORMAT message will be posted when a Win32 app requests the clipboard contents. (Harold L Hunt II, Alexander Gottwald) 3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify - No longer steal ownership of the selection each time it changes in X11. We can do this because we have notification when SetSelectionOwner is called (see above). (Harold L Hunt II) 4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear - Remove handling, it is no longer needed; it used to request the contents of the selection that we lost ownership of. (Harold L Hunt II) 5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY - Add information to be used on each call to a window property. (Harold L Hunt II) 6) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DEST ROY,WM_CHANGECBCHAIN,WM_DRAWCLIPBOARD - Add ourselves to the clipboard viewer chain so that we receive notification when the clipboard contents are changed by a Win32 application. Our normal response to this is to call XSetSelectionOwner, but we specifically do nothing if we currently own the Win32 clipboard. (Harold L Hunt II) 7) winclipboardwndproc.c/winClipboardWindowProc/WM_RENDERFORMAT,W M_RENDERALLFORMATS - Request the contents of the X11 selection. Use XPeekIfEvent to wait until the response is added to our event queue (this could probably lead to a dead-lock of a client exists before responding), then call winClipboardFlushXEvents to handle the SelectionNotify event. UTF8 and CompoundText targets require that we call XConvertSelection from the SelectionNotify event, which will cause another SelectionNotify event to be fired; be careful to check for this and do the XPeekIfEvent/winClipboardFlushXEvents thing again if this is the case (this is untested because I did not see any UTF8 or CompoundText targets that needed conversion). Copy the returned contents to the Win32 clipboard with SetClipboardData (). (Harold L Hunt II) 8) winscrinit.c/winFinishScreenInitFB - Generate a MIT-MAGIC-COOKIE-1 cookie and add it to the server's list of cookies. (Harold L Hunt II) 9) winclipboardthread.c/winClipboardSaveXauthData - Add the generated MIT-MAGIC-COOKIE-1 cookie to the Xauthority file. Beware that this is hard-coded to 127.0.0.1:0 and that the entry is not cleaned up upon exit; this will force the host-based access to be disabled in some cases and could cause problems starting X
RE: Updated: XFree86-xserv-4.3.0-31
On Mon, 5 Jan 2004, Andrew Braverman wrote: I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? Noticed this too. It happend after sever reset. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Updated: XFree86-xserv-4.3.0-31
I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll). Should the installer handle this automatically?
Re: Updated: XFree86-xserv-4.3.0-31
Volker == Volker Zell writes: Volker Hi Harold Volker You made my day The selection ownership problem really went away. Volker I'm running the X version of XEmacs since half a day now and no Volker problems with selection and copy/paste between X and Windows. A couple of hours later it stopped working, now my XWin.log fills up with winProcSetSelectionOwner - OpenClipboard () failed: 0578 winProcSetSelectionOwner - OpenClipboard () failed: 0578 winProcSetSelectionOwner - OpenClipboard () failed: 0578 Ciao Volker
Re: where can I get instruction for installation the xemacs on cgwin threw startx
See o http://cygwin.com/ml/cygwin-apps/2004-01/msg00015.html Ciao Volker
IPC not configured
Hi! I have recently been starting to use cygwin on a Windows 2003 server. The UNIX code has been ported using Interix, windows services for UNIX. This does not come with an X-server. The port has been very straightforward. The single user X applications work A-OK. I am having problems with the multi-user versions which make use of IPC. When I try starting say message queues within cygwin and check with ipcs the system states that the kernel has not been configured for IPC. IPC started via c-shell in Interix are active and X-apps in cygwin start and put a message on to a queue, the other end of the queue is not read and so the app hangs. If anyone could point me to documentation I will be delighted. Thank you in anticipation Darryl
Re: Fix to stop xwinclip from clobbering remote clipboard
Daniel, Hr. Daniel Mikkelsen wrote: On Tue, 23 Dec 2003, Øyvind Harboe wrote: I'm going out on a limb here, as my experience with xfree86 is extremely limited. Perhaps there is an option to achieve what I'm suggesting here. Did you ever find out of that strange unicode-problem when copying from OpenOffice? The \x023 problem. If it was a problem due to the fact that the OpenOffice (X11, right) text got copied to Windows, then back to X11, then that should no longer be a problem in XFree86-xserv-4.3.0-31 since round-tripping has been eliminated. Harold
Re: Updated: XFree86-xserv-4.3.0-31
Volker, Dr. Volker Zell wrote: Harold == Harold L Hunt writes: Harold 1) General - Everything up to the last three entries describes the Harold new clipboard handling system that does not steal ownership of the X11 Harold selection each time that something is selected; this seems to work Harold fine, but it needs to be tested. Hi Harold You made my day The selection ownership problem really went away. I'm running the X version of XEmacs since half a day now and no problems with selection and copy/paste between X and Windows. Great! I was sort of afraid to test it really hard... I didn't want to find out for myself that it had major bugs. :) That is great to hear that it is holding up. Harold
Re: New clipboard handling notes (XFree86-xserv-4.3.0-31)
Alexander, Good, thanks for reviewing the notes. Harold Alexander Gottwald wrote: On Mon, 5 Jan 2004, Harold L Hunt II wrote: Here are my notes that I put together to convince myself that the new clipboard handling was complete and would not cause infinite loops. Please examine the notes if you are interested in the new code or if you would like to double-check my logic for errors. Please review the steps and post to the list if you think you have found an error. Also, if you find a bug or a crash, look at these steps and try to identify the approximate location of your problem so that we can do a better job of debugging. Harold Copy in X11 === 1) winProcSetSelectionOwner gets called and takes ownership of the Win32 clipboard (OpenClipboard, EmptyClipboard, SetClipboardData (foo, NULL)). 2) Selection is owned by another X11 client (the one that called XSetSelectionOwner). 3) EmptyClipboard() in step #1 files WM_DRAWCLIPBOARD message, which is ignored since hwnd == GetClipboardOwner (). 4) Paste in X11 a) Owning X11 client handles SelectionRequest events. b) Item is pasted within X11 without round-trip to Win32. 5) Paste in Win32 a) WM_RENDERFORMAT fires. b) SelectionRequest is sent, conversion from X11 to Win32 is done. c) SetClipboardData is called, passing converted text. 6) Copy in X11 (different app) a) Goto Step #1. 7) Copy in Win32 a) Clipboard is emptied and owned by the other application. b) WM_DRAWCLIPBOARD fires, XSetSelectionOwner is called, owning the selection for the clipboard integration manager. Copy in Win32 = 1) WM_DRAWCLIPBOARD fires, calls XSetSelectionOwner for itself. 2) winProcSetSelectionOwner gets called, does nothing since clipboard X11 window is the window that is taking ownership. 3) Paste in Win32 a) Clipboard owning Win32 app handles GetClipboardData call. b) Item is pasted without round-trip to X11. 4) Paste in X11 a) Clipboard integration manager receives SelectionRequest. b) GetClipboardData is called, returning Win32 clipboard contents. c) Conversion from Win32 to X11 is done and text is pasted. 5) Copy in X11 a) winProcSetSelectionOwner is called. b) Clipboard integration manager takes ownership of Win32 clipboard. c) WM_DRAWCLIPBOARD fires and is ignored since hwnd == GetClipboardOwner (). 6) Copy in Win32 (different app) a) Goto Step #1. Looks good to me. bye ago
Re: Updated: XFree86-xserv-4.3.0-31
Andrew, Yup, this happens when you are using -query and there are no entries in your .Xauthority file. You can alleviate this by running it again after it crashes, since the previous entries are left in the file. This is something that still has to be fixed or worked around and that is why these are 'test' releases. Sorry for not describing this particular failure mode in the announcement. Harold Andrew Braverman wrote: I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harold L Hunt II Sent: Monday, January 05, 2004 2:09 AM To: cygxannounce Subject: Updated: XFree86-xserv-4.3.0-31 Announcement The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin distribution. Links = Server source, direct link: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0 105.tar.bz2 (131 KiB) xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29 (yes, the file has the wrong name, just live with it) source code: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t o-4.3.0-31.diff (39 KiB) xc/programs/Xserver/Imakefile diff against XFree86 CVS: http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse rver-Imakefile-20040105-0105.diff (1 KiB) Changes === 1) General - Everything up to the last three entries describes the new clipboard handling system that does not steal ownership of the X11 selection each time that something is selected; this seems to work fine, but it needs to be tested. The last three entries describe my nearly complete attempt at generating a MIT-MAGIC-COOKIE-1, adding it to the list of cookies that the X Server recognizes, and using it when the clipboard client tries to connect during an XDMCP connection. This authentication approach should work, but I need a break from trying to figure out which of the function calls has a minor error in its parameters; thus, it does not currently work. However, feel free to examine the source code and let me know if any of my calls to GenerateAuthorization, AddResource, or XauWriteAuth are incorrect. I would really like to get this automatic authorization working as soon as possible. Until then I will mark this release (and all releases based upon it) as 'test'. 2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap the generic function ProcVector[X_SetSelectionOwner] with it. This allows us to get a notification each time the selection (clipboard) owner changes. Call SetClipboardData (foo, NULL) so that the WM_RENDERFORMAT message will be posted when a Win32 app requests the clipboard contents. (Harold L Hunt II, Alexander Gottwald) 3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify - No longer steal ownership of the selection each time it changes in X11. We can do this because we have notification when SetSelectionOwner is called (see above). (Harold L Hunt II) 4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear - Remove handling, it is no longer needed; it used to request the contents of the selection that we lost ownership of. (Harold L Hunt II) 5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY - Add information to be used on each call to a window property. (Harold L Hunt II) 6) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DEST ROY,WM_CHANGECBCHAIN,WM_DRAWCLIPBOARD - Add ourselves to the clipboard viewer chain so that we receive notification when the clipboard contents are changed by a Win32 application. Our normal response to this is to call XSetSelectionOwner, but we specifically do nothing if we currently own the Win32 clipboard. (Harold L Hunt II) 7) winclipboardwndproc.c/winClipboardWindowProc/WM_RENDERFORMAT,W M_RENDERALLFORMATS - Request the contents of the X11 selection. Use XPeekIfEvent to wait until the response is added to our event queue (this could probably lead to a dead-lock of a client exists before responding), then call winClipboardFlushXEvents to handle the SelectionNotify event. UTF8 and CompoundText targets require that we call XConvertSelection from the SelectionNotify event, which will cause another SelectionNotify event to be fired; be careful to check for this and do the XPeekIfEvent/winClipboardFlushXEvents thing again if this is the case (this is untested because I did not see any UTF8 or CompoundText targets that needed conversion). Copy the returned contents to the Win32 clipboard with SetClipboardData (). (Harold L Hunt II) 8) winscrinit.c/winFinishScreenInitFB - Generate a MIT-MAGIC-COOKIE-1 cookie and add it to the server's list of cookies. (Harold
Re: Updated: XFree86-xserv-4.3.0-31
Volker, Dr. Volker Zell wrote: Volker == Volker Zell writes: Volker Hi Harold Volker You made my day The selection ownership problem really went away. Volker I'm running the X version of XEmacs since half a day now and no Volker problems with selection and copy/paste between X and Windows. A couple of hours later it stopped working, now my XWin.log fills up with winProcSetSelectionOwner - OpenClipboard () failed: 0578 winProcSetSelectionOwner - OpenClipboard () failed: 0578 winProcSetSelectionOwner - OpenClipboard () failed: 0578 Hmm... that is not something I had seen before. Did an earlier entry in the XWin.log say anything about the clipboard manager shutting down? Want to bzip2 it and send XWin.log to me privately? Harold
Re: Updated: XFree86-xserv-4.3.0-31
Alexander Gottwald wrote: On Mon, 5 Jan 2004, Andrew Braverman wrote: I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? Noticed this too. It happend after sever reset. Hmm... I guess I didn't tell you guys that server resets were not supported, right? :) I already had a fix in my code base for this last night. The problem is that the server functions vectors are only setup once, but I keep wrapping the function each time the server resets. I added an if (serverGeneration == 1) to my local code last night, just after I posted the 4.3.0-31 release. That should stop the multiple wrapping from happening, which is causing the crash. Harold
Re: Updated: XFree86-xserv-4.3.0-31
Daniel, Armbrust, Daniel C. wrote: I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll). Should the installer handle this automatically? You must have been going for a very long time before upgrading. Yes, the cygipc package is a dependency of the X packages, but if you upgrade from an old version that did not require it, then it might not be automatically selected for installation. The solution is to manually select the cygipc package. Harold
Re: IPC not configured
Darryl, Darryl Scott wrote: Hi! I have recently been starting to use cygwin on a Windows 2003 server. The UNIX code has been ported using Interix, windows services for UNIX. This does not come with an X-server. Okay, is your ported code in these examples still being run under Interix, or has it been recompiled under Cygwin? I am thinking Cygwin, but I want to make sure. The port has been very straightforward. The single user X applications work A-OK. I am having problems with the multi-user versions which make use of IPC. When I try starting say message queues within cygwin and check with ipcs the system states that the kernel has not been configured for IPC. The cygipc package in Cygwin provides IPC support. It has to be started manually. IPC started via c-shell in Interix are active and X-apps in cygwin start and put a message on to a queue, the other end of the queue is not read and so the app hangs. That sort of integration between the IPC system in Interix and the IPC system in Cygwin is unlikely to work. I don't believe that cygipc is using Windows' IPC mechanisms, so Interix would have no knowledge of what is going on in cygipc, etc. At least, I suspect that is how it is implemented, but I could be wrong. If anyone could point me to documentation I will be delighted. Here is Chuck Wilson's documentation: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/ Here is the readme for cygipc: http://www.neuro.gatech.edu/users/cwilson/cygutils/cygipc/#README Do note that the cygipc package will be dropped in favor of the new cygserver application that works in conjunction with function stubs in a new version of cygwin1.dll. That will allow all Cygwin apps to be compiled with IPC support and to only enable it when cygserver is running. That change will require a recompile of all apps that use IPC, I believe. Harold
RE: Updated: XFree86-xserv-4.3.0-31
No problem. I understood it was a test release and just went back to the old. FYI - I am not, however, using the -query parameter in my XWin invocation. I am using ssh tunnels and therefore am not doing a query. The invocation looks like this: XWin -once -emulate3buttons -clipboard -multiwindow -lesspointer -clipupdate s 5 Even running it multiple times gets me the same result. I will check it again the next time you put it out. I would love to use it. It sounds like it will solve a bunch of problems. As usual, sincere thanks go out to the crew of a half dozen or so of you who do most of the work on this project. If it were not for you guys (especially Harold), this project would not go anywhere. There are many other contributors who deserve thanks, but they would not have something to contribute to without the core group of you guys. One of these days, when I have some free time, I need to try to look more deeply at the code and try to help out some more. Thanks again to all for a wonderful product. Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harold L Hunt II Sent: Monday, January 05, 2004 2:31 PM To: [EMAIL PROTECTED] Subject: Re: Updated: XFree86-xserv-4.3.0-31 Andrew, Yup, this happens when you are using -query and there are no entries in your .Xauthority file. You can alleviate this by running it again after it crashes, since the previous entries are left in the file. This is something that still has to be fixed or worked around and that is why these are 'test' releases. Sorry for not describing this particular failure mode in the announcement. Harold Andrew Braverman wrote: I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harold L Hunt II Sent: Monday, January 05, 2004 2:09 AM To: cygxannounce Subject: Updated: XFree86-xserv-4.3.0-31 Announcement The XFree86-xserv-4.3.0-31 package has been updated in the Cygwin distribution. Links = Server source, direct link: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040105-0 105.tar.bz2 (131 KiB) xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-29 (yes, the file has the wrong name, just live with it) source code: http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-30-t o-4.3.0-31.diff (39 KiB) xc/programs/Xserver/Imakefile diff against XFree86 CVS: http://www.msu.edu/~huntharo/xwin/devel/server/xc-programs-Xse rver-Imakefile-20040105-0105.diff (1 KiB) Changes === 1) General - Everything up to the last three entries describes the new clipboard handling system that does not steal ownership of the X11 selection each time that something is selected; this seems to work fine, but it needs to be tested. The last three entries describe my nearly complete attempt at generating a MIT-MAGIC-COOKIE-1, adding it to the list of cookies that the X Server recognizes, and using it when the clipboard client tries to connect during an XDMCP connection. This authentication approach should work, but I need a break from trying to figure out which of the function calls has a minor error in its parameters; thus, it does not currently work. However, feel free to examine the source code and let me know if any of my calls to GenerateAuthorization, AddResource, or XauWriteAuth are incorrect. I would really like to get this automatic authorization working as soon as possible. Until then I will mark this release (and all releases based upon it) as 'test'. 2) InitInput.c - Add a function, winProcSetSelectionOwner, and wrap the generic function ProcVector[X_SetSelectionOwner] with it. This allows us to get a notification each time the selection (clipboard) owner changes. Call SetClipboardData (foo, NULL) so that the WM_RENDERFORMAT message will be posted when a Win32 app requests the clipboard contents. (Harold L Hunt II, Alexander Gottwald) 3) winclipboardxevents.c/winClipboardFlushXEvents/SelectionNotify - No longer steal ownership of the selection each time it changes in X11. We can do this because we have notification when SetSelectionOwner is called (see above). (Harold L Hunt II) 4) winclipboardxevents.c/winClipboardFlushXEvents/SelectionClear - Remove handling, it is no longer needed; it used to request the contents of the selection that we lost ownership of. (Harold L Hunt II) 5) winclipboardwndproc.c/winClipboardWindowProc/WM_CREATE,WM_DESTROY - Add information to be used on each call
Re: Updated: XFree86-xserv-4.3.0-31
Alexander Gottwald wrote: On Mon, 5 Jan 2004, Andrew Braverman wrote: I just tried running this version and it crashes. I get a normal looking stuff at the beginning of the XWin.log file and then get one line telling me: winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. Then I get 64K + lines (total size of log file is 65072 lines) of: winProcSetSelectionOwner - We changed ownership, aborting. Does anyone have any ideas? Noticed this too. It happend after sever reset. Here is a dumb question: if the clipboard client is attached, how did you cause a server reset? Is there a way to force the server to reset when there are clients still attached? I need to be able to do this in order to test my fix... and it sounds like there is a way to do this, since I don't think it could happen automatically. Harold
fatal IO error 104 on start
Hi All, I just installed cygwin on my work machine, but am unable to start the X server. Each time I try (using startx), I receive the following error: XIO: fatal IO error 104 (Connection reset by perr) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I searched the archives and saw that others were having the same problem at the end of November/beginning of December, but no solution was offered. I downloaded the packages from a couple of different sources this morning, but none of them produced different results. Other than the few times that I've installed the software this morning, cygwin had not been on this machine previously. (It's a new box.) Does anybody know how to resolve this? Thanks, Greg Jewell
Re: fatal IO error 104 on start
Greg, Look at /tmp/XWin.log. Harold Greg Jewell wrote: Hi All, I just installed cygwin on my work machine, but am unable to start the X server. Each time I try (using startx), I receive the following error: XIO: fatal IO error 104 (Connection reset by perr) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I searched the archives and saw that others were having the same problem at the end of November/beginning of December, but no solution was offered. I downloaded the packages from a couple of different sources this morning, but none of them produced different results. Other than the few times that I've installed the software this morning, cygwin had not been on this machine previously. (It's a new box.) Does anybody know how to resolve this? Thanks, Greg Jewell
Re: Updated: XFree86-xserv-4.3.0-31
Harold L Hunt II wrote:
I already had a fix in my code base for this last night. The problem is
that the server functions vectors are only setup once, but I keep
wrapping the function each time the server resets. I added an if
(serverGeneration == 1) to my local code last night, just after I posted
the 4.3.0-31 release. That should stop the multiple wrapping from
happening, which is causing the crash.
how about
if (ProcVector[X_SetSelectionOwner] != winSetSelectionOwner)
{
oldSetSelectionOwner = ProcVector[X_SetSelectionOwner];
ProcVector[X_SetSelectionOwner] = winSetSelectionOwner;
}
bye
ago
--
[EMAIL PROTECTED]
http://www.gotti.org ICQ: 126018723
Re: Updated: XFree86-xserv-4.3.0-31
Harold == Harold L Hunt, Harold writes: Harold Hmm... that is not something I had seen before. Did an earlier entry Harold in the XWin.log say anything about the clipboard manager shutting Harold down? Want to bzip2 it and send XWin.log to me privately? Sorry, I'm reading this mail from my home. So I already booted my laptop and XWin.log got overwritten. If I see the error again I'll send it to you. Harold Harold Ciao Volker
Re: Updated: XFree86-xserv-4.3.0-31
Harold L Hunt II wrote: Noticed this too. It happend after sever reset. Here is a dumb question: if the clipboard client is attached, how did you cause a server reset? good question. I've started a session and stopped the windowmanager. The log showed signs of another server generation. I'll check tomorrow. Maybe the clipboard client died before. I've also noticed different behaviour (crash or segfault) depending on which side (X11, Win32) has changed the clipboard last but had no time to examine this further. I can test it tomorrow. is there a way to force the server to reset when there are clients still attached? I need to be able to do this in order to test my fix... and it sounds like there is a way to do this, since I don't think it could happen automatically. I'm quite sure there are similar functions to TerminateServer. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
RE: Updated: XFree86-xserv-4.3.0-31
Yeah, it had been a couple of months I usually try to avoid upgrading it unless there is a new feature I want (if its not broke) I had to track down three missing dll files, but now the cut and paste upgrades are working great. Thanks for your work yet again, Harold. This was about the only thing on my it would be nice if it was fixed list For my uses of cygwin anyway. Dan -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 1:53 PM To: [EMAIL PROTECTED] Subject: Re: Updated: XFree86-xserv-4.3.0-31 Daniel, Armbrust, Daniel C. wrote: I just upgraded my install, and now it reports a missing dll file (cygcygipc-2.dll). Should the installer handle this automatically? You must have been going for a very long time before upgrading. Yes, the cygipc package is a dependency of the X packages, but if you upgrade from an old version that did not require it, then it might not be automatically selected for installation. The solution is to manually select the cygipc package. Harold
Please test XFree86-xserv-4.3.0-32
I posted a new release today with updates to the clipboard handling. Please test it and report your results if you can. I know that the new binary is on at least mirrors.kernel.org already. I can't tell if I broke something from the 4.3.0-31 release or not; emacs in X11 is not copying text from the Win32 clipboard when it does a paste, nor is it unhighlighting the selection when I copy something in Win32. I thought that was working before. I would appreciate it if someone else could confirm that this is new bustage. Harold
Re: XDMCP Problems - Possible fix, please try
Harold L Hunt II wrote: The XFree86-xserv-4.3.0-30 release may fix some problems with not getting a login screen when using XDMCP. See the change log for more information: http://xfree86.cygwin.com/devel/server/changelog.html Please try this new server and report on whether it allows you to get a login screen or not. Thanks for testing, Sorry for the delay. We were having problems with our router and general networking issues - not an nice environment to test things like remote X... Well I tried that too but it didn't work. The symptoms are exactly the same. For kicks I tried the following: While on sonslinux I attempted to start another X server like so: $ X -query sonslinux :1 This brought me to another console (that I could get to by doing Alt-Ctrl-F8 whereas my previous console is at Alt-Ctrl-F7) and started X but KDM did not attach to it. Monitoring I see: /var/log/messages: nothing new /var/log/kdm.log nothing at all stdout/stderr where I ran the above X -query ...: XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: SuSE Linux [ELF] SuSE Build Date: 11 September 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.1.log, Time: Mon Jan 5 15:18:01 2004 (==) Using config file: /etc/X11/XF86Config (EE) R128(0): No DFP detected (EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI. Could not init font path element /usr/X11R6/lib/X11/fonts/local, removing from l ist! Could not init font path element /usr/X11R6/lib/X11/fonts/kwintv, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID, removing from lis t! XDM: too many retransmissions /var/log/XFree86.0.log: attached I retried this operation with the following command: $ X -query sonssun :1 where sonssun is a Sun box running Solaris 7. A CDE session came up with no problems! Then I shut all this down again and cleared out the log files and did an XWin -query sonslinux -from adefaria again: /tmp/XWin.log (from my XP system): attached I'm stumped. I think we need to turn on some more debugging options and try again. Let me know what to try. attached -- Mental Floss prevents Moral Decay. XFree86 Version 4.3.0 Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: SuSE Linux [ELF] SuSE Build Date: 11 September 2003 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.1.log, Time: Mon Jan 5 15:18:01 2004 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Layout[all] (**) |--Screen Screen[0] (0) (**) | |--Monitor Monitor[0] (**) | |--Device Device[0] (**) |--Input Device Keyboard[0] (**) Option Protocol Standard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout us (**) XKB: layout: us (==) Keyboard: CustomKeycode disabled (**) |--Input Device Mouse[1] (WW) The directory /usr/X11R6/lib/X11/fonts/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/PEX does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/latin2/misc does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/latin2/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/latin2/100dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/latin2/Type1 does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/latin7/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/baekmuk does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/japanese does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/ucs/misc does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/ucs/75dpi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/ucs/100dpi does not exist. Entry deleted from font path. (WW) The
RE: fatal IO error 104 on start
Thanks for the tip. Looking at the log file, it appears that this is the pertinent error message: Fatal server error: could not open default font 'fixed' winDeinitClipboard - Noting shutdown in progress winDeinitMultiWindowWM - Noting shutdown in progress Any ideas? I installed the default XFree86 packages. Greg -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 13:58 To: [EMAIL PROTECTED] Subject: Re: fatal IO error 104 on start Greg, Look at /tmp/XWin.log. Harold Greg Jewell wrote: Hi All, I just installed cygwin on my work machine, but am unable to start the X server. Each time I try (using startx), I receive the following error: XIO: fatal IO error 104 (Connection reset by perr) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I searched the archives and saw that others were having the same problem at the end of November/beginning of December, but no solution was offered. I downloaded the packages from a couple of different sources this morning, but none of them produced different results. Other than the few times that I've installed the software this morning, cygwin had not been on this machine previously. (It's a new box.) Does anybody know how to resolve this? Thanks, Greg Jewell
Re: New clipboard handling notes (XFree86-xserv-4.3.0-31)
Is the eventual goal of XFree86-xserv-4.3.0-31 going to be to eliminate the need for xwinclip in xdmcp setups? Or this something totally different. (I only use X to login to remote boxes.) On Mon, 2004-01-05 at 02:40, Harold L Hunt II wrote: Here are my notes that I put together to convince myself that the new clipboard handling was complete and would not cause infinite loops. Please examine the notes if you are interested in the new code or if you would like to double-check my logic for errors. Please review the steps and post to the list if you think you have found an error. Also, if you find a bug or a crash, look at these steps and try to identify the approximate location of your problem so that we can do a better job of debugging. Harold Copy in X11 === 1) winProcSetSelectionOwner gets called and takes ownership of the Win32 clipboard (OpenClipboard, EmptyClipboard, SetClipboardData (foo, NULL)). 2) Selection is owned by another X11 client (the one that called XSetSelectionOwner). 3) EmptyClipboard() in step #1 files WM_DRAWCLIPBOARD message, which is ignored since hwnd == GetClipboardOwner (). 4) Paste in X11 a) Owning X11 client handles SelectionRequest events. b) Item is pasted within X11 without round-trip to Win32. 5) Paste in Win32 a) WM_RENDERFORMAT fires. b) SelectionRequest is sent, conversion from X11 to Win32 is done. c) SetClipboardData is called, passing converted text. 6) Copy in X11 (different app) a) Goto Step #1. 7) Copy in Win32 a) Clipboard is emptied and owned by the other application. b) WM_DRAWCLIPBOARD fires, XSetSelectionOwner is called, owning the selection for the clipboard integration manager. Copy in Win32 = 1) WM_DRAWCLIPBOARD fires, calls XSetSelectionOwner for itself. 2) winProcSetSelectionOwner gets called, does nothing since clipboard X11 window is the window that is taking ownership. 3) Paste in Win32 a) Clipboard owning Win32 app handles GetClipboardData call. b) Item is pasted without round-trip to X11. 4) Paste in X11 a) Clipboard integration manager receives SelectionRequest. b) GetClipboardData is called, returning Win32 clipboard contents. c) Conversion from Win32 to X11 is done and text is pasted. 5) Copy in X11 a) winProcSetSelectionOwner is called. b) Clipboard integration manager takes ownership of Win32 clipboard. c) WM_DRAWCLIPBOARD fires and is ignored since hwnd == GetClipboardOwner (). 6) Copy in Win32 (different app) a) Goto Step #1.
Re: XDMCP Problems - Possible fix, please try
Andrew,
Andrew DeFaria wrote:
Sorry for the delay. We were having problems with our router and general
networking issues - not an nice environment to test things like remote X...
Well I tried that too but it didn't work. The symptoms are exactly the
same.
For kicks I tried the following:
While on sonslinux I attempted to start another X server like so:
$ X -query sonslinux :1
This brought me to another console (that I could get to by doing
Alt-Ctrl-F8 whereas my previous console is at Alt-Ctrl-F7) and started X
but KDM did not attach to it. Monitoring I see:
That is genius! I never thought of forcing people to try to make a
connection on the actual box itself.
I ran the same command on my linux box and confirmed that it does work.
I then edited (for my display manager and distribution, this will be
different for you) /etc/kde3/kdm/kdmrc, changed the following:
[XDMCP]
Enable=true
to
[XDMCP]
Enable=false
Then I restarted kdm ('/etc/init.d/kdm restart' for my dist), and ran 'X
-query %hostname% :1' again and waited about five minutes. Before five
minutes, I saw nothing: nothing special in the log files and no login
screen on Ctrl-Alt-F8. Then, after about five minutes, I saw that the
/var/log/XFree86.1.log file (and the console from which I started X)
both said:
XDM: too many retransmissions
We now know that the failure mode when XDMCP is disabled is that after a
five minute wait you get a message about too many retransmissions, even
if attempting to connect from the machine back to itself via '-query
%hostname%'. This is the same failure mode that happens with XWin.exe,
but it eliminates lots of possible problems.
To solve your problem, you need to revisit the instructions for enabling
XDMCP on your Linux box:
http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-mandrake-8.1-xdmcp
Those instructions are not complete, but they are a start that should be
able to point you in the right direction. Confirm that you can create a
local connection via XDMCP before attempting a remote connection with
XWin.exe. Please report your results to the list so that I know if you
have fixed your problem or not.
Thanks for your help in debugging this,
Harold
Re: fatal IO error 104 on start
Follow these steps: 1) Open Cygwin bash shell. 2) In bash shell, run the following two commands: umount /usr/X11R6/lib/X11/fonts umount -u /usr/X11R6/lib/X11/fonts 3) Rerun Cygwin's setup.exe, select 'Reinstall' for any of the following packages that were already installed: XFree86-f100 XFree86-fcyr XFree86-fenc XFree86-fnts XFree86-fscl 4) Launch Cygwin/X again and test that the font problems have gone away. 5) Report your results here along with any deviations you had to make from these instructions. Harold Greg Jewell wrote: Thanks for the tip. Looking at the log file, it appears that this is the pertinent error message: Fatal server error: could not open default font 'fixed' winDeinitClipboard - Noting shutdown in progress winDeinitMultiWindowWM - Noting shutdown in progress Any ideas? I installed the default XFree86 packages. Greg -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED] Sent: Monday, January 05, 2004 13:58 To: [EMAIL PROTECTED] Subject: Re: fatal IO error 104 on start Greg, Look at /tmp/XWin.log. Harold Greg Jewell wrote: Hi All, I just installed cygwin on my work machine, but am unable to start the X server. Each time I try (using startx), I receive the following error: XIO: fatal IO error 104 (Connection reset by perr) on X server :0.0 after 0 requests (0 known processed) with 0 events remaining. I searched the archives and saw that others were having the same problem at the end of November/beginning of December, but no solution was offered. I downloaded the packages from a couple of different sources this morning, but none of them produced different results. Other than the few times that I've installed the software this morning, cygwin had not been on this machine previously. (It's a new box.) Does anybody know how to resolve this? Thanks, Greg Jewell
Re: XDMCP Problems - Possible fix, please try
Harold L Hunt II wrote:
Andrew,
Andrew DeFaria wrote:
Sorry for the delay. We were having problems with our router and
general networking issues - not an nice environment to test things
like remote X...
Well I tried that too but it didn't work. The symptoms are exactly
the same.
For kicks I tried the following:
While on sonslinux I attempted to start another X server like so:
$ X -query sonslinux :1
This brought me to another console (that I could get to by doing
Alt-Ctrl-F8 whereas my previous console is at Alt-Ctrl-F7) and
started X but KDM did not attach to it. Monitoring I see:
That is genius!
Why thank you!
I never thought of forcing people to try to make a connection on the
actual box itself.
I ran the same command on my linux box and confirmed that it does work.
I then edited (for my display manager and distribution, this will be
different for you) /etc/kde3/kdm/kdmrc, changed the following:
[XDMCP]
Enable=true
to
[XDMCP]
Enable=false
Then I restarted kdm ('/etc/init.d/kdm restart' for my dist), and ran
'X -query %hostname% :1' again and waited about five minutes. Before
five minutes, I saw nothing: nothing special in the log files and no
login screen on Ctrl-Alt-F8. Then, after about five minutes, I saw
that the /var/log/XFree86.1.log file (and the console from which I
started X) both said:
XDM: too many retransmissions
Well you see that's sorta the problem. In my distro (SuSE 8.2) it's at
/opt/kde/share/config/kdm/kdmrc but the problem is that it already says
true! In mine is says:
[Xdmcp]
Enable=true
I don't think that the capitalization of Xdmcp is significant (yours is
all caps while mine is initial cap - tried changing it - didn't help)
nor do I think that case is significant in the true/false value. Also, I
cannot restart kdm with /etc/init.d/kdm restart as I have no
/etc/init.d/kdm! I have an /etc/init.d/xdm though. When I do
/etc/init.d/xdm stop it says Shutting down service kdm and it does
shut it down. Similarly /etc/init.d/xdm start starts it.
So I have no ideas why this is still not working.
We now know that the failure mode when XDMCP is disabled is that after
a five minute wait you get a message about too many retransmissions,
even if attempting to connect from the machine back to itself via
'-query %hostname%'. This is the same failure mode that happens with
XWin.exe, but it eliminates lots of possible problems.
To solve your problem, you need to revisit the instructions for
enabling XDMCP on your Linux box:
http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-mandrake-8.1-xdmcp
Those instructions are not complete, but they are a start that should
be able to point you in the right direction. Confirm that you can
create a local connection via XDMCP before attempting a remote
connection with XWin.exe. Please report your results to the list so
that I know if you have fixed your problem or not.
Thanks for your help in debugging this,
Well I've been there before and all it really says is to make sure that
[Xdmcp] has Enable=true, which mine does. Still no does not work.
--
I've always wanted to be somebody, but I should have been more specific.
Re: XDMCP Problems - Possible fix, please try
Andrew DeFaria wrote:
I never thought of forcing people to try to make a connection on the
actual box itself.
I ran the same command on my linux box and confirmed that it does work.
I then edited (for my display manager and distribution, this will be
different for you) /etc/kde3/kdm/kdmrc, changed the following:
[XDMCP]
Enable=true
to
[XDMCP]
Enable=false
Then I restarted kdm ('/etc/init.d/kdm restart' for my dist), and ran
'X -query %hostname% :1' again and waited about five minutes. Before
five minutes, I saw nothing: nothing special in the log files and no
login screen on Ctrl-Alt-F8. Then, after about five minutes, I saw
that the /var/log/XFree86.1.log file (and the console from which I
started X) both said:
XDM: too many retransmissions
Well you see that's sorta the problem. In my distro (SuSE 8.2) it's at
/opt/kde/share/config/kdm/kdmrc but the problem is that it already says
true! In mine is says:
[Xdmcp]
Enable=true
kdm != xdm
kdm has a distinct configuration file from xdm's configuration file.
xdm.config lives in either /etc/X11/xdm/xdm.config or
/usr/X11R6/lib/X11/xdm/xdm-config, where you will see something like the
following:
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort: 0
So, you have to change that to:
! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
! DisplayManager.requestPort: 0
Then restart xdm and it should work.
Harold
Re: XDMCP Problems - Possible fix, please try
Andrew, I think at this point you need to start looking at some SuSE docs to figoure out how to enable XDMCP on that distribution. This is not a problem with Cygwin/X... it is clearly a problem with the configuration of your SuSE box. I think that other mailing lists/websites/newsgroups would have more specific information that can better assist you. Harold
Clipboard progress
I don't have another release ready, so I wanted to update people on the progress I am making: 1) I talked with Keith Packard and found out that I can use XSetAuthorization to tell Xlib to use the cookie that I generated and installed within the server. This allows the integrated clipboard manager (-clipboard parameter) to connect when making an XDMCP connection (-query parameter). It works great! 2) The only problem with step #1 is that we have to detect when we are doing an XDMCP connection and delay the clipboard client connecting to the X Server until the XDMCP connection has been made. If we don't, then the XDMCP code will perform a server reset, the clipboard client will re-attach, XDMCP will perform a reset, ad nauseum. Well, it isn't quite that bad because the clipboard client crashes the server shortly after the first reset :) I can detect when XDMCP is being used, but I haven't found a good way to detect that XDMCP has connected to the X server... I suppose I could monitor the total client count and use that as a signal, but I would have to poll it. More later. 3) I created a new function, similar to OsVendorInit, called OsVendorReset, that gets called from Xserver/dix/dispatch.c/Dispatch right before KillAllClients is called. It allows me to do some processing right before the X Server is going to reset. The primary interest here is to shut down the clipboard client cleanly and to unwrap the XSetSelectionOwner function so that it doesn't crash the next time it is called. This works pretty well so far (it delays the total crash until after two resets), but it is going to require a thorough examination of the startup and shutdown process for the clipboard client, as well as a complete re-write of all of that code. 4) I think the problem I saw with emacs was due to emacs using the CLIPBOARD selection instead of the PRIMARY selection. I have not yet added support for the CLIPBOARD selection, so applications that depend upon it will be broken. 5) I added code that releases ownership of the Windows clipboard (if we currently own it) when XSetSelectionOwner is called with a window of None... that is done when an X Client says, I don't want to own the selection anymore. It is probably going to take me a few days to work through all of these issues, if not a week or more. So, be patient, and wait for better clipboard support than we have ever had! Harold
