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
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
> "Harold" == Harold L Hunt, 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:
> 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
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
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
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: 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
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
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 L
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: 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: 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
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 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; t
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
