Re: Xwin weirdnesses

[Wirawan Purwanto <wirawan at camelot dot physics dot wm dot edu>]

Certainly there are lots of things that need work at this point with
X.org's Xwin. I also have the same problem as described below. What I did
to resolve the problem is to replace the "run" keyword with "start". "run"
was a cygwin command (run.exe), while "start" is Windows shell (cmd.exe)
intrinsic command.

The other complaint is this: Xwin often closes by itself with NO warning,
nothing written in /tmp/XWin.log. Here's my XWin.log quote:

wirawan@wp ~
$ cat /tmp/XWin.log
Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 6.7.0.0-8

Contact: cygwin-xfree@cygwin.com

XWin was started with the following command line:

XWin -unixkill -nowinkill -clipboard

ddxProcessArgument - Initializing default screens
winInitializeDefaultScreens - w 1600 h 1024
winInitializeDefaultScreens - Returning
_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 00000007
winSetEngine - Using Shadow DirectDraw NonLocking
winAdjustVideoModeShadowDDNL - Using Windows display depth of 24 bits per
pixel
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
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: "00000409" (00000409)
(EE) Keyboardlayout "US" (00000409) 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: 797 480
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.

------ yip, and not too long after, the X screen disappears!
No core dump was found in $HOME directory or /tmp. Note: I use WindowMaker
as the window manager.


Wirawan


OOT:

Are you sure that the %CYGWIN_ROOT%\tmp\.X11-unix subdir is properly
created? This issue is a disgression from the discussion topic, but let me
mention it. It may worth looking into to fix the current implementation of
my-startxwin.bat.

This directory is actually a problem, if someone cares. In my case, the
cygwin "partition" lives on an NTFS filesystem, and I use ntsec (NT
Security) to provide the "real" unix file permissions. This poses a
problem. The X server needs /tmp/.X11-unix subdir, which may or may not be
accessible by any user starting the session. This may in turn fails the
whole X session. Why? Since the X session is started by an ordinary _user_
(and not by ROOT as in Linux). The subdir /tmp/.X11-unix, if created by a
user, say, XYZ, will not be erasable by another user starting X session
(later) on the same machine.

Suppose there are 2 users on that machine that can start X sessions (of
course not concurrently, I would assume, but that can also happen on an XP
box). For simplicity let me assume that they are 2 different users that
would start X at different times, and the sessions do not overlap. The
first user started it, and my-startxwin.bat creates /tmp/.X11-unix (OWNED
by the first user). Now this session is properly terminated. Then the
other user tried to start with my-startxwin.bat, but it wouldn't be able
to, as /tmp/.X11-unix has been there and created by someone else. NTFS
permission is so strict that even administrators can't always able to
erase that subdir!

Let me outline my solution: I had to customize the script, by replacing
%CYGWIN_ROOT%\tmp to another directory which is accessible only to me.
In this case, I create C:\cygwin\tmp\wirawan, and MOUNT that subdir as
/tmp *for me only*:

wirawan@wp ~
$ mount -u -b 'C:\cygwin\tmp\wirawan' /tmp

Then all references to %CYGWIN_ROOT%\tmp are replaced with
C:\cygwin\tmp\wirawan. This can pose another trickery, but it works for
me. My X session would generate .X11-unix subdir in *my* /tmp, not in
global tmp (C:\cygwin\tmp).



On Thu, 13 May 2004, it was written:

> Since updating to the newest xorg distribution weird things are happening
> with starting Xwin from startxwin.bat.  I used to be able to start multiple
> windows in a 800 by 600 screen with the blackbox window manager.  Now when
> I try that using the -scrollbars -clipboard -screen 0 800 600 no window
> appears although when I kill X it thinks there are 2 clients connected?! I
> removed "run" from in front of Xwin in the batch file and that works, well,
> every other time.  I start startxwin.bat and it pops up the X window but then
> doesn't start the window manager or xterm.  If I kill X and restart, then it
> works (although it crashes at random times - it used to never crash).  Rootless
> and multiwindow work, although I like having all my X stuff in its own window
> and using rootless and multiwindow I don't have the benefits of blackbox (i.e.
> opening a new xterm session by right-clicking).  Is anyone else having these
> problems?
>