Re: Crash when remote desktop changes screen resolutions
Here is another example log file showing this crash: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.66 Contact: [EMAIL PROTECTED] XWin was started with the following command line: /usr/X11R6/bin/XWin -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - 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 1274 h 971 r 1274 l 0 b 971 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 5096 winAllocateFBShadowDDNL - Created shadow pitch: 5096 winAllocateFBShadowDDNL - Created shadow stride: 1274 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning 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 shared memory support in the kernel (--) Setting autorepeat to delay=250, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 Rules = xfree86 Model = pc105 Layout = gb Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 637 485 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 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. winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 8 winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 720 winWindowProc - Disruptive change in depth winDisplayDepthChangeDialog - DialogBox returned: 1840476 winDisplayDepthChangeDialog - GetLastError: 6 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Detached clipper winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e winChangeDelthDlgProc - wParam == s_pScreenInfo-dwBPP winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 8, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e --
Re: Updated: xorg-x11-[base,bin,bin-dlls,bin-lndir,devel,etc,f100,fcyr,fenc,fnts,fscl,fsrv,libs-data,man-pages,man-pages-html,nest,vfb,xwin]-6.7.0.0-1
Harold L Hunt, writes: The following packages have been updated in the Cygwin distribution: *** xorg-x11-base-6.7.0.0-1 *** xorg-x11-bin-6.7.0.0-1 *** xorg-x11-bin-dlls-6.7.0.0-1 *** xorg-x11-bin-lndir-6.7.0.0-1 *** xorg-x11-devel-6.7.0.0-1 *** xorg-x11-etc-6.7.0.0-1 *** xorg-x11-f100-6.7.0.0-1 *** xorg-x11-fcyr-6.7.0.0-1 *** xorg-x11-fenc-6.7.0.0-1 *** xorg-x11-fnts-6.7.0.0-1 *** xorg-x11-fscl-6.7.0.0-1 *** xorg-x11-fsrv-6.7.0.0-1 *** xorg-x11-libs-data-6.7.0.0-1 *** xorg-x11-man-pages-6.7.0.0-1 *** xorg-x11-man-pages-html-6.7.0.0-1 *** xorg-x11-nest-6.7.0.0-1 *** xorg-x11-vfb-6.7.0.0-1 *** xorg-x11-xwin-6.7.0.0-1 * xorg-x11-libs-data-6.7.0.0-1 and xorg-x11-devel-6.7.0.0-1 have both the /usr/X11R6/lib/X11/config directory with all the files inside * lndir is in xorg-x11-bin-6.7.0.0-1 and xorg-x11-bin-lndir-6.7.0.0-1 Ciao Volker
XWin.log
Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.67 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X -query 192.168.0.3 ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1024 h 768 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winCheckDisplayNumber - Cygwin/X is already running on display 0 Fatal server error: InitOutput - Duplicate invocation on display number: 0. Exiting. winDeinitMultiWindowWM - Noting shutdown in progress ddxBeforeReset - Hello winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1018 dwHeight: 715 winSetEngine - Using Shadow DirectDraw NonLocking winCreateBoundingWindowWindowed - User w: 1024 h: 768 winCreateBoundingWindowWindowed - Current w: 1018 h: 715 winAdjustForAutoHide - Original WorkArea: 0 0 740 1024 winAdjustForAutoHide - Adjusted WorkArea: 0 0 740 1024 winCreateBoundingWindowWindowed - WindowClient w 1018 h 715 r 1018 l 0 b 715 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 4072 winAllocateFBShadowDDNL - Created shadow pitch: 4072 winAllocateFBShadowDDNL - Created shadow stride: 1018 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning 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 shared memory support in the kernel (--) Setting autorepeat to delay=500, rate=31
Re: Crash when remote desktop changes screen resolutions
Pass -engine 1 to XWin.exe and see what happens. Harold Ed Avis wrote: Here is another example log file showing this crash: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.66 Contact: [EMAIL PROTECTED] XWin was started with the following command line: /usr/X11R6/bin/XWin -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1280 h 1024 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1280 dwHeight: 1024 winSetEngine - Using Shadow DirectDraw NonLocking winAdjustVideoModeShadowDDNL - 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 1274 h 971 r 1274 l 0 b 971 t 0 winCreateBoundingWindowWindowed - Returning winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Created primary surface winCreatePrimarySurfaceShadowDDNL - Attached clipper to primary surface winAllocateFBShadowDDNL - lPitch: 5096 winAllocateFBShadowDDNL - Created shadow pitch: 5096 winAllocateFBShadowDDNL - Created shadow stride: 1274 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowDDNL - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winRandRInit () winCreateDefColormap - Deferring to fbCreateDefColormap () winFinishScreenInitFB - returning 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 shared memory support in the kernel (--) Setting autorepeat to delay=250, rate=31 (--) winConfigKeyboard - Layout: 0809 (0809) (--) Using preset keyboard for English (United Kingdom) (809), type 4 Rules = xfree86 Model = pc105 Layout = gb Variant = (null) Options = (null) Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! winPointerWarpCursor - Discarding first warp: 637 485 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned winProcEstablishConnection - Hello winInitClipboard () winProcEstablishConnection - winInitClipboard returned. winClipboardProc - Hello DetectUnicodeSupport - Windows NT/2000/XP winClipboardProc - DISPLAY=127.0.0.1:0.0 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. winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt () failed: 887601c2 winShadowUpdateDDNL - IDirectDrawSurface4_Blt failure message maximum (10) reached. No more failure messages will be printed. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winClipboardFlushXEvents - SelectionNotify - X*TextPropertyToTextList list_return is NULL. winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 8 winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 720 winWindowProc - Disruptive change in depth winDisplayDepthChangeDialog - DialogBox returned: 1840476 winDisplayDepthChangeDialog - GetLastError: 6 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Detached clipper winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface winCreatePrimarySurfaceShadowDDNL - Could not create primary surface: 8876024e winChangeDelthDlgProc - wParam == s_pScreenInfo-dwBPP winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 8, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winReleasePrimarySurfaceShadowDDNL - Hello winReleasePrimarySurfaceShadowDDNL - Released primary surface winCreatePrimarySurfaceShadowDDNL - Creating primary surface
Re: XWin.log
winCheckDisplayNumber - Cygwin/X is already running on display 0 Fatal server error: InitOutput - Duplicate invocation on display number: 0. Exiting. winDeinitMultiWindowWM - Noting shutdown in progress You can't launch two instances on the same display number. Harold
execv
Hi! I cannot find any reference to a problem with this in the Cygwin docs. Is there a display problem for Xapp2 when instigated using a execv call from an X-app compiled in cygwin? Actually it is a three app connection, App1 - A fork function - App2 The requirement being to allow App1 to be used as if app2 did not exist. example IN app1 : system(fork_func app2); . Fork_func : // this (should) start a function as an independent process from the orphaned parent allowing it to progress as normal. While the fork_func dies. main(rgc,argv) .. execv(argv[1],args); ... All standard stuff. As usual this is code that is operational elsewhere. In addition if the second X-apps has been compiled using Interix and not cygwin it is also OK. From monitoring I can see the second app stops as it attempts to display. It passs through all of the screen build and even the XtRealizeWidget and stops on entry to the XtAppMainLoop. If the execv is replaced by a simple system call, system(app2); then app2 is displayed OK but at the expense of pausing the calling process.. Obviously the second app is 100% ok when not called from the prompt.. Although the App2 finds the appcontext etc and all seems well during the build process when it comes to really display the graphics it slips into a close down. and terminates. Any input gratefully received.
Start script changes
Harold, Since /usr/X11R6 is apparently an abomination, you'll have no qualms about moving run.exe into /usr/bin (alias /bin), right? ;-) You can say yes now and skip to the last two paragraphs, it's mostly justification for the change. However, if you need more convincing... I've got a startxwin.bat that makes the same assumption about the location of /bin as cygwin.bat i.e. it (more or less) tries to do the following: C: chdir \cygwin\bin set CYGWIN=tty bash -lc /usr/X11R6/bin/startxwin.sh This works. If I run this from a shortcut, I can make it start minimised so that the DOS box is hidden, but I'd prefer to get rid of it entirely once X has started. The problem is that, even though startxwin.sh runs xterm as a background process and then bash exits, the DOS box doesn't close until the last client (i.e. xterm) has died. One solution is: insist that ALL background processes be started using run.exe rather than just putting them in the background. I've rejected this because it is unreasonable to force shell script writers to be aware of the foibles of DOS - we want to leave behind all DOS baggage in the .bat file :-) Another solution: use run.exe to start bash. I don't think we can assume ANY of the cygwin directories are in %PATH%, so the bash line becomes: C:\cygwin\usr\X11R6\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh This is useless for me, because /usr is on my D: drive and as one of the prime motivations for making the change is to make the scripts more universal, this too has to be rejected. If instead, we chdir to the (DOS) location of /usr/X11R6/bin, e.g. in my case D:\cygwin\usr\X11R6\bin, we can't guarantee that bash will start OK (it won't find cygwin1.dll for starters). Therefore, the cleanest solution would be to move run.exe to /usr/bin. Then, the startxwin.bat can just: run bash -lc /usr/X11R6/bin/startxwin.sh Any shortcut to run the .bat file just needs the target to be the batch file itself, there's no need to be careful about setting its starting directory. It could hardly be simpler. In case you're wondering, startxdmcp.bat is virtually the same except it sets REMOTE_HOST then runs bash as: run bash -lc /usr/X11R6/bin/startxwin.sh -xdmcp %REMOTE_HOST% The XDMCP specific bits in startxdmcp.bat have migrated into startxwin.sh. If you're OK with run.exe moving into /usr/bin, I should be able to get a patch out tomorrow. It might be worth pointing out that with run.exe in /bin, the batch files are pretty redundant. I've got a shortcut with a target of: C:\cygwin\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh which runs fine so long as Start in: is C:\cygwin\bin. Perhaps you could clarify: if run.exe moves to /usr/bin, should this be referred to (in the xxx.in files) as /usr/bin, /bin or @some_autoconf_macro@? @prefix@ appears to be /usr/X11R6, and the other autoconf directories seem to be derived from this e.g. @exec_prefix@ and @bindir@, so none of them seem to be applicable. Longer term, wouldn't it make more sense to persuade Charles Wilson (the cygutils maintainer) to adopt run.exe as an addition to the cygutils family? There is nothing X about it after all, and it would also make it available to other folk that aren't interested in X (there must be some out there ;-). It may need a name change to cygrun, but that's not going to hurt. Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Re: Start script changes
Actually, I would suggest moving *all* of the X stuff into /usr/bin (or, rather, /bin), and mounting /bin on /usr/X11R6/bin to keep the broken apps and old scripts happy. Igor On Wed, 7 Apr 2004, Phil Betts wrote: Harold, Since /usr/X11R6 is apparently an abomination, you'll have no qualms about moving run.exe into /usr/bin (alias /bin), right? ;-) You can say yes now and skip to the last two paragraphs, it's mostly justification for the change. However, if you need more convincing... I've got a startxwin.bat that makes the same assumption about the location of /bin as cygwin.bat i.e. it (more or less) tries to do the following: C: chdir \cygwin\bin set CYGWIN=tty bash -lc /usr/X11R6/bin/startxwin.sh This works. If I run this from a shortcut, I can make it start minimised so that the DOS box is hidden, but I'd prefer to get rid of it entirely once X has started. The problem is that, even though startxwin.sh runs xterm as a background process and then bash exits, the DOS box doesn't close until the last client (i.e. xterm) has died. One solution is: insist that ALL background processes be started using run.exe rather than just putting them in the background. I've rejected this because it is unreasonable to force shell script writers to be aware of the foibles of DOS - we want to leave behind all DOS baggage in the .bat file :-) Another solution: use run.exe to start bash. I don't think we can assume ANY of the cygwin directories are in %PATH%, so the bash line becomes: C:\cygwin\usr\X11R6\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh This is useless for me, because /usr is on my D: drive and as one of the prime motivations for making the change is to make the scripts more universal, this too has to be rejected. If instead, we chdir to the (DOS) location of /usr/X11R6/bin, e.g. in my case D:\cygwin\usr\X11R6\bin, we can't guarantee that bash will start OK (it won't find cygwin1.dll for starters). Therefore, the cleanest solution would be to move run.exe to /usr/bin. Then, the startxwin.bat can just: run bash -lc /usr/X11R6/bin/startxwin.sh Any shortcut to run the .bat file just needs the target to be the batch file itself, there's no need to be careful about setting its starting directory. It could hardly be simpler. In case you're wondering, startxdmcp.bat is virtually the same except it sets REMOTE_HOST then runs bash as: run bash -lc /usr/X11R6/bin/startxwin.sh -xdmcp %REMOTE_HOST% The XDMCP specific bits in startxdmcp.bat have migrated into startxwin.sh. If you're OK with run.exe moving into /usr/bin, I should be able to get a patch out tomorrow. It might be worth pointing out that with run.exe in /bin, the batch files are pretty redundant. I've got a shortcut with a target of: C:\cygwin\bin\run.exe bash -lc /usr/X11R6/bin/startxwin.sh which runs fine so long as Start in: is C:\cygwin\bin. Perhaps you could clarify: if run.exe moves to /usr/bin, should this be referred to (in the xxx.in files) as /usr/bin, /bin or @some_autoconf_macro@? @prefix@ appears to be /usr/X11R6, and the other autoconf directories seem to be derived from this e.g. @exec_prefix@ and @bindir@, so none of them seem to be applicable. Longer term, wouldn't it make more sense to persuade Charles Wilson (the cygutils maintainer) to adopt run.exe as an addition to the cygutils family? There is nothing X about it after all, and it would also make it available to other folk that aren't interested in X (there must be some out there ;-). It may need a name change to cygrun, but that's not going to hurt. Phil -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! I have since come to realize that being between your mentor and his route to the bathroom is a major career booster. -- Patrick Naughton
auto-hiding taskbar causes refresh problems
Hi folks, To recreate this small bug: 1) Disable taskbar auto-hiding 2) Start X in multiwindow mode 3) Enable taskbar auto-hiding Now, nothing is rendered into the area where the taskbar used to be. Previously rendered areas can be dragged into the taskbar zone without being erased, but if they become obscured, they will not be refreshed on exposure. I can't imagine this affecting too many people, I only found it because I needed to temporarily disable auto-hiding while I was testing the various options for starting X, so there's no rush. FYI, this is on NT4, server release: 4.3.0.65 Phil ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **
Emacs on Linux crashes in XQueryPointer
I've got a Debian Sid box running XFree86 (debian package 4.3.0-7). If I pipe emacs -q from it (emacs 21.3 or CVS, doesn't matter) to my WinXP box running XWin 6.7.0.0-1, click the window to get rid of the Emacs intro screen, and select text right to left, Emacs crashes with X protocol error: BadWindow (invalid Window parameter) on protocol request 38 Backtrace shows that this is occuring in XQueryPointer, called from various points in Emacs. I can reproduce this every time. Running Emacs in synchronous mode shows the same results. This does not happen running Emacs to the local Linux X server. This also does not show up with the Cygwin packaged Emacs 21.2. Any ideas on what's causing this, or how I could help narrow it down some more? This makes Emacs extremely unstable displaying on Cygwin/X for me, since I have to try to avoid using the mouse at all, or else I might crash Emacs. -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. My computer's getting jealous of the time I spend with my wife.
Re: Emacs on Linux crashes in XQueryPointer
Harold L Hunt II [EMAIL PROTECTED] writes: I assume pipe means ssh tunnel. If so, see A1 in this FAQ entry: http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Thank you, that did it. I'm sorry I missed it in the FAQ. -- Alan Shutko [EMAIL PROTECTED] - I am the rocks. To do is to be.
Window Movement after display settings change
In the latest release I have the following problem (after changing display settings): - Open any x app (eg nedit, xterm) - Move the window Then updates are only applied to the rect where the window used to be, and the mouse will not move into the new area (into which it has moved). Anyone else getting this? Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.67 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multimonitors -multiwindow -clipboard -nodecoration ... winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 768 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 768 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1024 new height: 768 winWindowProc - WM_DISPLAYCHANGE - orig bpp: 32, last bpp: 32, new bpp: 32 winWindowProc - WM_DISPLAYCHANGE - new width: 1280 new height: 1024 winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter) winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter) winMultiWindowXMsgProcErrorHandler - ERROR: BadWindow (invalid Window parameter)
Re: Window Movement after display settings change
Ben Jackson wrote: In the latest release I have the following problem (after changing display settings): - Open any x app (eg nedit, xterm) - Move the window Then updates are only applied to the rect where the window used to be, and the mouse will not move into the new area (into which it has moved). Anyone else getting this? Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.67 Contact: [EMAIL PROTECTED] XWin was started with the following command line: XWin -multimonitors -multiwindow -clipboard -nodecoration How is this even working? You aren't supposed to be able to use -nodecoration and -multiwindow together and you should not. I swear I checked for this combination in my command-line argument validation that I added sometime last month... Harold
MMS Notification
This is NOT an error, this is INFORMATIONAL ONLY. --- An email that you sent to [EMAIL PROTECTED] on 04/07/2004, 04:41:48 PM with the subject Re: Hi has been electronically scanned. GraybaR Electric does not accept or send emails with executable attachments. The email has been entirely deleted and will not be delivered. Please contact the person you were sending it to or the GraybaR Electric Help Desk at 314-573-5896 for assistance. Thank you for your business and we apologize for any inconvenience. GraybaR Electric Company
grow
stick another 3 inches in next time you bang a chick... http://sudanese.nzzesrc.com/vp5 take off- http://gong.diffrs.com/a.html chanson indisposition aforethought
