public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
* RE: Updated: XFree86-xserv-4.3.0-33 [not found] <3FFD075A.8020404@msu.edu> @ 2004-01-08 15:16 ` Andrew Braverman 2004-01-08 15:20 ` Harold L Hunt II 0 siblings, 1 reply; 6+ messages in thread From: Andrew Braverman @ 2004-01-08 15:16 UTC (permalink / raw) To: 'cygx' [-- Attachment #1: Type: text/plain, Size: 6275 bytes --] I seem to be the one not to have any luck lately. I tried running this package and get a standard windows "XWin-33.exe has encountered a problem and needs to close. We are sorry for the inconvenience." message. There was no useful stackdump. After going through my batch file, I found that if I put a "sleep 2" before the "xhost +hostname" command that I have in the file, XWin does not crash. If I use "sleep 1", it sometimes crashes. With no sleep, it crashes. I have attached an XWin.log from one of the attempts with no sleep. - Andy > -----Original Message----- > From: cygwin-xfree-announce-owner@cygwin.com > [mailto:cygwin-xfree-announce-owner@cygwin.com]On Behalf Of Harold L > Hunt II > Sent: Thursday, January 08, 2004 2:32 AM > To: cygxannounce > Subject: Updated: XFree86-xserv-4.3.0-33 > > > Announcement > ============ > > The XFree86-xserv-4.3.0-33 'test' package has been updated in > the Cygwin > distribution. > > > Links > ===== > > Server source, direct link: > http://www.msu.edu/~huntharo/xwin/devel/server/xwin-20040107-2 315.tar.bz2 > (137 KiB) > > xc/programs/Xserver/hw/xwin (all files) diff against 4.3.0-32 > source code: > http://www.msu.edu/~huntharo/xwin/devel/server/xwin-4.3.0-32-t > o-4.3.0-33.diff > (113 KiB) > > > Changes > ======= > > 1) General - If you use the diff above, note that the Imakefile was > missing from previous tarballs, so this diff includes the whole > Imakefile. I have updated my source packaging script so that this > does not happen again. Also, the source code in this release has > already been committed to the xorg repository on freedesktop.org's > CVS. (Harold L Hunt II) > > 2) winauth.c - New File - Move winGenerateAuthorization into this new > file. This function generates a cookie to be used by the clipboard > client for authorization when using Xdmcp. (Harold L Hunt II) > > 3) winglobals.c - New File - Start moving global variables into this > file. (Harold L Hunt II) > > 4) winclipboardwrappers.c - New File - Move all clipboard wrappers of > ProcVector and InitialVector funtions into this file. > (Harold L Hunt II) > > 5) winprocarg.c - New File - Move winInitializeDefaultScreens and > ddxProcessArgument from InitOutput.c into this file. The same will be > done eventually for other functions in InitOutput.c. (Harold L Hunt > II) > > 6) win.h, General - Get started on removing "extern" declarations > from win.h by including explicit references to extern symbols in the > source files that use those symbols. The long term goal is to start > breaking up the monolithic win.h header file. (Harold L Hunt II) > > 7) Xserver/dix/dispatch.c/Dispatch() - Add hook to OsVendorReset > function that can be optionally defined in the DDX layer when > DDXOSRESET is defined. (Harold L Hunt II) > > 8) InitOutput.c/OsVendorReset() - New Function - Send a message to > the clipboard client telling it to shutdown, then wait for the > clipboard client thread to exit before proceeding. This allows us to > cleanly shutdown the clipboard client. Incidentally, I noticed that > the previous code would spawn *additional* clipboard client threads > when the X Server was reset; this was happening because we trapped IO > errors and attempted to reconnect when they happened. There was no > code that told a clipboard client thread to exit when the server was > being reset so that it could be replaced by a new clipboard client > thread (which was happening correctly). This should lead to greater > stability across X Server resets, though I did discover that this > version and previous versions where shutting down after two or three > resets without any error message being logged nor exception being > thrown. That problem will be looked into later. (Harold L Hunt > II) > > 9) winclipboardinit.c, winclipboardthread.c, winclipboardxevents.c, > winclipboardwndproc.c - Fix problems getting killed by Xdmcp code and > remote XDM/KDM/GDM client on startup. Fix problems not being > authorized to connect when using Xdmcp by calling XSetAuthorization > and passing it our cookie that was created earlier; this removes the > need to save the cookie to a .Xauthority file. Watch the CLIPBOARD > selection in addition to the PRIMARY selection and track which was > changed within X last so that we know which one we should paste within > Win32. Fix crashes when the server resets (as explained above, it > still exits after one or two resets, for an unknown reason). The > improved clipboard code should now be good to go. (Harold L Hunt > II) > > 10) winmultiwindowwm.c - Clean up the startup of the two multi-window > threads. Create separate error and IO error handlers for the XMsgProc > thread since it was using the same IO error handler as another thread > and would try to longjmp into the other thread if it received an IO > error, which was likely causing some crashes. The multi-window code > needs additional work to confirm that it properly shuts down and exits > both threads; something similar to the clipboard shutdown message in > OsVendorReset will be needed. (Harold L Hunt II) > > 11) winclipboardxevents.c - Find and fix a last minute bug that caused > Unicode clipboard translations to be broken. (Kensuke Matsuzaki, > Harold L Hunt II) > > -- > Harold Hunt > > To update your installation, click on the "Install Cygwin now" link on > the http://cygwin.com/ web page. This downloads setup.exe to your > system. Once you've downloaded setup.exe, run it and select "XFree86" > and then click on the appropriate field until the above announced > version number appears if it is not displayed already. > > If your mirror doesn't yet have the latest version of this > package after > 24 hours, you can either continue to wait for that site to be > updated or > you can try to find another mirror. > > Please send questions or comments to the Cygwin/X mailing list at: > cygwin-xfree@cygwin.com > > If you want to subscribe go to: > http://cygwin.com/ml/cygwin-xfree/ > > I would appreciate if you would use this mailing list rather than > emailing me directly. This includes ideas and comments about > the setup > utility or Cygwin/X in general. > > If you want to make a point or ask a question the Cygwin/X mailing > list is the appropriate place. > [-- Attachment #2: XWin.log --] [-- Type: application/octet-stream, Size: 3453 bytes --] ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root (EE) Unable to locate/open config file InitOutput - Error reading config file winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - Allowing PrimaryDD winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0000001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 990 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 0 990 1280 winCreateBoundingWindowWindowed - WindowClient w 1280 h 990 r 1280 l 0 b 990 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 990 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1280 height: 990 depth: 16 size image: 2534400 winAllocateFBShadowGDI - Created shadow stride: 1280 winFinishScreenInitFB - Masks: 0000f800 000007e0 0000001f winInitVisualsShadowGDI - Masks 0000f800 000007e0 0000001f BPRGB 6 d 16 bpp 16 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () LoadPreferences: Done parsing the configuration file... InitOutput - Returning. 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 (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "00000409" (00000409) (EE) No primary keyboard configured (==) Using compiletime defaults for keyboard Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" winPointerWarpCursor - Discarding first warp: 640 495 winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. winInitMultiWindowWM - Calling setlocale () winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - Calling setlocale () OsVendorReset - Hello winInitMultiWindowWM - setlocale () returned winMultiWindowXMsgProc - pthread_mutex_lock () returned. winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updated: XFree86-xserv-4.3.0-33 2004-01-08 15:16 ` Updated: XFree86-xserv-4.3.0-33 Andrew Braverman @ 2004-01-08 15:20 ` Harold L Hunt II 2004-01-08 19:48 ` Andrew Braverman 0 siblings, 1 reply; 6+ messages in thread From: Harold L Hunt II @ 2004-01-08 15:20 UTC (permalink / raw) To: cygwin-xfree Andrew Braverman wrote: > I seem to be the one not to have any luck lately. I tried running this > package and get a standard windows "XWin-33.exe has encountered a problem > and needs to close. We are sorry for the inconvenience." message. There > was no useful stackdump. After going through my batch file, I found that if > I put a "sleep 2" before the "xhost +hostname" command that I have in the > file, XWin does not crash. If I use "sleep 1", it sometimes crashes. With > no sleep, it crashes. I have attached an XWin.log from one of the attempts > with no sleep. > > - Andy Andy, You should not need the 'xhost +hostname' unless hostname is a remote host. Have you tried without the -clipboard parameter to confirm whether the problem persists in that case? Harold ^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Updated: XFree86-xserv-4.3.0-33 2004-01-08 15:20 ` Harold L Hunt II @ 2004-01-08 19:48 ` Andrew Braverman 2004-01-10 6:43 ` Harold L Hunt II 0 siblings, 1 reply; 6+ messages in thread From: Andrew Braverman @ 2004-01-08 19:48 UTC (permalink / raw) To: cygwin-xfree I had not checked, but I just did. If I remove the -clipboard and the sleep, all is well. As another data point, a longer sleep is needed if the files are run on windows login (which is not surprising). On a different note, I have noticed that the X clipboard will transfer to windows as long as the data is highlighted. Once the data is unhighlighted (i.e. typing "clear") the text is still in the X buffer (middle button or shift insert pastes correctly), but the windows clipboard is empty. - Andy > -----Original Message----- > From: cygwin-xfree-owner@cygwin.com > [mailto:cygwin-xfree-owner@cygwin.com]On Behalf Of Harold L Hunt II > Sent: Thursday, January 08, 2004 10:20 AM > To: cygwin-xfree@cygwin.com > Subject: Re: Updated: XFree86-xserv-4.3.0-33 > > > Andrew Braverman wrote: > > > I seem to be the one not to have any luck lately. I tried > running this > > package and get a standard windows "XWin-33.exe has > encountered a problem > > and needs to close. We are sorry for the inconvenience." > message. There > > was no useful stackdump. After going through my batch > file, I found that if > > I put a "sleep 2" before the "xhost +hostname" command that > I have in the > > file, XWin does not crash. If I use "sleep 1", it > sometimes crashes. With > > no sleep, it crashes. I have attached an XWin.log from one > of the attempts > > with no sleep. > > > > - Andy > > Andy, > > You should not need the 'xhost +hostname' unless hostname is > a remote host. > > Have you tried without the -clipboard parameter to confirm > whether the > problem persists in that case? > > Harold > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Updated: XFree86-xserv-4.3.0-33 2004-01-08 19:48 ` Andrew Braverman @ 2004-01-10 6:43 ` Harold L Hunt II 2004-01-12 15:25 ` XFree86-xserv-4.3.0-38 test results Andrew Braverman 0 siblings, 1 reply; 6+ messages in thread From: Harold L Hunt II @ 2004-01-10 6:43 UTC (permalink / raw) To: cygwin-xfree Andrew, Andrew Braverman wrote: > I had not checked, but I just did. If I remove the -clipboard and the > sleep, all is well. As another data point, a longer sleep is needed if the > files are run on windows login (which is not surprising). Your crash is possibly due to xhost being the first X Client to connect... when it disconnects, the X Server tries to reset. There may be some problems in -clipboard that cause a crash in such a quick server startup followed by a reset. I have tried to fix those problems, but it is going to take me a while to find all of the bugs that have krept into the server reset code. Currently you can't even reset the server more than twice, without -clipboard and without -multiwindow, before it just exits without a warning or error message. So, you are likely to have to work around this problem for a while if it doesn't magically go away in the next release. For now, I would just drop the xhost command from your startup file. > On a different note, I have noticed that the X clipboard will transfer to > windows as long as the data is highlighted. Once the data is unhighlighted > (i.e. typing "clear") the text is still in the X buffer (middle button or > shift insert pastes correctly), but the windows clipboard is empty. That is an interesting point that I had thought of, but didn't really want to think hard about :) I spent about 12 hours coding this up... everytime I thought I had it, I realized that more basic changes were needed in the clipboard code. Now I have it working, I believe. One of the funniest things that I fixed was that we were creating one clipboard thread *per* screen. I realized, in looking at xc/programs/Xserver/dix/dispatch.c, that the selections are global to all screens running on the same display (or instance of XWin.exe). So, we really only needed one clipboard client thread, no matter how many -screen parameters were passed to XWin.exe. I changed the code to create just one clipboard client thread for the entire process... that really simplified the process of changing the code, since I didn't have to track things per-screen anymore. I have made your request work only for the PRIMARY and CLIPBOARD selections. It won't matter if the X client still has data in the SECONDARY selection, because we do not monitor that selection. So, don't complain if you can still paste in one or two X apps but not in Win32 :) Harold ^ permalink raw reply [flat|nested] 6+ messages in thread
* XFree86-xserv-4.3.0-38 test results 2004-01-10 6:43 ` Harold L Hunt II @ 2004-01-12 15:25 ` Andrew Braverman 2004-01-12 17:44 ` Harold L Hunt II 0 siblings, 1 reply; 6+ messages in thread From: Andrew Braverman @ 2004-01-12 15:25 UTC (permalink / raw) To: cygwin-xfree > [...] For now, I would just drop the xhost command from > your startup file. No problem. I can deal with it as long as you are aware of the issue. > > > On a different note, I have noticed that the X clipboard > will transfer to > > windows as long as the data is highlighted. Once the data > is unhighlighted > > (i.e. typing "clear") the text is still in the X buffer > (middle button or > > shift insert pastes correctly), but the windows clipboard is empty. > > That is an interesting point that I had thought of, but didn't really > want to think hard about :) I spent about 12 hours coding this up... > everytime I thought I had it, I realized that more basic changes were > needed in the clipboard code. Now I have it working, I believe. It seems to work now. Thanks. > I have made your request work only for the PRIMARY and CLIPBOARD > selections. It won't matter if the X client still has data in the > SECONDARY selection, because we do not monitor that selection. So, > don't complain if you can still paste in one or two X apps but not in > Win32 :) I try not to COMPLAIN about anything. :-) Seriously, though - I do realize how much time and energy are put into this project by the few core people and though I will report issues I see or ask questions, I will never complain about what is or is not done. You guys do too much work to deserve that. One of these days, I will make enough time to make some contributions of my own - and then I MIGHT have a right to complain a little. You guys have done a wonderful job, and as many have said before, we appreciate your work. Thank you. > > Harold > OS: Windows XP Language: English Win32->X11 Copy and Paste: Worked X11->Win32 Copy and Paste: Worked Xdmcp: Did Not Try - Andy ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: XFree86-xserv-4.3.0-38 test results 2004-01-12 15:25 ` XFree86-xserv-4.3.0-38 test results Andrew Braverman @ 2004-01-12 17:44 ` Harold L Hunt II 0 siblings, 0 replies; 6+ messages in thread From: Harold L Hunt II @ 2004-01-12 17:44 UTC (permalink / raw) To: cygwin-xfree Andrew, Andrew Braverman wrote: >>[...] For now, I would just drop the xhost command from >>your startup file. > > > No problem. I can deal with it as long as you are aware of the issue. Okay. I think it needs to be fixed eventually so that the problem is not repeatedly reported. >>>On a different note, I have noticed that the X clipboard >> >>will transfer to >> >>>windows as long as the data is highlighted. Once the data >> >>is unhighlighted >> >>>(i.e. typing "clear") the text is still in the X buffer >> >>(middle button or >> >>>shift insert pastes correctly), but the windows clipboard is empty. >> >>That is an interesting point that I had thought of, but didn't really >>want to think hard about :) I spent about 12 hours coding this up... >>everytime I thought I had it, I realized that more basic changes were >>needed in the clipboard code. Now I have it working, I believe. > > > It seems to work now. Thanks. No problem. >>I have made your request work only for the PRIMARY and CLIPBOARD >>selections. It won't matter if the X client still has data in the >>SECONDARY selection, because we do not monitor that selection. So, >>don't complain if you can still paste in one or two X apps but not in >>Win32 :) > > > I try not to COMPLAIN about anything. :-) Seriously, though - I do realize > how much time and energy are put into this project by the few core people > and though I will report issues I see or ask questions, I will never > complain about what is or is not done. You guys do too much work to deserve > that. One of these days, I will make enough time to make some contributions > of my own - and then I MIGHT have a right to complain a little. You guys > have done a wonderful job, and as many have said before, we appreciate your > work. Thank you. Sorry. My "complain" should be read as more of a "I am already aware of this problem, so it doesn't have to be mentiond" and it was really written for other readers, not for you. I don't think you are complaining :) It is just that if others see this in the future, I don't want them saying "me too" if they notice this problem. > OS: Windows XP > > Language: English > > Win32->X11 Copy and Paste: Worked > > X11->Win32 Copy and Paste: Worked > > Xdmcp: Did Not Try Thanks for testing! Harold ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-01-12 17:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <3FFD075A.8020404@msu.edu> 2004-01-08 15:16 ` Updated: XFree86-xserv-4.3.0-33 Andrew Braverman 2004-01-08 15:20 ` Harold L Hunt II 2004-01-08 19:48 ` Andrew Braverman 2004-01-10 6:43 ` Harold L Hunt II 2004-01-12 15:25 ` XFree86-xserv-4.3.0-38 test results Andrew Braverman 2004-01-12 17:44 ` Harold L Hunt II
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).