Re: xwin -multiwindow puts glass pane over windows taskbar
On 8/31/2010 7:06 PM, Jon TURNEY wrote: On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html Sorry my description was so vague. It is indeed the same problem as in [1] (I thought maybe the other had gotten lost in the shuffle and reposted it). Basically, you know how the previous bug would make X apps unresponsive to key presses and mouse events until you did an alt-tab to "wake" them? Now I never get that any more but I get virtually the same behavior with my XP Pro non-autohide task bar, which is docked on the left side of my screen. If I mouse over systray icons, the tooltips don't appear. Mousing over the window entries doesn't make them highlight. Clicking on a window's entry or the 'start' button does nothing. It really is like something invisible sits over the whole area and intercepts all mouse events. The behavior continues for around 5 seconds or until I alt-tab some other window to foreground (whichever comes first). This doesn't always happen, and it only happens when an X window is in the foreground. Ryan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: xwin -multiwindow puts glass pane over windows taskbar
On 16/08/2010 11:57, Ryan Johnson wrote: The latest versions of the X server put a glass pane over the windows taskbar -- you have to click on it and then wait several seconds before it responds and gets out of the way. This seems related to the previous problem of generally slow response to key presses... Has anyone else run into this? I don't see any behaviour like that, and I can't really visualize what you are describing. Can you upload some screenshots somewhere? Facts which might be relevant: - do you have the taskbar set to autohide? - what version of Windows are you using? - is this the same problem as you mentioned at [1]? [1] http://cygwin.com/ml/cygwin-xfree/2010-08/msg00011.html -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin Multiwindow fails to start
Can anyone give suggestions on this problem? I'm completely stuck now, and I would really like to get it working. On Tue, Oct 23, 2007 at 01:59:54PM +0200, Nick Douma wrote: > On Mon, Oct 22, 2007 at 06:28:33PM +0200, Nick Douma wrote: > > On Mon, Oct 22, 2007 at 05:11:12PM +0200, Holger Krull wrote: > > > Nick Douma schrieb: > > > > No one who has any suggestions... ? > > > > > > Not for your main problem. Just the general idea that sometimes deleting > > > and reinstalling helps to solve strange problems. > > I'll try that tomorrow > > I have deleted my previous installation of Cygwin, and reinstalled all the > required CygwinX packages, along with > openssh, pico and svn. > > When I use the startx script, it seems to startup fine, but at the end I get > this error: > > The XKEYBOARD keymap compiler (xkbcomp) reports: > > Error:Can't find file "pc/us_intl" for symbols include > > Exiting > > Abandoning symbols file "default" > Errors from xkbcomp are not fatal to the X server > (--) 3 mouse buttons found > Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from > list! > Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing > from list! > Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from > list! > winPointerWarpCursor - Discarding first warp: 640 512 > winInitMultiWindowWM - pthread_mutex_lock () returned. > winProcEstablishConnection - Hello > winProcEstablishConnection - Clipboard is not enabled, returning. > winInitMultiWindowWM - pthread_mutex_unlock () returned. > winMultiWindowXMsgProc - pthread_mutex_lock () returned. > winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 > winMultiWindowXMsgProc - pthread_mutex_unlock () returned. > winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 > cat: /cygdrive/x/.Xauthority: No such file or directory > > winMultiWindowXMsgProcIOErrorHandler! > > 8 [unknown (0x7B8)] X 1144 _cygtls::handle_exceptions: Error while > dumping state (probably corrupted > stack) > xinit: connection to X server lost. > xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X > server ":0.0" > > Also, seemingly totally random, Xterm may or may not start up and work. But I > can't make any other programs > connect to the X server, nor can I use remote X11 forwarding to this PC. > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://x.cygwin.com/docs/ > FAQ: http://x.cygwin.com/docs/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin Multiwindow fails to start
On Mon, Oct 22, 2007 at 06:28:33PM +0200, Nick Douma wrote: > On Mon, Oct 22, 2007 at 05:11:12PM +0200, Holger Krull wrote: > > Nick Douma schrieb: > > > No one who has any suggestions... ? > > > > Not for your main problem. Just the general idea that sometimes deleting > > and reinstalling helps to solve strange problems. > I'll try that tomorrow I have deleted my previous installation of Cygwin, and reinstalled all the required CygwinX packages, along with openssh, pico and svn. When I use the startx script, it seems to startup fine, but at the end I get this error: The XKEYBOARD keymap compiler (xkbcomp) reports: > Error:Can't find file "pc/us_intl" for symbols include > Exiting > Abandoning symbols file "default" Errors from xkbcomp are not fatal to the X server (--) 3 mouse buttons found Could not init font path element /usr/X11R6/lib/X11/fonts/TTF/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/Type1/, removing from list! Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 640 512 winInitMultiWindowWM - pthread_mutex_lock () returned. winProcEstablishConnection - Hello winProcEstablishConnection - Clipboard is not enabled, returning. winInitMultiWindowWM - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - pthread_mutex_lock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winMultiWindowXMsgProc - pthread_mutex_unlock () returned. winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 cat: /cygdrive/x/.Xauthority: No such file or directory winMultiWindowXMsgProcIOErrorHandler! 8 [unknown (0x7B8)] X 1144 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) xinit: connection to X server lost. xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X server ":0.0" Also, seemingly totally random, Xterm may or may not start up and work. But I can't make any other programs connect to the X server, nor can I use remote X11 forwarding to this PC. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin Multiwindow fails to start
On Mon, Oct 22, 2007 at 05:11:12PM +0200, Holger Krull wrote: > Nick Douma schrieb: > > No one who has any suggestions... ? > > Not for your main problem. Just the general idea that sometimes deleting and > reinstalling helps to solve strange problems. I'll try that tomorrow > > > On Tue, Oct 16, 2007 at 11:38:33AM +0200, Nick Douma wrote: > >> I'm using the latest version of Cygwin, and Xwin 6.8.99.901-4. Whenever I > >> try to run X with `startx` or startx > >> scripts, it fails. If I run it directly with `X :0` it works fine (so it > >> appears), but when I run it with `X :0 > >> -multiwindow` it fails with the following log: > >> > >> Also, when I run it with the `X :0` command, the DISPLAY var is not set, > >> and xterm does not start up > >> automatically. > > That is no surprise, the DISPLAY variable doesn't set itself, you need a > script to do that. The same with the starting of xterm, if you just start the > X11 server, it will not start an xterm. Sounds logical, I guess that is one of the uses for the startx scripts > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://x.cygwin.com/docs/ > FAQ: http://x.cygwin.com/docs/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin Multiwindow fails to start
Nick Douma schrieb: > No one who has any suggestions... ? Not for your main problem. Just the general idea that sometimes deleting and reinstalling helps to solve strange problems. > On Tue, Oct 16, 2007 at 11:38:33AM +0200, Nick Douma wrote: >> I'm using the latest version of Cygwin, and Xwin 6.8.99.901-4. Whenever I >> try to run X with `startx` or startx >> scripts, it fails. If I run it directly with `X :0` it works fine (so it >> appears), but when I run it with `X :0 >> -multiwindow` it fails with the following log: >> >> Also, when I run it with the `X :0` command, the DISPLAY var is not set, and >> xterm does not start up >> automatically. That is no surprise, the DISPLAY variable doesn't set itself, you need a script to do that. The same with the starting of xterm, if you just start the X11 server, it will not start an xterm. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: XWin Multiwindow fails to start
No one who has any suggestions... ? On Tue, Oct 16, 2007 at 11:38:33AM +0200, Nick Douma wrote: > I'm using the latest version of Cygwin, and Xwin 6.8.99.901-4. Whenever I try > to run X with `startx` or startx > scripts, it fails. If I run it directly with `X :0` it works fine (so it > appears), but when I run it with `X :0 > -multiwindow` it fails with the following log: > > $ startx > > Welcome to the XWin X Server > Vendor: The Cygwin/X Project > Release: 6.8.99.901-4 > > Contact: cygwin-xfree@cygwin.com > > XWin was started with the following command line: > > X :0 -multiwindow > > (WW) /tmp mounted int textmode > _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root > winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 > (II) XF86Config is not supported > (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information > winDetectSupportedEngines - Windows NT/2000/XP > winDetectSupportedEngines - DirectDraw installed > winDetectSupportedEngines - DirectDraw4 installed > winDetectSupportedEngines - Returning, supported engines 0007 > winSetEngine - Multi Window or Rootless => ShadowGDI > winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel > winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 1024 depth: 32 > winFinishScreenInitFB - Masks: 00ff ff00 00ff > winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 > null screen fn ReparentWindow > null screen fn RestackWindow > InitQueue - Calling pthread_mutex_init > InitQueue - pthread_mutex_init returned > InitQueue - Calling pthread_cond_init > InitQueue - pthread_cond_init returned > winInitMultiWindowWM - Hello > winMultiWindowXMsgProc - Hello > winInitMultiWindowWM - Calling pthread_mutex_lock () > winMultiWindowXMsgProc - Calling pthread_mutex_lock () > 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: "00020409" (00020409) > (--) Using preset keyboard for "English (USA, International)" (20409), type > "4" > Rules = "xorg" Model = "pc105" Layout = "us_intl" Variant = "(null)" Options > = "(null)" > The XKEYBOARD keymap compiler (xkbcomp) reports: > > Error:Can't find file "pc/us_intl" for symbols include > > Exiting > > Abandoning symbols file "default" > Errors from xkbcomp are not fatal to the X server > (--) 3 mouse buttons found > Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from > list! > winPointerWarpCursor - Discarding first warp: 640 512 > winInitMultiWindowWM - pthread_mutex_lock () returned. > winProcEstablishConnection - Hello > winProcEstablishConnection - Clipboard is not enabled, returning. > winInitMultiWindowWM - pthread_mutex_unlock () returned. > winMultiWindowXMsgProc - pthread_mutex_lock () returned. > winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 > winMultiWindowXMsgProc - pthread_mutex_unlock () returned. > winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 > cat: /cygdrive/x/.Xauthority: No such file or directory > > winMultiWindowXMsgProcIOErrorHandler! > > 11 [unknown (0xB88)] X 1864 _cygtls::handle_exceptions: Error while > dumping state (probably corrupted > stack) > xinit: connection to X server lost. > > > Also, when I run it with the `X :0` command, the DISPLAY var is not set, and > xterm does not start up > automatically. > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://x.cygwin.com/docs/ > FAQ: http://x.cygwin.com/docs/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Xwin multiwindow
On Fri, 8 Apr 2005, Rahil Hussain wrote: > Hi, > > I'm trying to run Xwin, but the multiwindow option won't work. The > program just stops when it tries WinClipboardProc - Call to select(). > How can this be fixed. This happends if you have some kind of personal firewalls like ZoneAlarm or Symantac antivirus installed. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XWin -multiwindow worked once, then never again
On Fri, Mar 18, 2005 at 12:37:17PM -0800, Matthew Johnson wrote: >--- Alexander Gottwald ><[EMAIL PROTECTED]> wrote: > >[snip] >> You're running a version which is quite old. Please >> try the >> lastet xorg-x11 packages. If this was a fresh >> install, plaese >> consider using a different mirror, which is more >> up-to-date > >Hi, Alexander- > >I have had similar problems due to using mirrors that >turn out to be out of date. Can you give us a hint >concerning how to tell if a mirror is up-to-date or >not? Select the mirror from the list and it is up-to-date. If you use a mirror that you've "cached" from a previous usage it may not be up-to-date. cgf
Re: XWin -multiwindow worked once, then never again
Matthew Johnson wrote: > I have had similar problems due to using mirrors that > turn out to be out of date. Can you give us a hint > concerning how to tell if a mirror is up-to-date or > not? mirrors.kernel.org and ftp.informatik.tu-dresden.de and gwdg.de are known to be up-to-date. For others check if the latest version of xorg-x11-xwin is 6.8.2.0-1. bye ago NP: Plastic - Lies -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XWin -multiwindow worked once, then never again
--- Alexander Gottwald <[EMAIL PROTECTED]> wrote: [snip] > You're running a version which is quite old. Please > try the > lastet xorg-x11 packages. If this was a fresh > install, plaese > consider using a different mirror, which is more > up-to-date Hi, Alexander- I have had similar problems due to using mirrors that turn out to be out of date. Can you give us a hint concerning how to tell if a mirror is up-to-date or not? [snip] --- Matthew Johnson [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: XWin -multiwindow worked once, then never again
On Fri, 18 Mar 2005, Bowers, Kirk wrote: > I just installed cygwin on my laptop exactly as it is > installed on my work machine. The first time I ran > startxwin.sh, it worked, for the most part. An xterm > appeared, but the X logo in my system tray did nothing > when I right clicked on it to try to shut X down. > Since then, every time I've launched X, the X logo has > been similarly unresponsive, and no windows appear. > In my task manager, there is both an XWin and an xterm > process, but nothing displays on the screen. twm > works fine, the only problem is in mutliwindow mode. > Any ideas? Thanks in advance!! > > Here's my log: > > Welcome to the XWin X Server > Vendor: The Cygwin/X Project > Release: 6.7.0.0-10 You're running a version which is quite old. Please try the lastet xorg-x11 packages. If this was a fresh install, plaese consider using a different mirror, which is more up-to-date Anyway, those kind of errors are common for running Cygwin/X with some personal firewalls and online virus scanners. Do you have any of those installed? bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XWin -multiwindow and XEmacs/gnuclient -- cannot get autoraise
X program can't change window order in multiwindow mode. winRestackWindowMultiWindow in xc/programs/Xserver/hw/xwin/winmultiwindowwindow.c /* * Calling winReorderWindowsMultiWindow here means our window manager * (i.e. Windows Explorer) has initiative to determine Z order. */ winReorderWindowsMultiWindow (); I can't remember in detail, but someone did that to fix some problem. zakki -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Re: XWin -multiwindow and XEmacs/gnuclient -- cannot get autoraise
Alexander Gottwald s1999.tu-chemnitz.de> writes: > > Harold Bamford wrote: > > > I tried this using XWin without the builtin window manager (using twm or mwm > > as the window manager) and then autoraise seems to work. But this is not a > > good environment for me as I need constant access to both the X windows and > > the PC. > > > > I have done quite a bit of searching of the web and FAQs and manual pages and > > cannot find this even mentioned. So either it is so obvious that no-one could > > possibly need it explained, or it has just never come up. Or I used the wrong > > keywords in the searches. > > It seems this feature has not been implemented in the internal window manager. > > > So, what's the secret to getting this to work? > > There are basicly 3 possible ways > > - wait until someone has the time to dig up documentation how the autoraise > should work and fixes that bug > > - dig up the documentation yourself and report which window manager message > should be handled > > - fix it yourself > > The fastest is most likely number two. > > bye > ago Thanks. Unfortunately, it would take me a great deal of time to learn enough about the internals of window managers that I could make a coherent report. I guess I'll just live with the problem for now. I was hoping that this was a known problem with a known solution. Thanks anyway! -- Harold
Re: XWin -multiwindow and XEmacs/gnuclient -- cannot get autoraise
Harold Bamford wrote: > I tried this using XWin without the builtin window manager (using twm or mwm > as the window manager) and then autoraise seems to work. But this is not a > good environment for me as I need constant access to both the X windows and > the PC. > > I have done quite a bit of searching of the web and FAQs and manual pages and > cannot find this even mentioned. So either it is so obvious that no-one could > possibly need it explained, or it has just never come up. Or I used the wrong > keywords in the searches. It seems this feature has not been implemented in the internal window manager. > So, what's the secret to getting this to work? There are basicly 3 possible ways - wait until someone has the time to dig up documentation how the autoraise should work and fixes that bug - dig up the documentation yourself and report which window manager message should be handled - fix it yourself The fastest is most likely number two. bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: xwin -multiwindow bug [ver 1.5.10(0.116/4/2)?]
On Wed, 11 Aug 2004, Ariel Millennium Thornton wrote: > Hello. I think I have found a bug in Cygwin/X. > > When running xwin.exe with the -multiwindow switch (to use winxp's gdi > as X's wm), the X-managed regions of the screen do some rather strange > things. > > When the root window is shown, all of the X windows behave as they > should, with the root window having the proper dimensions and offset > from the upper-left corner of the screen. However, when the root window > is hidden, X refuses to draw any regions of any window it thinks are > outside the bounds of the root window, drawing white blocks instead. > > The bug is that when the root window is hidden, X thinks that the offset > of the root window is (0,0), flush with the upper-left corner of the > screen, regardless of what the desktop bounds (the extent of maximized > windows) really are. > > This behavior doesn't manifest itself on factory-installed Windows XP > systems, but it does manifest when the system is customized, especially > if the taskbar is moved to other edges of the screen, or when another > shell (such as LiteStep) is used in lieu of the default Internet > Explorer/Windows Explorer shell. I've not used LiteStep before. XWin queries the system about the screen size and the size and location of the task bar. You can check the logfile /tmp/XWin.log and it should print a line with the visual size (maybe you have to specify -logverbose 3 or higher to see this line). you can specify the size itself with the -screen parameter (eg -screen 0 800x600) bye ago -- [EMAIL PROTECTED] http://www.gotti.org ICQ: 126018723
Re: XWin -multiwindow menu problem (Was: XWinrc bugs)
I've had some problems with XWin as well, here's what I get: [EMAIL PROTECTED] ~ $ export DISPLAY=:0 [EMAIL PROTECTED] ~ $ Xwin -multiwindow -clipboard & [1] 2068 [EMAIL PROTECTED] ~ $ Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 6.7.0.0-4 Contact: [EMAIL PROTECTED] XWin was started with the following command line: Xwin -multiwindow -clipboard OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winValidateArgs - Returning. (II) XF86Config is not supported (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Multi Window or Rootless => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1280 h: 1024 winCreateBoundingWindowWindowed - Current w: 1280 h: 1024 winAdjustForAutoHide - Original WorkArea: 0 0 996 1280 winAdjustForAutoHide - Adjusted WorkArea: 0 0 996 1280 winCreateBoundingWindowWindowed - WindowClient w 1280 h 996 r 1280 l 0 b 996 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1280 height: 996 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1280 height: 996 depth: 32 size image : 5099520 winAllocateFBShadowGDI - Created shadow stride: 1280 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () 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 winInitMultiWindowWM - Hello winMultiWindowXMsgProc - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Calling pthread_mutex_lock () winScreenInit - returning InitOutput - Returning. MIT-SHM extension disabled due to lack of kernel support XFree86-Bigfont extension local-client optimization disabled due to lack of shar ed memory support in the kernel (--) Setting autorepeat to delay=500, rate=31 (--) winConfigKeyboard - Layout: "0409" (0409) (EE) Keyboardlayout "US" (0409) is unknown Rules = "xorg" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null )" Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from li st! winPointerWarpCursor - Discarding first warp: 640 498 winBlockHandler - Releasing pmServerStarted winInitMultiWindowWM - pthread_mutex_lock () returned. winBlockHandler - pthread_mutex_unlock () 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 winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the disp lay. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the di splay. winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winProcSetSelectionOwner - Clipboard not yet started, aborting. winProcSetSelectionOwner - Clipboard not yet started, aborting. then it locks up... Rodrigo Medina wrote: Hi Earle, At Sun, 18 Apr 2004 22:35:12 -0700 Earle F. Philhower, III wrote: That's good troubleshooting, a patch that works around the W95 bug was committed to CVS. (Are you able to run the latest cygwin DLLs under W95 still? When I was running cygwin w/W95A+IE5.5sp2 under bochs I got nothing but bluescreens in cygwin1.dll...) I have been working with cygwin/X under Win95 for more than 2 years without too much problem. Lately, from cygwin1 1.5.6 up to 1.5.9 there was a bug with threads that crashed XWin -multiwindow. This problem was solved in the more recent snapshots. As I understand that there are difficulties to check the new software in Win95, I have decided to try all new snapshots and versions of XWin as soon as possible. bye Rodrigo Medina
RE: XWin -multiwindow menu problem (Was: XWinrc bugs)
Hi Earle, At Sun, 18 Apr 2004 22:35:12 -0700 Earle F. Philhower, III wrote: >That's good troubleshooting, a patch that works around the W95 bug >was committed to CVS. (Are you able to run the latest cygwin DLLs >under W95 still? When I was running cygwin w/W95A+IE5.5sp2 under >bochs I got nothing but bluescreens in cygwin1.dll...) I have been working with cygwin/X under Win95 for more than 2 years without too much problem. Lately, from cygwin1 1.5.6 up to 1.5.9 there was a bug with threads that crashed XWin -multiwindow. This problem was solved in the more recent snapshots. As I understand that there are difficulties to check the new software in Win95, I have decided to try all new snapshots and versions of XWin as soon as possible. bye Rodrigo Medina
Re: XWin -multiwindow menu problem (Was: XWinrc Bugs)
Hi Rodrigo, At 02:02 PM 4/17/2004 -0400, Rodrigo Medina wrote: The problems with XWinrc seem to be gone. Remains the problem with the 3 items menus, that I previously attributed to the XWinrc feature, but I now think it is a "XWin -multiwindow" problem. To remember the problem: All windows produce by "XWin -multiwindow" have a 3-items (Move, Size and Close) instead of the Windows standard 6-items menus. What the XWinrc feature has to do with this problem is that the XWinrc RELOAD command cures the windows previously produced by "XWin -multiwindow". XFree86 versions of XWin did not have this problem. That's good troubleshooting, a patch that works around the W95 bug was committed to CVS. (Are you able to run the latest cygwin DLLs under W95 still? When I was running cygwin w/W95A+IE5.5sp2 under bochs I got nothing but bluescreens in cygwin1.dll...) -Earle F. Philhower, III [EMAIL PROTECTED] cdrlabel - ZipLabel - FlpLabel http://www.cdrlabel.com
Re: XWin -multiwindow crashes.
Rodrigo Medina (myself) wrote: >After upgrading, "XWin -multiwindow &" immediately crashes. >Windows 95 reports page fault in cygwin1.dll. >Relevant information is in attachments. >Without the multiwindow option it is OK. Before upgrading I had cygwin-1.5.5-1 and XFree86-xserv-4.3.0-30 after I had cygwin-1.5.7-1 and XFree86-xserv-4.3.0-44. Actually it is not the new version of XWin but the new cygwin the origin of the problem. XWin-4.3.0-30 and XWin-4.3.0-44 are both OK with cygwin-1.5.5-1 and both crash with cygwin-1.5.7-1 Rodrigo Medina
Re: XWin - multiwindow problem
Harold, I finally got a break from 'real' work to pursue this problem. I got the latest ATI drivers (dated 2001) and DirectX 9 installed, but still no luck with running XWin -multiwindow. There are no MS drivers for the card in Win98. I got some additional display depths and tried them too. The log is the same as below. Any more hints? I'm running the application o.k. not multiwindow, but it's tough training a windoze user to operate an xterm and twm. Thanks, terry Harold wrote: In this case I think you need to try to install the drivers directly from your video card manufacturer on the non-working system and see if that helps. On the other hand, if the manufacturer drivers are installed on the system that does not work while the other has the default MS drivers, then the manufacturer drivers might be the problem. Note that "non-multiwindow" mode on both computers will use DirectDraw, which has its own seperate driver, while "multiwindow" mode on both computers will use the GDI drivers. These drivers are distinct, so problems with one won't necessarily cause problems with the other. Oddly enough, upgrading to DX 9.x might install some fresh drivers that could fix your problem. Give those things a try and let us know what happens. Harold terry wrote: Harold, Thanks - I get the same log output using 16 and 8 bit. I don't have other choices with the driver I'm using. Both systems have ATI graphics cards of type Rage 128. The working system has a specific monitor (Hitachi 751), while the non-working one is using Plug-and-Pray with a NEC 77F. If you think it's worthwhile I can play with the 98 configuration. Terry --- Harold wrote: Try changing the display depth on the problem machine from 32 bits to 24, 16, or 15 bits. In fact, try each one of those depths if the first one you try doesn't work. Report your results to the mailing list please. Harold terry wrote: > I have successfully setup a Win98se system with CygWin using startxwin.bat from a download a couple of weeks ago (Perhaps if it had been difficult, I would know better how to deal with this problem :>) ). > > I am attempting to do the same on another system with almost identical hardware, also using Win98se. The significant difference between the systems is that the successful system has a 19" monitor @1600x1200 while the problem system has a 17" monitor @1024x768. I have not modified startxwin.bat, and everything works fine 'non-multiwindow'. I cannot determine how to deal with the error in the XWin log below. Many thanks for any help. > > terry > > > ddxProcessArgument - Initializing default screens > winInitializeDefaultScreens - w 1024 h 768 > winInitializeDefaultScreens - Returning > OsVendorInit - Creating bogus screen 0 > (EE) Unable to locate/open config file > InitOutput - Error reading config file > winDetectSupportedEngines - Windows 95/98/Me > winDetectSupportedEngines - DirectDraw installed > winDetectSupportedEngines - DirectDraw4 installed > winDetectSupportedEngines - Returning, supported engines 0017 > InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 > winSetEngine - Multi Window => ShadowGDI > winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel > winCreateBoundingWindowWindowed - User w: 1024 h: 768 > winCreateBoundingWindowWindowed - Current w: 1024 h: 768 > winAdjustForAutoHide - Original WorkArea: 0 0 768 1024 > winAdjustForAutoHide - Taskbar is auto hide > winAdjustForAutoHide - Found LEFT auto-hide taskbar > winAdjustForAutoHide - Adjusted WorkArea: 0 1 768 1024 > winCreateBoundingWindowWindowed - WindowClient w 1023 h 768 r 1023 l 0 b 768 t 0 > winCreateBoundingWindowWindowed - Returning > winAllocateFBShadowGDI - Creating DIB with width: 1023 height: 768 depth: 32 > winAllocateFBShadowGDI - Dibsection width: 1023 height: -768 depth: 32 size image: 3142656 > winAllocateFBShadowGDI - Shadow blit failure > winFinishScreenInitFB - Could not allocate framebuffer > winScreenInit - winFinishScreenInit () failed > > Fatal server error: > InitOutput - Couldn't add screen 0
RE: RE XWin multiwindow clipboard
Raymond, Okay, so it still crashes. For future reference, I can guarantee that -clipboard will not work if you are passing -nolisten tcp. So, once the crash is fixed, don't start using that flag again :) Thanks for testing, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Raymond Kwong Sent: Wednesday, January 29, 2003 1:38 AM To: [EMAIL PROTECTED] Subject: RE XWin multiwindow clipboard Harold: I guess curosity got me going to try your suggestions on my laptop. The bottom line is: the X server still crashed. I used Test 76 this time. The script is: ___ @echo off REM SET DISPLAY=:0.0 SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\b in;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. start XWin -multiwindow -clipboard REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white -title xterm -e bash REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 __ Here is the XWinrl.log file: _ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (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 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 740 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 740 r 1024 l 0 b 740 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 740 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1024 height: 740 depth: 16 size image: 1515520 winAllocateFBShadowGDI - Created shadow stride: 1024 winFinishScreenInitFB - Masks: f800 07e0 001f
RE: Re XWin multiwindow clipboard
Yeah, that may be, but does startx pass -nolisten tcp? My point in mentioning that DISPLAY was also modified was that the user had made rather significant modifications to their startxwin.bat, which they had neglected to tell us. Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sylvain Petreolle Sent: Wednesday, January 29, 2003 7:19 AM To: [EMAIL PROTECTED] Subject: RE: Re XWin multiwindow clipboard Harold, If you use 'startx' to start your XWindow, the default display is set to :0.0. And I run startx -- -clipboard -multiwindow without problem. > Both the Clipboard Manager and the MultiWindow Window Manager try to > connect > to the local server via TCP/IP on 127.0.0.1:display.screen > > One of my messages from a few days back says that we were changing > from > connecting to (essentially) :0.0 to (essentially) 127.0.0.1:0.0. = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
RE: Re XWin multiwindow clipboard
Harold, If you use 'startx' to start your XWindow, the default display is set to :0.0. And I run startx -- -clipboard -multiwindow without problem. > Both the Clipboard Manager and the MultiWindow Window Manager try to > connect > to the local server via TCP/IP on 127.0.0.1:display.screen > > One of my messages from a few days back says that we were changing > from > connecting to (essentially) :0.0 to (essentially) 127.0.0.1:0.0. = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
RE XWin multiwindow clipboard
Harold: I guess curosity got me going to try your suggestions on my laptop. The bottom line is: the X server still crashed. I used Test 76 this time. The script is: ___ @echo off REM SET DISPLAY=:0.0 SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\bin;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. start XWin -multiwindow -clipboard REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white -title xterm -e bash REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 __ Here is the XWinrl.log file: _ ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 (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 001f InitOutput - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 16 bits per pixel winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1024 h: 768 winAdjustForAutoHide - Original WorkArea: 0 0 740 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024 winCreateBoundingWindowWindowed - WindowClient w 1024 h 740 r 1024 l 0 b 740 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1024 height: 740 depth: 16 winAllocateFBShadowGDI - Dibsection width: 1024 height: 740 depth: 16 size image: 1515520 winAllocateFBShadowGDI - Created shadow stride: 1024 winFinishScreenInitFB - Masks: f800 07e0 001f winInitVisualsShadowGDI - Masks f800 07e0 001f 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 - Calling winInitClipboard. winInitClipboard () winFinishScreenInitFB - returning winScre
RE Xwin multiwindow clipboard
Harold: While the script I sent contained -nolisten tcp, I had deleted it before and it did not make any difference: X still crashed. However, I have to say that I have had my DISPLAY variable set to :0.0 in place of 127.0.0.1:0.0 for quite some time. If that can cause a problem, I can test without -nolisten tcp and DISPLAY=127.0.0.1:0.0. I'll send you the log file. To be consistent, I'll have to test on the office machine, which is the one I have used earlier. Raymond
RE: Re XWin multiwindow clipboard
Raymond, Well, your straightforward modification of startxwin.bat includes two modifications that are neither straightforward nor allowed. You changed DISPLAY=127.0.0.0:0.0 to DISPLAY=:0.0 and you told XWin.exe -nolisten tcp. That is not a small change! Both the Clipboard Manager and the MultiWindow Window Manager try to connect to the local server via TCP/IP on 127.0.0.1:display.screen One of my messages from a few days back says that we were changing from connecting to (essentially) :0.0 to (essentially) 127.0.0.1:0.0. We did that because UNIX domain sockets did not seem to be working correctly for some users. Thus, you are going to have to drop the "-nolisten tcp". You can keep DISPLAY=:0.0, but you have to get rid of "-nolisten tcp". You can watch the mailing list to see if we ever change the CM and MWWM back to connecting to :0.0. That's all for now, Harold -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Raymond Kwong Sent: Tuesday, January 28, 2003 11:43 PM To: [EMAIL PROTECTED] Subject: Re XWin multiwindow clipboard Harold: I normally don't have xwinclip in my startup script. I just start it manually if I need it. In any case, here is the startup script, a straightforward modification of startxwin.bat: @echo off SET DISPLAY=:0.0 REM SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\b in;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. REM start XWin -multiwindow -clipboard start XWin -multiwindow -nolisten tcp REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 By the way, I am using Windows 2000, cygwin 1.3.19-1. Raymond
Re XWin multiwindow clipboard
Harold: I normally don't have xwinclip in my startup script. I just start it manually if I need it. In any case, here is the startup script, a straightforward modification of startxwin.bat: @echo off SET DISPLAY=:0.0 REM SET DISPLAY=127.0.0.1:0.0 REM REM The path in the CYGWIN_ROOT environment variable assignment assume REM that Cygwin is installed in a directory called 'cygwin' in the root REM directory of the current drive. You will only need to modify REM CYGWIN_ROOT if you have installed Cygwin in another directory. For REM example, if you installed Cygwin in \foo\bar\baz\cygwin, you will need REM to change \cygwin to \foo\bar\baz\cygwin. REM REM This batch file will almost always be run from the same drive (and REM directory) as the drive that contains Cygwin/XFree86, therefore you will REM not need to add a drive letter to CYGWIN_ROOT. For example, you do REM not need to change \cygwin to c:\cygwin if you are running this REM batch file from the C drive. REM SET CYGWIN_ROOT=\cygwin SET PATH=%CYGWIN_ROOT%\bin;%CYGWIN_ROOT%\usr\X11R6\bin;%CYGWIN_ROOT%\usr\local\bin;%PATH% REM REM Cleanup after last run. REM if not exist %CYGWIN_ROOT%\tmp\.X11-unix\X0 goto CLEANUP-FINISH attrib -s %CYGWIN_ROOT%\tmp\.X11-unix\X0 del %CYGWIN_ROOT%\tmp\.X11-unix\X0 :CLEANUP-FINISH if exist %CYGWIN_ROOT%\tmp\.X11-unix rmdir %CYGWIN_ROOT%\tmp\.X11-unix REM REM Startup the X Server, the twm window manager, and an xterm. REM REM Notice that the window manager and the xterm will wait for REM the server to finish starting before trying to connect; the REM error "Cannot Open Display: 127.0.0.1:0.0" is not due to the REM clients attempting to connect before the server has started, rather REM that error is due to a bug in some versions of cygwin1.dll. Upgrade REM to the latest cygwin1.dll if you get the "Cannot Open Display" error. REM See the Cygwin/XFree86 FAQ for more information: REM http://xfree86.cygwin.com/docs/faq/ REM REM The error "Fatal server error: could not open default font 'fixed'" is REM caused by using a DOS mode mount for the mount that the Cygwin/XFree86 REM fonts are accessed through. See the Cygwin/XFree86 FAQ for more REM information: REM http://xfree86.cygwin.com/docs/faq/cygwin-xfree-faq.html#q-error-font-eof REM if "%OS%" == "Windows_NT" goto OS_NT REM Windows 95/98/Me echo startxwin.bat - Starting on Windows 95/98/Me goto STARTUP :OS_NT REM Windows NT/2000/XP echo startxwin.bat - Starting on Windows NT/2000/XP :STARTUP REM REM Startup the programs REM REM Startup the X Server. REM start XWin -multiwindow -clipboard start XWin -multiwindow -nolisten tcp REM Startup an xterm, using bash as the shell. run xterm -sl 1024 -sb -font 9x15 -fg black -bg white REM run xterm -sl 1000 -sb -rightbar -ms red -fg yellow -bg black -e /usr/bin/bash REM Startup the twm window manager. REM run twm REM run openbox REM Set a background color. run xsetroot -solid aquamarine4 By the way, I am using Windows 2000, cygwin 1.3.19-1. Raymond
RE: XWin multiwindow clipboard
I haven't been using a script. Just running 'XWin.exe -clipboard -multiwindow' directly from the command line causes XWin to crash on startup. anders -Original Message- From: Harold L Hunt II [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 2:42 PM To: [EMAIL PROTECTED] Subject: Re: XWin multiwindow clipboard Raymond, What we really need to see is the script file that you used to start XWin.exe, such as startxwin.bat, startxwin.sh, etc. You see, 99% of users seem to be missing the point that you have to remove xwinclip from your startup script if you intend to use the new -clipboard option. So, we would like to verify that the startup script you are using doesn't have any problems. Thanks, Harold
Re: XWin multiwindow clipboard
Raymond, What we really need to see is the script file that you used to start XWin.exe, such as startxwin.bat, startxwin.sh, etc. You see, 99% of users seem to be missing the point that you have to remove xwinclip from your startup script if you intend to use the new -clipboard option. So, we would like to verify that the startup script you are using doesn't have any problems. Thanks, Harold
