Re: numlock
Sorry to come back to this again, but I have a lot of user faults reported due to this problem. Our users' boxes boot up with the numlock key on so this causes some confusion when they are told they have to switch the numlock key off before starting XFree. Is there anything I can do to switch this numlock behaviour off without user interference? JS. _ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger
6.7.0.0-4: Unable to connect to remote server using DMCP
I have upgraded to the X/Cygwin 6.7.0.0-4 but find that I am unable to view the login screen on a SuSE Linux box. Basically, the XWin window appears but does not show any of the KDM GUI or login on the remote server. The screen is simply a gray background with the 'X' cursor. Oddly, others are able to connect with XWin on this remote server from _other_ boxes. There doesn't seem to be any indication in the logs as to why this is happening... Has anyone seen this problem before? I haven't seen any suggestions on the mailing list which seemed to alleviate the problems I'm seeing... XWin was started with the following command line: XWin -query 10.10.19.122 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 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 - 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=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 list! winPointerWarpCursor - Discarding first warp: 637 485 winBlockHandler - Releasing pmServerStarted winBlockHandler - pthread_mutex_unlock () returned ddxBeforeReset - Hello winDeinitMultiWindowWM - Noting shutdown in progress
Re: 6.7.0.0-4: Unable to connect to remote server using DMCP
On Thu, 15 Apr 2004, Bailey Wier wrote: I have upgraded to the X/Cygwin 6.7.0.0-4 but find that I am unable to view the login screen on a SuSE Linux box. Basically, the XWin window appears but does not show any of the KDM GUI or login on the remote server. The screen is simply a gray background with the 'X' cursor. The grey background with the X is the X server in the default state. You can end up with this for any number of reasons. Since you're trying to get XDMCP to work here, run xdm/kdm on the SuSE box in debug mode and check the logs. Are you getting any connections from your Windows box at all? Also try to tcpdump at the SuSE box, tcpdump -i eth0 -l udp port xdmcp or something. -- Daniel Mikkelsen Copyleft Software AS
Re: GDI leak fixed in multiwindow mode, thanks to Kensuke's work
Earle, It seems that we've got a lot of cut-n-pasted code in XWin. :( If someone has a few spare hours they should see if we can add a common multiwindow utility function file for things like generating class names or reloading the g_hiconX. I thought same thing when I tested off-by-one error and GDI leaks. MWExtWM's windows cursor and sizing/moving window improvement may be able to apply to multiwindow mode. Kensuke Matsuzaki -- Kensuke Matsuzaki mailto:[EMAIL PROTECTED] http://peppermint.jp
Gone for the weekend
I will be gone until Sunday evening. Please try to answer questions while I am gone. I may make a release in the next 30 minutes, but I may not have enough time. Later, Harold
Multiple monitors and repainting
I have an NVidia DualView card (Quadro NVS) with two monitors attached to it. My monitors are laid out as 2-1 (#2 on the left). I recently upgraded to the new xorg x11 via setup. The version is xorg-x11 6.7.0.0-6. I start X with startxwin.bat. I'm using Windows 2000. The problem is this: If you move an xterm from one screen to the next (they appear on #2, and I move them to #1), the window stops repainting. If I move half, the half that was on #2 still repaints, while the #1 half does not. I'm wondering if you are aware of this issue, and if you have any solutions or workarounds. For now all my consoles live in monitor #2 :-) Thanks, -David Martinez
RE: Starting with startxwin.bat
... problem with the way that XWin and 'run' interact. In other words, you can't use 'run' with XWin in certain modes... Instead use 'start /B' if you are on an NT-based platform... Using this; start /B XWin run openbox run xsetroot -solid aquamarine4 allows it to start with the 'startxwin.bat' ok, albeit, it does open a separate terminal window. I can easily work with this. Thanks Sterling
RE: 6.7.0.0-4: Unable to connect to remote server using DMCP
Thanks, Daniel... I figured this one out using your tcpdump suggestion. For reference, it appears that the network routing or dns tables had an older cached reference for the IP address I was making xdmcp requests from. Thus, xdm resolved an invalid hostname for the source address and sent packets to a non-existing host. e.g.: C:\cygwinhostname NYC-5XB1R31.marketaxess.com C:\cygwinXWin.exe -query nyc-hhgas.marketaxess.com nyc-hhgas:/var/log # tcpdump -i eth0 -l udp port xdmcp tcpdump: listening on eth0 17:08:51.760754 nyc-wr0vs.marketaxess.com.mice nyc-hhgas.marketaxess.com.xdmcp: udp 7 17:08:51.790810 nyc-hhgas.marketaxess.com.xdmcp nyc-wr0vs.marketaxess.com.mice: udp 52 (DF) 17:08:52.451785 nyc-wr0vs.marketaxess.com.mice nyc-hhgas.marketaxess.com.xdmcp: udp 66 17:08:52.453015 nyc-hhgas.marketaxess.com.xdmcp nyc-wr0vs.marketaxess.com.mice: udp 52 (DF) 17:08:52.453457 nyc-wr0vs.marketaxess.com.mice nyc-hhgas.marketaxess.com.xdmcp: udp 29 17:08:54.458327 nyc-wr0vs.marketaxess.com.mice nyc-hhgas.marketaxess.com.xdmcp: udp 29 17:08:57.113586 nyc-gwb1r31.marketaxess.com.xdmcp 255.255.255.255.xdmcp: udp 34 17:08:58.458581 nyc-wr0vs.marketaxess.com.mice nyc-hhgas.marketaxess.com.xdmcp: udp 29 On Thu, 15 Apr 2004, Bailey Wier wrote: I have upgraded to the X/Cygwin 6.7.0.0-4 but find that I am unable to view the login screen on a SuSE Linux box. Basically, the XWin window appears but does not show any of the KDM GUI or login on the remote server. The screen is simply a gray background with the 'X' cursor. The grey background with the X is the X server in the default state. You can end up with this for any number of reasons. Since you're trying to get XDMCP to work here, run xdm/kdm on the SuSE box in debug mode and check the logs. Are you getting any connections from your Windows box at all? Also try to tcpdump at the SuSE box, tcpdump -i eth0 -l udp port xdmcp or something. -- Daniel Mikkelsen Copyleft Software AS
Re: Multiple monitors and repainting
David, Add -multiplemonitors to your XWin command line. -- Original Message - Subject: Multiple monitors and repainting Date: Thu, 15 Apr 2004 10:57:57 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] I have an NVidia DualView card (Quadro NVS) with two monitors attached to it. My monitors are laid out as 2-1 (#2 on the left). I recently upgraded to the new xorg x11 via setup. The version is xorg-x11 6.7.0.0-6. I start X with startxwin.bat. I'm using Windows 2000. The problem is this: If you move an xterm from one screen to the next (they appear on #2, and I move them to #1), the window stops repainting. If I move half, the half that was on #2 still repaints, while the #1 half does not. I'm wondering if you are aware of this issue, and if you have any solutions or workarounds. For now all my consoles live in monitor #2 :-) Thanks, -David Martinez -- -Earle F. Philhower, III [EMAIL PROTECTED] http://www.ziplabel.com
Re: Problem with other window managers
On 15 Apr, [EMAIL PROTECTED] wrote: I'm unable to start any other window manager (twm, wmaker) with XWin 6.7.0.0-3, only the -multiwindow works. Is this a problem of whether to use 'run' or 'start /B' for starting XWin or the manager? I believe you have to change the script that starts X, so that startx is invoked like so: startx -- :0 Remember to add an exec wmaker to your .xinitrc file, too. luke
