Re: problem of cygwin X fixed
On 25 Nov, Emacs Rocky wrote: > Dear: > > I just sent a mail to complain I can't start X in cygwin. > > Now, I fount the solution in old mail-list. > > Anybody experienced the same problem can refer to > http://sourceware.org/ml/cygwin-xfree/2006-10/msg00051.html > > > the key point is : You need to mount the /usr/X11R6/lib/X11/fonts with > binary mode. > > but , I don't know why it worked well in another machine without the > mount for /usr/X11R6/lib/X11/fonts . > > anyway. thanks to all you guys. > > Rocky This used to be broken in Cygwin for a while, then it was fixed. I reinstalled from a snapshot from Jan 3rd 2007 and the problem had returned. I had no mount point for X at all, so I don't know why the problem occurred. I did have a warning from setup saying that setup.ini indicated it was newer than the version setup was expecting to install. I re-ran setup a couple more times, re-installing the fonts (no complaints about possibly mismatched setup.ini file this time), with no luck. Anyway, because I had no mount of the X fonts directory at all, I did this to create one: $ mount -b c:\cygwin\usr\lib\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts and re-ran setup to reinstall the fonts yet agai, and yes, X could now start, the problem is fixed. luke -- 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: Cygwin/X server displays nothing, sh.exe hangs
On 27 Dec, Mark Allen wrote: > sh.exe sits on close to 100% cpu usage until I kill it manually, and nothing > > is displayed on the x server (command line version seems to work, but is > missing several basic commands like ssh for some reason). > > I've looked through the mailing lsit & seen zonealarm can be a culprit for > these kind of symptoms, I do not have zonealarm installed, the only similar > program is the mcafee security center & privacy service (which I cannot > disable). I don't know if these cause the same issues as zonealarm. We see that and worse if there is another X server already running on the system - in fact it tends to force a reboot. (Xwin32, IIRC.) Yes, I know you should not run two X servers. It only happens by user error. luke
Re: running xterm in cygwin
On 24 Sep, Leow Wee Kheng wrote: > I installed Cygwin/X in my WinXP PC. > But, it has problem opening the X display. > I've set the display to my PC's host name > using "export DISPLAY=leowwk-1" but it still > doesn't work. Any idea what's the problem? You shouldn't need to set it explicitly, unless you're running it from a command outside X (e.g. from a DOS prompt), and even then it should only need to be set to ":0.0". You have remembered to actually start X first, haven't you? Experiment by starting X (use "startx" or run xinit directly). Check out /tmp/XWin.log to see if any errors are reported. luke
Re: The "no font fixed" problem
On 21 Sep, Alexander Gottwald wrote:
> On Tue, 21 Sep 2004 [EMAIL PROTECTED] wrote:
>
> > The problem with X not running because of the error "no font 'fixed'"
> > has been around so long that some months ago a I scripted a post-install
>
> I could provide new packages where the remounting of /usr/X11R6/lib/X11/fonts
> is not done anymore but the list files are autogenerated on postinstall.
>
> It works on binmode (as expected) but I was not able to get hands on a clean
> textmode install to test.
>
> bye
> ago
Many thanks! Following your release of the new xorg-x11-{fonts,xwin}-6.8.1.0-2
package, I'd like to report that X worked 1st time after a fresh
install.
Many thanks, Alexander,
luke
The "no font fixed" problem
The problem with X not running because of the error "no font 'fixed'" has been around so long that some months ago a I scripted a post-install fixup, based on http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof FWIW, here's the output on a machine we installed Cygwin on today. You'll note that most of the theories about the cause of the problem were incorrect in this case: Now trying to workaround the new X installation problem Hmm, /usr/X11R6/lib/X11/fonts exists. So much for that theory. Hmm, /usr/X11R6/lib/X11/fonts/misc exists too. So much for that theory. Hmm, /usr/X11R6/lib/X11/fonts/misc had plenty of fonts (446, actually) Checking for /usr/X11R6/lib/X11/fonts mount point... D:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmo de) Unmounting /usr/X11R6/lib/X11/fonts in preparation for fix Now re-running setup: you will need to choose RE-INSTALL for each of the X11 font sets (about 4 sets) under the X11 category. ** Lets try starting X to see if it now works. If you have to kill any of these attempts, you can continue from where you left off by using the try-X script. ** etc. So, the FAQ entry's theories don't seem to match the real cause, whatever that may be. I assume this problem has been affecting everyone, for months now, not just us? Or have I missed something? Here's the fixup script that generates the above output. The "yorn" script just asks for and examines a y/n answer. fixup-X #!/bin/sh # # As of about June 2004, every Cygwin installation installs a broken # version of X. # # Workaround is as per the FAQ: # http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof # This is an attempt to automate the workaround as far as possible. # # Author: Luke Kendall # DONE_PROOF=/etc/profile.d/.X-fixed # Same as in try-X MYNAME=`basename $0` XFONTDIR=/usr/X11R6/lib/X11/fonts if [ -s $DONE_PROOF ] then echo "$MYNAME: $DONE_PROOF indicates X11 has already been fixed." if yorn "do you really want to do it again" then : else exit 0 fi fi if [ ! -d $XFONTDIR ] then echo "Strange but kind of good: as expected, $XFONTDIR did not exist" else echo "Hmm, $XFONTDIR exists. So much for that theory." if [ ! -d $XFONTDIR/misc ] then echo "Not unexpected, $XFONTDIR/misc did not exist" else echo "Hmm, $XFONTDIR/misc exists too. So much for that theory." NUM=`ls $XFONTDIR/misc | wc -l` if [ $NUM -le 100 ] then echo "As expected, $XFONTDIR/misc had few fonts ($NUM, actually)" else echo "Hmm, $XFONTDIR/misc had plenty of fonts ($NUM, actually)" fi fi fi echo "Checking for $XFONTDIR mount point..." if mount | grep "$XFONTDIR" then echo "Unmounting $XFONTDIR in preparation for fix" umount $XFONTDIR else echo "Hmm, pretty strange, $XFONTDIR wasn't mounted on C:/cygwin$XFONTDIR" fi echo "Now re-running setup: you will need to choose RE-INSTALL for each" echo "of the X11 font sets (about 4 sets) under the X11 category." //samba/install/win32/cygwin/setup.exe echo "**" echo "Let's try starting X to see if it now works. If you have to" echo "kill any of these attempts, you can continue from where you left off" echo "by using the try-X script." echo "**" $CYG_POST_DIR/try-X - cut here -- Regards, luke
Re: Problem in Cygwin-X...
On 17 Sep, Moises Deangelo wrote: > Please > > I installed cygwin in my windows 2000 with service pack 4. > > I download the complete version of cygwin. > > But the graphic interface does not work by any means > Cygwin-X does not run. > > Any applications do not accuse no mistake, simply do not initiate. > Other introduce the following mistake: > > RUN.EXE > ERROR: could not start C:\cygwin\usr\X11R6\xdvi -display 127.0.0.1:0.0 > > Can anybody help to do the graphic interface to work? > > Moises Deangelo. For us, for many months now, X11 hasn't worked after any fresh Cygwin install, due to the "missing font "fixed" problem) - see http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof In fact, our install process now runs setup, runs various commands as per the faq entry above, then re-runs setup and requires the user to re-install the X fonts. After that X will work. On top of that, there were changes to -multiwindow and other parameters. We now default to starting X in a way that boils down to this: xinit -- -rootless -clipboard -logfile /tmp/XWin.log.$USER The .$USER is important if multiple people may use the machine - the default choice of /tmp/XWin.log will make X fail to start because a later user won't have write permissions on /tmp/XWin.log. Anyway, try the above, and check out the contents of the log file to help work out what's going wrong. luke
Re: Does xinit do magic stuff?
On 23 Jul, To: [EMAIL PROTECTED] wrote: > I ask only to try to understand. I think the correct fix is to use > xinit. The new script seems to work completely reliably. I'm still interested in xinit's magic, though. :-) luke #!/bin/sh # # Start up X. Allow XSERVER_ARGS to define args to pass to the X server. # # Author: Luke Kendall # MYNAME=`basename $0` USAGE="$MYNAME This will start X (by running $HOME/.xserverrc if that file exists), otherwise by running xinit -- \$XSERVER_ARGS. An example of the (optional) ~/.xserverrc file: xinit -- \$XSERVER_ARGS The default window manager is wmaker; use \$WINDOWMANAGER to override." # # Process the command line arguments. # Of which there are none, presently. # if [ $# != 0 ] then echo "Usage: $USAGE" >&2 exit 1 fi # # If the user has a .xserverrc, use that instead of the default, which is to # run "xinit -- $XSERVER_ARGS". # XSERVER_ARGS are defined in /etc/profile.d/cisra.sh # if [ -f $HOME/.xserverrc ] then $HOME/.xserverrc& else xinit -- $XSERVER_ARGS & fi > /tmp/XWin.xlog.$USER 2>&1 # Collect all the ugly output echo "Please see /tmp/XWin.xlog.$USER for extra X11 startup output"
Does xinit do magic stuff?
I have just found that on a very recent Cygwin, I can never ever start X using our simple shell script (just posted: cisraxwin.sh). The script does this: runs ~/.xserverrc if it exists, else it runs Xwin with $XSERVER_ARGS; waits for the X server to start; else fails if ~/.xinitrc exists, it feeds that to a shell, else runs an xterm and then wmaker kills Xwin when the window manager exits But this works 50% of the time on my machine (with a weeks-old Cygwin), and fails 100% of the time on a new machine (with a days-old Cygwin). But if I run xinit with the options that I'd chosen for Xwin, it works 100% of the time. Clearly, the thing to do is to change our script to use xinit. We thought xinit's logic was basically the same as what I've described above, for our script. But it seems it does some other magic that's not mentioned in the man page. Would anyone tell me what the extra "magic" is? Does it set up shared memory, or named pipes, or similar? I ask only to try to understand. I think the correct fix is to use xinit. luke
Sometimes X starts, sometimes it sticks
cisraxwin.sh"
rem pause
: /cygdrive/x/cygnus/cisra ; ./cisrastartx.bat
The system cannot find the path specified.
Setting OFFICE_PATH (if MS Office is installed) ...
Path is /cygdrive/c/Program Files/Microsoft Office/Office10/, version: 10.0
Running .profile
Setting up for bash
Setting up GNU environment
Setting up CVS environment
stty: standard input: Not a typewriter
Please see /tmp/XWin.xlog.luke for extra X11 startup output
... X server is running
kill 3336: No such process
: /cygdrive/x/cygnus/cisra ; # That worked. That's 2 in a row.
: /cygdrive/x/cygnus/cisra ; ./cisrastartx.bat
The system cannot find the path specified.
Setting OFFICE_PATH (if MS Office is installed) ...
Path is /cygdrive/c/Program Files/Microsoft Office/Office10/, version: 10.0
Running .profile
Setting up for bash
Setting up GNU environment
Setting up CVS environment
stty: standard input: Not a typewriter
Please see /tmp/XWin.xlog.luke for extra X11 startup output
... X server is running
kill 2352: No such process
: /cygdrive/x/cygnus/cisra ; ./cisrastartx.bat
The system cannot find the path specified.
Setting OFFICE_PATH (if MS Office is installed) ...
Path is /cygdrive/c/Program Files/Microsoft Office/Office10/, version: 10.0
Running .profile
Setting up for bash
Setting up GNU environment
Setting up CVS environment
stty: standard input: Not a typewriter
Please see /tmp/XWin.xlog.luke for extra X11 startup output
... X server is running
kill 2556: No such process
: /cygdrive/x/cygnus/cisra ; # That worked. That was 4 in a row.
: /cygdrive/x/cygnus/cisra ; ./cisrastartx.bat
The system cannot find the path specified.
Setting OFFICE_PATH (if MS Office is installed) ...
Path is /cygdrive/c/Program Files/Microsoft Office/Office10/, version: 10.0
Running .profile
Setting up for bash
Setting up GNU environment
Setting up CVS environment
stty: standard input: Not a typewriter
Please see /tmp/XWin.xlog.luke for extra X11 startup output
... X server is running
kill 2140: No such process
: /cygdrive/x/cygnus/cisra ; # 5 in a row.
: /cygdrive/x/cygnus/cisra ; ./cisrastartx.bat
The system cannot find the path specified.
Setting OFFICE_PATH (if MS Office is installed) ...
Path is /cygdrive/c/Program Files/Microsoft Office/Office10/, version: 10.0
Running .profile
Setting up for bash
Setting up GNU environment
Setting up CVS environment
stty: standard input: Not a typewriter
Please see /tmp/XWin.xlog.luke for extra X11 startup output
... X server is running
kill 2376: No such process
: /cygdrive/x/cygnus/cisra ; # 6 in a row.
Any insights would be welcome! We do also have a ~/.Xresources, though
I doubt that's relevant.
---- cisraxwin.sh
#!/bin/sh
#
# Start up X. Allow XSERVER_ARGS to define args to pass to the X server.
# Use ~/.xinitrc if it exists, otherwise an xterm and $WINDOWMANAGER.
#
# Authors: Cameron Simpson and Luke Kendall
#
MYNAME=`basename $0`
USAGE="$MYNAME
This will start X (by running $HOME/.xserverrc if that file exists),
otherwise by running Xwin \$XSERVER_ARGS.
An example of the (optional) ~/.xserverrc file:
Xwin \$XSERVER_ARGS
After starting X, we run $HOME/.xinitrc if it exists.
The default window manager is wmaker; use \$WINDOWMANAGER to override."
#
# Process the command line arguments.
# Of which there are none, presently.
#
if [ $# != 0 ]
then
echo "Usage: $USAGE" >&2
exit 1
fi
#
# If the user has a .xserverrc, use that instead of the default, which is to
# run "Xwin $XSERVER_ARGS".
# XSERVER_ARGS are defined in /etc/profile.d/cisra.sh
#
if [ -f $HOME/.xserverrc ]
then
$HOME/.xserverrc&
else
Xwin $XSERVER_ARGS &
fi > /tmp/XWin.xlog.$USER 2>&1 # Collect all the ugly output
xserver=$!
echo "Please see /tmp/XWin.xlog.$USER for extra X11 startup output"
DISPLAY=:0
export DISPLAY
while :
do
# If we can run xdpyinfo, the server is running properly:
xdpyinfo >/dev/null 2>&1 && echo "... X server is running" && break
# Did the X server die during startup? If so, give up and exit:
kill -0 $xserver 2> /dev/null || exit 1
echo "$MYNAME: waiting for X server ..."
sleep 1
done
#
# If the user has a .xinitrc file, run that after the X server has started,
# else just give them an xterm and run the Window Maker window manager.
#
(
if [ -f $HOME/.xinitrc ]
then
exec sh $HOME/.xinitrc >> /tmp/XWin.xlog.$USER 2>&1
else
xterm &
exec ${WINDOWMANAGER:-wmaker}
fi
)
# Do what xinit does when the window manager exits:
kill $xserver
~/.xinitr
Re: cygwin/x: x starts, but does nothing
On 22 Jul, ?man wrote: > I installed cygwin with all the packages. I made a batch file called "xwin.bat" > that runs xwin located in my home dir, so that I dont have to navigate to the > file every time. > > Here is the content of "xwin.bat": > > -- > > @echo off > > chdir C:\cygwin\usr\X11R6\bin > > startxwin > > -- > > Here is the cygwin shell log i took: > > -- > > [EMAIL PROTECTED] ~ > > $ xwin > > Welcome to the XWin X Server > > Vendor: The Cygwin/X Project > > Release: 6.7.0.0-12 > > Contact: [EMAIL PROTECTED] > > winInitializeDefaultScreens - w 1280 h 1024 > > winInitializeDefaultScreens - Returning > > _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root > > XWin was started with the following command line: > > xwin > > What happens is X starts, but does nothing. The mouse remains the "X" cursor, > and the background remains the black and white checker pattern. The only > thing I can do is close it from the Windows close button, and it confirms > exiting. > > Since the only error I see that is not totally disregarded in the FAQ/User > manuals online is "Could not init font path element > /usr/X11R6/lib/X11/fonts/CID/, removing from list!", I tried following the > instructions to reinstall the fonts in the FAQ. However, I still get this > error. > > I navigated in windows explorer to the C:\cygwin\usr\X11R6\lib\X11\fonts > directory, but no \CIV directory exists. However, there are about 9 other > directories, some containing other fonts. > > I want to know if this is the problem, or if I am doing something else wrong, > such as a missing command line parameter needed to do anything. > Thank you for your time. You're not running any X applications. Try this in an rxvt or Cygwin window: export DISPLAY=":0.0" rxvt & You might want to run a window manager too: twm & Running XWin is just running the X11 server. It would be like just running /usr/X11R6/bin/X under Linux. I don't think it's the same as my problem at all (that I'm about to report). The "cisraxwin.sh" (coming in later email) shows the kind of thing you can wrap around the call to xwin.exe. It's a much simpler script than startx. luke
Re: Recent X installation oddity
On 16 Jul, To: [EMAIL PROTECTED] wrote: > Two more installs today, with the same problem. On one machine, X just blocked if you started it with the -multiwindow option. The X logo appeared in the taskbar, but you couldn't even right-click on that to bring up the menu, or kill the blocked X if you started it from the command line via CTRL-C (had to use Task Manager). Except that you *could* kill it if you ran it under strace, which I'll show you the last 25 lines of the > 3000 lines of output that that produced, in case it's of interest. (That's at the end.) Fortunately, -rootless seems to work well again now. Below is my byzantine workaround that we're starting to use locally to fix up the install. luke - fixup-X - #!/bin/sh # # As of about June 2004, every Cygwin installation installs a broken # version of X. # # Workaround is as per the FAQ: # http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof # This is an attempt to automate the workaround as far as possible. # # Author: Luke Kendall # DONE_PROOF=/etc/profile.d/.X-fixed # Same as in try-X MYNAME=`basename $0` XFONTDIR=/usr/X11R6/lib/X11/fonts if [ -s $DONE_PROOF ] then echo "$MYNAME: $DONE_PROOF indicates X11 has already been fixed." if yorn "do you really want to do it again" then : else exit 0 fi fi if [ ! -d $XFONTDIR ] then echo "Strange but kind of good: as expected, $XFONTDIR did not exist" else echo "Hmm, $XFONTDIR exists. So much for that theory." if [ ! -d $XFONTDIR/misc ] then echo "Not unexpected, $XFONTDIR/misc did not exist" else echo "Hmm, $XFONTDIR/misc exists too. So much for that theory." NUM=`ls $XFONTDIR/misc | wc -l` if [ $NUM -le 100 ] then echo "As expected, $XFONTDIR/misc had few fonts ($NUM, actually)" else echo "Hmm, $XFONTDIR/misc had plenty of fonts ($NUM, actually)" fi fi fi echo "Checking for $XFONTDIR mount point..." if mount | grep "$XFONTDIR" then echo "Unmounting $XFONTDIR in preparation for fix" umount $XFONTDIR else echo "Hmm, pretty strange, $XFONTDIR wasn't mounted on C:/cygwin$XFONTDIR" fi echo "Now re-running setup: you will need to choose RE-INSTALL for each" echo "of the X11 font sets (about 4 sets) under the X11 category." //samba/install/win32/cygwin/setup.exe echo "**" echo "Let's try starting X to see if it now works. If you have to" echo "kill any of these attempts, you can continue from where you left off" echo "by using the try-X script." echo "**" try-X --- try-X #!/bin/sh # # Try to run X in different ways. If you find a way that works, exit with # success. # If X blocks so badly you have to kill the calling script, this is written # so that next time you run it, it will skip the methods it's tried and # proceed to the next attempt. # # Author: Luke Kendall # DONE_PROOF=/etc/profile.d/.X-fixed # Same as in fixup-X MYNAME=`basename $0` PATH="/usr/X11R6/bin:$PATH" STAGE=/tmp.$USER for TRY in \ startx \ "startx -- -multiwindow :0" \ "startx -- -clipboard :0" \ /startx.bat \ startxwin.sh\ "xinit -- -kb -clipboard" \ "X :0 -multiwindow" do if [ -s "$STAGE.$TRY.bad" ] then echo "Skipping $TRY - must have failed badly last time" continue elif [ -s "$STAGE.$TRY" ] then echo "Skipping $TRY - already tried" continue else date > "$STAGE.$TRY.bad" fi echo "Now attempting to start X via $TRY ..." $TRY mv "$STAGE.$TRY.bad" "$STAGE.$TRY" if yorn "Did that run X correctly" then echo "Noting that the problem has now been fixed" date >> $DONE_PROOF head -5 /tmp/XWin.log >> $DONE_PROOF echo >> $DONE_PROOF echo "That method ($TRY) would be good" echo " for you to put into /startx.bat" exit 0 fi done exit 1 strace output --- 216 35608223 [main] Xwin 3132 open: 6 = open (/usr/X11R6/lib/X11/locale/locale.alias, 0x0) 4 35608227 [unknown (0x84C)] Xwin 3132 fhandler_base::write: 1 = write (0x100F390B, 1) 122 35608349 [main] Xwin 3132 _cygwin_istext_for_stdio: fd 6: defaulting to text 28189 35636538 [unknown (0x84C)] Xwin 3132 writev: 1 = write
Re: Recent X installation oddity
On 16 Jul, To: [EMAIL PROTECTED] wrote: > In the last couple of days, we've done several cygwin fresh installs > and updates. In every case we get the X problem "Cannot find font: > fixed", afterwards. If it's of any interest, we have mirrored Cygwin from kernels.org (and update each night via rsync). luke
X failures if two users
If two people use the same machine, and the first starts X, the second person can't start X unless they have administrator rights. Cygwin sets /tmp to have mode drwxrwxrwt which means ordinary users can't remove /tmp/XWin.log if it's owned by someone else. So subsequent attempts to start X fail because it can't write the log file. My suggestion would be for X to create the file called /tmp/XWin.log.$USER luke PS: Note that unlike Unix, it is possible for a user to remove a file that some other user created in a directory with the above permissions, provided they have administrator privileges on a machine.
Re: Recent X installation oddity
On 16 Jul, To: [EMAIL PROTECTED] wrote: > In the last couple of days, we've done several cygwin fresh installs > and updates. In every case we get the X problem "Cannot find font: > fixed", afterwards. Two more installs today, with the same problem. luke
Recent X installation oddity
In the last couple of days, we've done several cygwin fresh installs and updates. In every case we get the X problem "Cannot find font: fixed", afterwards. In every case, the directory C:/cygwin/usr/X11R6/lib/X11/fonts exists, it contains the directory misc, that directory contains hundreds of files, yet we get the error message. And, as per the FAQ, we then have to umount /usr/X11R6/lib/X11/fonts, re-run setup, select all the X fonts, and choose reinstall. This is both on absolutely fresh machines (Windows XP just installed), and on an update to an older Cygwin system. (Which may have had the same problem before running setup again, admittedly.) Any idea what's wrong? It used to be that X normally worked after an install. Now it seems to fail with this problem each time. I'm planning to automate (as far as I can), the FAQ fixup, in our local post-install script. (Unfortunately, I don't think I can drive setup.exe from the command line to reinstall the fonts directly, can I? Are there files I could remove from the install afterwards, so that a second run of setup could be done that would find that the X fonts were gone and proceed to install them?) Also, I was wondering why /usr/X11R6/lib/X11/fonts is mounted anyway? Since / is mounted, you can reach it using that same path. If it was so that you could remount it elsewhere if you wanted to, because you didn't have the space to hold 40MB (heh: tiny, these days!), then you could do the mount then ... Just wondering. luke
X starting difficulties
I just sat down with a colleague here who has never previously been able to run X on his XP laptop. I got it working, but *only* by doing this: /usr/X11R6/bin/X :0 -multiwindow & - nothing else that I could think of could start X. (The laptops here typically have ZoneAlarm installed, but I don't think it's implicated this time since I was able to get X to work, as above.) His initial problem was the "Cannot find font: fixed" error. Once we followed the faq workaround for that (re-install the fonts), we began to make some progress. I tried several ways to start X, which all failed: >From Cygwin bash shell: startx --> ... XWin was started with the following command line: X :0 -multiwindow -clipboard ... winClipboardProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardProc - Call to select () failed: -1. Bailing. winClipboardProc - XDestroyWindow succeeded. winClipboardIOErrorHandler! I got the same problem using a local .bat script that does this: rem The D: gets replaced by the real Cygwin drive during installation: D: chdir \cygwin\bin bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -multiwindow" Thinking it was a problem with the -clipboard option, I tried removing it in the proper way, by creating a file ~/.xserverrc containing: userserverrc="-multiwindow" That lead to worse problems (quite worrying, I think) - ... XWin was started with the following command line: /usr/X11R6/bin/X :0 -multiwindow ... 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 winProcEstablishConnection - Clipboard is not enabled, returning. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. winDeinitMultiWindowWM - Noting shutdown in progress winMultiWindowWMIOErrorHandler! winInitMultiWindowWM - Caught IO Error. Exiting. winDeinitMultiWindowWM - Noting shutdown in progress In contrast, here are pieces of the XWin.log when started via /usr/X11R6/bin/X :0 -multiwindow & XWin was started with the following command line: /usr/X11R6/bin/X :0 -multiwindow ... winMultiWindowXMsgProc - DISPLAY=127.0.0.1:0.0 winInitMultiWindowWM - pthread_mutex_unlock () returned. winInitMultiWindowWM - DISPLAY=127.0.0.1:0.0 winProcEstablishConnection - Hello winProcEstablishConnection - Clipboard is not enabled, returning. winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winInitMultiWindowWM - XOpenDisplay () returned and successfully opened the display. Here's a diff output of the log from the successful way (<) and an unsuccessful attempt that had clipboard turned off (>): 53a54,59 > winDeinitMultiWindowWM - Noting shutdown in progress > > winMultiWindowWMIOErrorHandler! > > winInitMultiWindowWM - Caught IO Error. Exiting. > winDeinitMultiWindowWM - Noting shutdown in progress Here's a diff output of the log from the successful way (<) and an unsuccessful attempt that had clipboard turned on (>): 9c9 < /usr/X11R6/bin/X :0 -multiwindow --- > X :0 -multiwindow -clipboard 39c39,40 < winMultiWindowXMsgProc - Calling pthread_mutex(--) winConfigKeyboard - Layout: "0409" (0409) --- > (--) Setting autorepeat to delay=500, rate=31 > (--) winConfigKeyboard - Layout: "0409" (0409) 51c52,53 < winProcEstablishConnection - Clipboard is not enabled, returning. --- > winInitClipboard () > winProcEstablishConnection - winInitClipboard returned. 52a55,57 > winClipboardProc - Hello > DetectUnicodeSupport - Windows NT/2000/XP > winClipboardProc - DISPLAY=127.0.0.1:0.0 53a59,64 > winClipboardProc - XOpenDisplay () returned and successfully opened the display. > winClipboardProc - Call to select () failed: -1. Bailing. > winClipboardProc - XDestroyWindow succeeded. > > winClipboardIOErrorHandler! > Also, we couldn't start any X applications from the Cygwin menu items via the Windows Start bar; apparently /usr/X11R6/bin isn't in the path, so none of the commands were found. luke
Re: -mwextwm works but -multiwindow does not
On 4 May, Harold L Hunt II wrote: > No, you are not supposed to be using -mwextwm nor -multiwindow. Both of > these parameters are intended to be used with a Windows-based window > manager; -multiwindow starts this window manager automatically while > -mwextwm relies on you to manually launch "xwinwm" (available in the > xwinwm package for Cygwin) and since you are probably not launching > xwinwm you are not having problems with trying to run two window > managers in that case. > > You need to be using either -rootless or -nodecoration (try each and > decide which you like). Where is the best place to read up on all this? I had a look at http://x.cygwin.com/docs/ug/configure-cygwin-x-options.html but couldn't see a mention of -mwextwm. I'm trying to work out a way to configure our setups so that it's easy for individual users to choose between running rooted and using ..xinitrc, or rootless (if I can put it that way). Is "xwinwm" a synonym for the Windows window manager? If I start with -nodecoration and stick "exec xwinwm" in my .xinitrc, will I get a rootless bunch of windows managed by Windows? If I want a rootless bunch of windows managed by wmaker, can I still do that? luke
Re: Error starting X
On 14 Apr, Carolyn Longfoot wrote: > sorry to bother but my fresh Cygwin installation fails to start X, and I'm > at a complete loss as to why. This is straight after a reboot, so why there > would be a server already running is a complete mystery to me. How do I go > about troubleshooting this? Sounds like you have a .xinitrc file that specifies a window manager to run. The default behaviour of the Cygwin X server was changed to run a built-in window manager that integrates X windows onto the Windows desktop better (this is the -multiwindow option, which is the default). You could write a .bat script that instead of running Xwin runs Xwin -- :0, to stop the -multiwindow being passed. luke
Re: '"GLX" missing on display' Problems
On 28 Apr, Harold L Hunt II wrote: > http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding Interesting info, though it confuses me a little. Where it says: "It is easiest to just override trusted X11 forwarding by passing -Y to ssh in place of -X. The -Y does the same thing as -X, but it enables trusted X11 forwarding for the current connection." does it mean to say "It is easiest to just override X11 forwarding..."? Otherwise it seems to be saying you can override trusted X forwarding with trusted X forwarding. When it says "OpenSSH 3.8 enables trusted X11 forwarding by default when connecting to an ssh server that supports trusted X11 forwarding.", does it mean that overrides the setting in the /etc/ssh_config file? In other words, which default is the most default? What happens if your config file has both "ForwardX11 yes" and "ForwardX11Trusted yes"? Which is the default then? Is it bad to have both? Is it bad to have one set to yes and the other to no? Apologies if these are stupid questions. I notice that I do have openssh 3.8 installed, and also note that the man page mentions ForwardX11Trusted in only one place, with no explanation, and the section on X11 and TCP forwarding mentions only ForwardX11 and the -X and -x options, not the -Y. So I couldn't get answers to my questions there. (This is true in the latest Cygwin, as of a day or so ago.) Regards, luke
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
/usr/bin/xterm (was: Re: Various starting X problems)
On 1 Apr, Igor Pechtchanski wrote: > > I don't have time to fix this. I would appreciate it if someone else > > would grab the -src package for X-start-menu-icons via setup.exe and > > work on fixing it; I don't want a half-assed untested patch either, I > > want one that has been thoroughly tested (you know, tough stuff like > > clicking at least one of the tree classes of shortcuts: /usr/bin X > > programs, /usr/X11R6/bin X programs, and /usr/X11R6/bin terminal > > programs) since the sort of changes required may break the other links > > that the scripts create (this is part of the Catch-22 I was talking about). > > I don't recall any discussion or a heads-up that xterm now resides in > /usr/bin... Any particular reason for this decision? I'm certainly interested to hear more. I got some ridicule dumped on me (in my role of Cygwin evangelist) when I mentioned this to an old-time Unix guy here. luke
Re: Fwd: Re: Various starting X problems
On 1 Apr, Harold L Hunt II wrote: > Luke, > > > > [EMAIL PROTECTED] wrote: > >>>cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory > >>>xinit: No such file or directory (errno 2): no program named > "/usr/X11R6/bin/xterm" in PATH > >> > >> > >> Something else must be wrong with your path. > > > > > > I don't think so. FWIW, here is my full and ugly PATH, wrapped for > > easy reading but no other changes: > > Oh no, once again I am right on this one... read on for a full > explanation of what you need to tell us in the future when you have such > problems. Sorry, there was no way that you could know that the startx.bat script wsa *not* involved; it's only used from the desktop shortcut. It lives in "/", and that's not on my path. > > I definitely have a custom .xinitrc file. In fact part of our site > > post-install process was to create a default one, since initially > > Cygwin's XFree didn't include it. I hadn't realised it was colliding > > with one from Cygwin. Our standard site post-install creates the > > ~/.xinitrc. Sounds like I'd better try to back that out. > > /etc/X11/xinit/xinitrc can be copied to ~/.xinitrc, but your copy looks > pretty close to stock except for the window manager that you are running. Makes sense. .xinitrc is just vanilla X stuff. > > How much does Cygwin's XFree depend on the (traditionally) > > user-controlled .xinitrc file, to work properly? Does it also depend > > on specific Cygwin things in ~/.Xresources? > > Not sure what you are asking here... I don't think the things you are > worried about matter in this case. Well, if it doesn't matter whether I'm using mine or using the default one from the XFree install, then there's nothing to worry about. > >> I think you can override the defaultserverargs in your .xinitrc so that > >> you could have a .xinitrc that both starts its own wm and prevents > >> startx from passing "-multiwindow" to XWin.exe. I'm not an xinit/startx > >> expert, so you'll have to look for docs on that elsewhere. > > > > > > Are there any docs on -multiwindow and using the Windows desktop as > > your window manager? I gather that -multiwindow in effect includes a window manager, and that's the main thing to know. > > I tried startxwin.sh without a lot of joy. I can't see where it gets > > its starting set of windows, and I can't see how to start up any > > windows conveniently either. (Currently it has -multiwindow and > > -clipboard hardwired in - it doesn't seem to do any argument > > processing.) > > > > I may change that and send you a revised one, if you'd be interested. > > > > Perhaps my question is, why would anyone choose to run multiwindow > > using the Windows desktop? There seems to be no easy way to start X > > applications, except presumably from the command line. > > > > It doesn't seem to use .xinitrc how I'd expect. Sure, if I add an > > "exec wmaker" then it all fails because it thinks a window manager (the > > Windows desktop) is running, and bails out. But if instead I add an > > xmessage "Quit X" at the end instead, that never appears. I just end > > up with the "console window" with yellow text on black background, and > > an icon in the Windows tray, that I can use to exit X or unhide the > > root window. > > > > If I unhide the root window, then the X cursor disappears. Nor can you > > call up a root menu, since I suppose Windows doesn't understand that. > > And I know of no way to get a root menu in the Windows + multiwindow > > "environment" or mode. > > > > Also, as I said, if I unhide the root window in this mode you can't > > exit from X. You can request to do so, but it doesn't exit until you > > rehide the root window. You can also exit from the taskbar icon if you > > have the root window hidden, but not if the root window is displayed. > > > > Hope this makes some sense, and/or is of some use! You'll notice that all the above problems were with using your startxwin.sh script. > > This looks fine to me. > > > --- cygwin/startx.bat - > > @echo off > > > > rem The D: gets replaced by the real Cygwin drive during installation: > > C: > > > > chdir \cygwin\bin > > > > rem For use with sample .profile: stop the exec in user's .profile for the > > rem case where we're really starting the X server. > > set STARTX=df > > > > rem > > rem Comment out the -rootless line if you *do* want the whole X desktop. > > rem -multiwindow had both hopeless performance and inability to get > > rem character input into an rxvt or xterm window under WindowMaker. > > rem > > > > bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx" > > rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -rootless" > > rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -multiwindow" > > > > pause > > Yeah, there is the money shot baby. This whole time you've been using a > poor
Re: Various starting X problems
On 1 Apr, Igor Pechtchanski wrote: > How about the "macro replace in a postinstall script" approach I suggested > earlier? Also, postinstall scripts already run *in* Cygwin, so there > should be no reason to detect it, right? Just use "cygpath"... > > > > If you'd be interested in a unified approach, where the .bat just runs > > > bash -c startxwin.sh (which will probably in turn be just a wrapper for > > > startx) I might be able to make time for this. > > > > Yes, I think that may be the way to go at this point since we are > > starting to waste a lot of cycles trying to do things in batch files > > that are easily supported in shell scripts using *nix-style utilities. > > Perhaps you're right. As long as you run "bash --login -c ...", so that > the PATH is set properly. That's what I do as part of my post-install. Here's the generic startx.bat: rem The D: gets replaced by the real Cygwin drive during installation: D: chdir \cygwin\bin rem For use with sample .profile: stop the exec in user's .profile for the rem case where we're really starting the X server. set STARTX=df rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx" bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -multiwindow" rem bash --login -c "PATH=$PATH:/usr/X11R6/bin; startx -- -rootless" With this line from my 345 line post-install script: sed "s/^D:/$CYGDRIVE:/;s/\\cygwin/$CYGDIR/" startx.bat > /startx.bat chmod 777 /startx.bat I learned many years ago that writing Windows .bat scripts is like typing with your nose. There's a certain satisfaction at getting a result, but you work a lot harder. My rule of thumb was about 10 times the effort of writing a shell script goes into writing a .bat script. luke
Fwd: Re: Various starting X problems
I'm re-sending this since the mail server rejected the .zip attachment,
it seems:
The Postfix program
<[EMAIL PROTECTED]>: host sources.redhat.com[67.72.78.213] said: 552 we
don't accept email with executable content (#5.3.4) (in reply to end of
DATA command)
Instead, I'll just paste them inline. Apologies for the length.
luke
-- Forwarded message --
From: [EMAIL PROTECTED]
Subject: Re: Various starting X problems
Date: Thu, 1 Apr 2004 17:08:28 +1000 (EST)
To: [EMAIL PROTECTED]
On 31 Mar, Harold L Hunt II wrote:
> Luke,
>
> [EMAIL PROTECTED] wrote:
> > Now with the workaround of knowing to run startx -- :0 to get X to
> > start, I thought I'd have a poke about to see what exactly makes it
> > crash. I came up with several interesting problems.
> >
> > In my .xinitrc I *don't* have an explicit path for xterm. However, I
> > see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other X
> > applications also move into there?
>
> My system does not have a problem finding xterm in /usr/bin because
> /usr/bin should always be in your Cygwin shell path... something else is
> wrong with your Cygwin setup if that is not the case.
Hmm, okay. /usr/bin and /bin and /usrX11R6/bin are all in my PATH.
The error message is:
xinit: No such file or directory (errno 2): no program named "/usr/X11R6/bin/xterm"
in PATH
Since there is no /usr/X11R6/bin/xterm (only a /usr/bin/xterm), I
suppose it's correct. I haven't been able to find what it is that's
referencing the absolute path to the old location for xterm.
(It still seems strange to me that it moved to /usr/bin.)
> > I only noticed that xterm had moved because when I start X with
> > -multiwindow (or with -clipboard), it complains like this and exits:
> >
> > $ PATH="$PATH:/usr/X11R6/bin" startx -multiwindow -- :0
>
> You shouldn't have to set the PATH to include /usr/X11R6/bin... as you
> said, it cannot find /usr/bin/xterm.
No, if it was asking for /usr/bin/xterm it would have been okay.
Something is asking for /usr/X11R6/bin/xterm.
> > XCOMM: not found
>
> Oops... that isn't supposed to be in the startx script. Those XCOMMs
> are supposed to be replaced with # signs at the beginning of the line.
> I've fixed this in a new version of the script.
Thanks.
> > cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory
> > xinit: No such file or directory (errno 2): no program named
> > "/usr/X11R6/bin/xterm" in PATH
>
> Something else must be wrong with your path.
I don't think so. FWIW, here is my full and ugly PATH, wrapped for
easy reading but no other changes:
/cygdrive/C/PROGRA~1/MICROS~3/VC98/BIN:
/cygdrive/C/PROGRA~1/MICROS~3/Common/MSDev98/BIN:
/cygdrive/d/home/luke/op-support:
/cygdrive/d/home/luke/bin:
/opt/bin:
/usr/X11R6/bin:
/usr/local/bin:
/usr/bin:
/bin:
/cygdrive/c/Tcl/bin:
/cygdrive/c/WINDOWS/system32:
/cygdrive/c/WINDOWS:
/cygdrive/c/WINDOWS/System32/Wbem:
/cygdrive/c/Program Files/nsr/bin:
/usr/bin:
/cygdrive/x/bin:
/cygdrive/c/mysql/bin:
/cygdrive/c/jdk1.3.1_01/jre/bin/hotspot:
/cygdrive/d/home/mport/mp/build/win32/bin:
/cygdrive/c/Program Files/Common Files/Adaptec Shared/System:
/cygdrive/c/Program Files/Canon/mport/bin:
/cygdrive/c/Program Files/Canon/mport/bin:
/cygdrive/c/Program Files/Canon/mport/bin:
/cygdrive/c/Program Files/Canon/mport/bin:
/cygdrive/c/Program Files/Canon/mport/bin:
/cygdrive/x/cygnus/cisra:
/opt/script:
/usr/local/bin:/
/handel/d/bin/script:
//handel/d/bin
Apart from some classically-stupid repetitions, and one complete stupid
and excessive repetition I didn't expect (mport), it seems functional
if inefficient.
> I think you have a custom ~/.xinitrc or your /etc/X11/xinit/xinitrc has
> been modified. Or, you might have ~/.xserverrc or
> /etc/X11/xinit/xserverrc (which are not installed by anything I have
> written). Please send in any of these files if you find them so that we
> can see what they are doing. For starters, they are obviously starting
> a window manager, which is not something that the version from
> X-startup-scripts-1.0.5-1 does.
I definitely have a custom .xinitrc file. In fact part of our site
post-install process was to create a default one, since initially
Cygwin's XFree didn't include it. I hadn't realised it was colliding
with one from Cygwin. Our standard site post-install creates the
~/.xinitrc. Sounds like I'd better try to back that out.
How much does Cygwin's XFree depend on the (traditionally)
user-controlled .xinitrc file, to work properly? Does it also depend
on specific Cygwin things in ~/.Xresources?
I'll zip up and attach the files, anyway. I've included an XWin.log
from a failure when started with -multiwindow.
Archive: /u/luke/xwin.zip
Length Date TimeName
1698 04-01-04 14:22 .xinitrc
509 11-06-02 17:31 .Xresources
688 03-17-04 1
Another X crash on startup
A colleague installed the full Cygwin installation onto a laptop on Monday. He can't start X because of what looks like the "Fatal server error: could not open default font 'fixed'" mentioned at http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-error-font-eof However, we've checked that the fonts are installed; mount shows that /usr/X11R6/lib/X11/fonts is used, and the directory contains about 400 files in the misc subdirectory. X won't start. Any other suggestions? This is on a new Dell laptop, running at about 1600x1200, and XP. $ startx XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. $ cat /tmp/XWin.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.63 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X :0 -multiwindow -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1920 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1920 dwHeight: 1200 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1920 h: 1200 winCreateBoundingWindowWindowed - Current w: 1920 h: 1200 winAdjustForAutoHide - Original WorkArea: 0 86 1200 1920 winAdjustForAutoHide - Adjusted WorkArea: 0 86 1200 1920 winCreateBoundingWindowWindowed - WindowClient w 1834 h 1200 r 1834 l 0 b 1200 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1834 height: 1200 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1834 height: 1200 depth: 32 size image: 8803200 winAllocateFBShadowGDI - Created shadow stride: 1834 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winCreateDefColormap - Deferring to fbCreateDefColormap () null screen fn ReparentWindow null screen fn RestackWindow winFinishScreenInitFB - Calling winInitWM. InitQueue - Calling pthread_mutex_init InitQueue - pthread_mutex_init returned InitQueue - Calling pthread_cond_init InitQueue - pthread_cond_init returned winInitWM - Returning. winFinishScreenInitFB - returning winScreenInit - returning winInitMultiWindowWM - Hello winInitMultiWindowWM - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Hello winMultiWindowXMsgProc - Calling pthread_mutex_lock () 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 = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options = "(null)" Could not init font path element /usr/X11R6/lib/X11/fonts/CID/, removing from list! Fatal server error: could not open default font 'fixed' winDeinitMultiWindowWM - Noting shutdown in progress luke Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.63 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X :0 -multiwindow -clipboard ddxProcessArgument - Initializing default screens winInitializeDefaultScreens - w 1920 h 1200 winInitializeDefaultScreens - Returning OsVendorInit - Creating bogus screen 0 _XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root winValidateArgs - g_iNumScreens: 1 iMaxConsecutiveScreen: 1 winDetectSupportedEngines - Windows NT/2000/XP winDetectSupportedEngines - DirectDraw installed winDetectSupportedEngines - DirectDraw4 installed winDetectSupportedEngines - Returning, supported engines 0007 winScreenInit - dwWidth: 1920 dwHeight: 1200 winSetEngine - Multi Window => ShadowGDI winAdjustVideoModeShadowGDI - Using Windows display depth of 32 bits per pixel winCreateBoundingWindowWindowed - User w: 1920 h: 1200 winCreateBoundingWindowWindowed - Current w: 1920 h: 1200 winAdjustForAutoHide - Original WorkArea: 0 86 1200 1920 winAdjustForAutoHide - Adjusted WorkArea: 0 86 1200 1920 winCreateBoundingWindowWindowed - WindowClient w 1834 h 1200 r 1834 l 0 b 1200 t 0 winCreateBoundingWindowWindowed - Returning winAllocateFBShadowGDI - Creating DIB with width: 1834 height: 1200 depth: 32 winAllocateFBShadowGDI - Dibsection width: 1834 height: 1200 depth: 32 size image: 8803200 winAllocateFBShadowGDI - Created shadow stride: 1834 winFinishScreenInitFB - Masks: 00ff ff00 00ff winInitVisual
Various starting X problems
Now with the workaround of knowing to run startx -- :0 to get X to start, I thought I'd have a poke about to see what exactly makes it crash. I came up with several interesting problems. In my .xinitrc I *don't* have an explicit path for xterm. However, I see xterm has moved from /usr/X11R6/bin to /usr/bin! Did many other X applications also move into there? I only noticed that xterm had moved because when I start X with -multiwindow (or with -clipboard), it complains like this and exits: $ PATH="$PATH:/usr/X11R6/bin" startx -multiwindow -- :0 XCOMM: not found cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory xinit: No such file or directory (errno 2): no program named "/usr/X11R6/bin/xterm" in PATH Specify a program on the command line or make sure that /usr/X11R6/bin is in your path. waiting for X server to shut down $ head /tmp/XWin.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.65 Contact: [EMAIL PROTECTED] XWin was started with the following command line: /usr/X11R6/bin/X :0 ddxProcessArgument - Initializing default screens (What is XCOMM, BTW?) However if I start it the same way, but without the -multiwindow, X starts successfully. (PATH="$PATH:/usr/X11R6/bin" startx -- :0) If I try to start it with a plain startx (no "--"), I get the usual illegal option messages (related to having some kind of "traditional" Chinese or Japanese font installed, I vaguely think), and then it dies because it thinks a window manager is already running: $ PATH="$PATH:/usr/X11R6/bin" startx cat: /cygdrive/d/home/luke/.Xauthority: No such file or directory : illegal option -- t : illegal option -- r : illegal option -- a : illegal option -- d : illegal option -- i : illegal option -- t : illegal option -- i : illegal option -- o : illegal option -- n : illegal option -- a DISPLAY is :0 wmaker fatal error: it seems that there is already a window manager running xinit: Bad file descriptor (errno 9): can't send HUP to process group 3904 waiting for X server to shut down $ head /tmp/XWin.log Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.65 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X :0 -multiwindow -clipboard ddxProcessArgument - Initializing default screens Now, I gather that's because another piece of behaviour changed: From: "Danny Staple" <[EMAIL PROTECTED]> Subject: Re: window manager running already Date: Sat, 27 Mar 2004 12:00:57 - (GMT) To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Okay - I was having this problem as well, after updating. What you should do is check if you have an .xinitrc in your home directory. As shipped, older versions of cygwin would runa full screen x, with no window manager, and as such - you would have to run one yourself like wmaker. This would then be added to your .xinitrc file. The new X is configured with a window manager system which embeds windows onto the MS Windows desktop - quite neat when it works - but it means that by default, you do not need another window manager. So you probably need to remove the window manager lines from your .xinitrc, and possibly even remove that altogether if it has nothing else in it. So if I remove the "exec wmaker" from .xinitrc, X starts and stops instantly. So I add an "xterm" at the end of .xinitrc (since X doesn't realise the wmaker would have started lots of windows from its saved workspace state if it had been given a few seconds to run). Also, I see that if I use the MS Windows desktop with -multiwindow, and right-click on the X taskbar icon to turn off the hiding of the root window, I get the gray stipple pattern, the window decorations are stripped off, and the cursor turns into the black X and freezes in position, so I can't see the cursor until I move it out of the X window (e.g. down over the Windows taskbar). Nor can I right-click in the X desktop background area and call up any menu. It looks like no window manager is running at all. I wonder how I can run multiwindow with wmaker as my window manager? Maybe keep the "exec wmaker" and set display to :1 ... No, "startx -multiwindow -- :1" triggers the "no program named "/usr/X11R6/bin/xterm" in PATH" crash. So I don't quite see how to achieve that. I tried xinit -multiwindow but that started up a full desktop. I tried just running "X -multiwindow" from the command line. That appeared to just put the X icon in the taskbar. I turned off "Hide root window" then I got just a plain grey stipple. If I tried to exit from that, a window popped up saying "There are 0 clients connected. Do you want to exit? (Exit) (Cancel)" Clicking on Exit did nothing. I had to Hide the root window - that
Re: startx crashes, xinit works
On 31 Mar, Harold L Hunt II wrote: > Luke, > > [EMAIL PROTECTED] wrote: > > I find that after installing the latest version of Cygwin just now, X > > crashes if I try to start it via startx (not starting with -rootless or > > -multiwindow), with the error > > There is only one way to prove that: send us the top of your > /tmp/XWin.log from such a failed session. The top of XWin.log has a > print out of the command-line parameters that reached the server, which > will prove for good whether -multiwindow is reaching the server or not. You are quite right, I see: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 4.3.0.65 Contact: [EMAIL PROTECTED] XWin was started with the following command line: X :0 -multiwindow -clipboard > Oh yeah, -multiwindow reached the server all right... we wouldn't be > starting multi-window mode if it didn't. > > > Yet I can start it up if I run xinit. > > From 'startx': > > defaultserverargs="-multiwindow -clipboard" > > You see, it is startx that sets the default arugments, not xinitrc. Yep, I see. I thought that since startx.bat didn't pass such args to startx I'd be okay, but thanks for pointing out the true behaviour. > You can always just do "startx -- :0", which provides server args of > ":0", thus overriding the "defaultserverargs", thus preventing > "-multiwindow" from being passed to XWin.exe. Give that a try. Note: > The ":0" doesn't change anything if you were already running on display > number 0 before (this is the default), it is just used here as a dummy > argument so that defaultserverargs are ignored. You could just as > easily change this to "startx -- :1" if you were always starting on > display number 1 instead. > > Harld Thanks, Harold. Yes, that worked fine. I hadn't realised that startx pulled in extra default arguments unless you explicitly added a "--". For my own interest, where can I find where the default arguments are coming from? Is there something I should read up on, about this? I notice that in the announcement of "New package: X-startup-scripts-1.0.0-1" on March 10th, Harold pointed out: Note that the 'startx' and 'xinitrc' files have been modified to make them start the server in the same manner as 'startxwin.bat'. Additionally, "-clipboard" is now being passed to XWin.exe by default. I haven't found the announcement yet where it mentions that -multiwindow is added by default also. Cheers, luke
startx crashes, xinit works
I find that after installing the latest version of Cygwin just now, X crashes if I try to start it via startx (not starting with -rootless or -multiwindow), with the error wmaker fatal error: it seems that there is already a window manager running waiting for X server to shut down xterm: fatal IO error 104 (Connection reset by peer) or KillClient on X server ":0.0" The Xwin.log ends with: winMultiWindowXMsgProc - XOpenDisplay () returned and successfully opened the display. winClipboardProc - XOpenDisplay () returned and successfully opened the display. winClipboardWindowProc - WM_DRAWCLIPBOARD - Initializing - Returning. winClipboardProc - Call to select () failed: -1. Bailing. winClipboardProc - XDestroyWindow succeeded. ddxBeforeReset - Hello winClipboardIOErrorHandler! Yet I can start it up if I run xinit. Any suggestions? luke
Re: Can't start a specific remote X app any more
On 18 Mar, Alexander Gottwald wrote: > > > http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-ssh-no-x11forwarding > > bye No, I read that before I posted (I should have said so, sorry). Other X applications start (sometimes - see below). My investigations suggest that waiting 10 minutes and trying again is a workaround. But Harold's suggestion (to use trusted X forwarding), has worked twice in succession now with no need for a 10 minute pause to get things working, so that seems to be a solution. I still don't understand why a 10 minute pause was needed with old-style X forwarding, but hey, it works with -Y. Thanks, Harold. > > X Error of failed request: BadAtom (invalid Atom parameter) > >Major opcode of failed request: 18 (X_ChangeProperty) > >Atom id in failed request: 0xee > >Serial number of failed request: 12 > >Current serial number in output stream: 15 > > I tried running the MUA from inside gdb, and it worked. > Basically, this is what happened > > postilion --> error message above > repeat 3 times > ssh -X to my Linux machine > postilion --> error message above > xmessage --> ok > tkxplanet --> ok > postilion inside gdb --> ok > postilion --> ok > # log out > postilion --> this error message: > > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 20 (X_GetProperty) > Atom id in failed request: 0xee > Serial number of failed request: 11 > Current serial number in output stream: 11 > > ssh -X to my Linux machine > > $ tkxplanet > X Error of failed request: BadAtom (invalid Atom parameter > Major opcode of failed request: 20 (X_GetProperty) > Atom id in failed request: 0xee > Serial number of failed request: 11 > Current serial number in output stream: 11 > $ xmessage ok > $ tkxplanet > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 20 (X_GetProperty) > Atom id in failed request: 0xee > Serial number of failed request: 11 > Current serial number in output stream: 11 > > I haven't managed to run the MUA a 2nd time. > > Ah. Having just typed all this up, I just tried again in case it might > be time related. Since both times it worked, it was about 10 minutes > after a series of failures. Sure enough, it's working again at the > moment. > > Any idea what might be going on here? luke
Re: Can't start a specific remote X app any more
On 18 Mar, To: [EMAIL PROTECTED] wrote: > Now when I try to run one particular remote X application (my MUA) I get > this error: > > X Error of failed request: BadAtom (invalid Atom parameter) >Major opcode of failed request: 18 (X_ChangeProperty) >Atom id in failed request: 0xee >Serial number of failed request: 12 >Current serial number in output stream: 15 I tried running the MUA from inside gdb, and it worked. Basically, this is what happened postilion --> error message above repeat 3 times ssh -X to my Linux machine postilion --> error message above xmessage --> ok tkxplanet --> ok postilion inside gdb --> ok postilion --> ok # log out postilion --> this error message: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) Atom id in failed request: 0xee Serial number of failed request: 11 Current serial number in output stream: 11 ssh -X to my Linux machine $ tkxplanet X Error of failed request: BadAtom (invalid Atom parameter Major opcode of failed request: 20 (X_GetProperty) Atom id in failed request: 0xee Serial number of failed request: 11 Current serial number in output stream: 11 $ xmessage ok $ tkxplanet X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) Atom id in failed request: 0xee Serial number of failed request: 11 Current serial number in output stream: 11 I haven't managed to run the MUA a 2nd time. Ah. Having just typed all this up, I just tried again in case it might be time related. Since both times it worked, it was about 10 minutes after a series of failures. Sure enough, it's working again at the moment. Any idea what might be going on here? luke
Can't start a specific remote X app any more
I recently upgraded to Cygwin 1.5.7(0.109/3/2), including XWin release 4.3.0.56 installed from XFree86-bin-4.3.0-16.tar.bz2 Now when I try to run one particular remote X application (my MUA) I get this error: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0xee Serial number of failed request: 12 Current serial number in output stream: 15 The remote (linux) machine has not had its sshd config changed since 2002. It has "X11Forwarding yes", and used to work fine. If I ssh -X into the machine, DISPLAY is set to localhost:10.0 The MUA runs fine on the Linux machine which I am connecting to with ssh. xmessage and other X applications I've tried also work okay. The MUA is Postilion (a Tk/Tcl application built from the TkRat MUA, but with the Nextstep Mail program's look and feel). Other Tk applications work okay. There's nothing odd in /tmp/XWin.log. Any suggestions? luke
RE: Alternate window manager
On 9 Jun, Sergio wrote: > I would probably go with windowmaker, which is also downloadable via > setup.exe You might want to extract the modified exitscript from post-install.zip from http://members.optushome.com.au/lukekendall/xwin-network.html to work around a bug in the old version of Window Maker included in Cygwin. That file goes into ~/GNUstep/Library/WindowMaker/ It's basically this: #!/bin/sh # # Place commands to be executed when WindowMaker is exited here. # # WindowMaker will wait until this script finishes, so if you run any # commands that take long to execute (like a xterm), put a ``&'' in the # end of the command line. # # This file must be executable. # cd if [ -d GNUstep/Defaults ] then cd GNUstep/Defaults for f in WMState WindowMaker WMGLOBAL WMRootMenu WMWindowAttributes do tr -d '\015' < $f > $f.fix cp $f.fix $f done /bin/rm -f $f.fix fi luke
Does it work on a Chinese-enabled system?
I tried a Cygwin install on a PC here used by a Chinese person, and had a few strange problems. First, when doing an xrdb -merge .Xresources, it reported these errors: illegal parameter: t illegal parameter: r illegal parameter: a illegal parameter: d illegal parameter: i illegal parameter: t illegal parameter: i illegal parameter: o which I suspect was referring to some function which perhaps returned "traditional chinese" instead of C. Secondly, In any xterm or rxvt window, no prompt string would display. The shell was active and would execute commands; PS1 was set reasonably; but no prompt displayed. Even setting it to a plain old '$ ' made no difference. luke
-multiwindow vs -rootwindow (Was: Re: Setup failures during mirrored install)
On 4 Jun, Igor Pechtchanski wrote: > Umm, I noticed the typo before, but I was hoping you'd notice it too and > correct it. It should have been "startx -- -multiwindow" (you're passing > the "-multiwindow" to the server, not to the clients). Sorry about that. No worries. (I had assumed startx had been modified to treat -multiwindow specially, which was a silly thing to think.) Interestingly, I just did some tests and found that -rootless seems to work much better overall: 1) Able to type in all rxvt and xterm windows, instead of unable to type! 2) Responsiveness of mouse tracking at least twice as good using -rootless compared to -multiwindow. One advantage of -multiwindow is it gives you a confirmation dialogue box when you right click and choose exit from the startx.bat window's task bar entry, not just from the X taskbar entry. Plus you have an option to show the root window. I was using Xserv 4.2.0-37, but have just upgraded to 4.2.0-42 and there's no real change. I'm using Window Maker as the window manager, and running 24 bit colour on 1600 x 1192, under Windows XP Professional on a Dell C400 laptop driving an external monitor. One thing I noticed was that when using -multiwindow, for a short while (just after WM replaced the default window decorations with its own), I was able to type a few characters in one of the rxvt windows. By the time WM had started up all my rxvt and xterm windows, though, I could no longer type in any X window. And Xserv 4.2.0-42 seems about 5 to 10 times more responsive at tracking the mouse cursor when using -rootwindow instead of -multiwindow. This sounds to me interesting enough to Cc: to the mailing list - hope you don't mind. Regards, luke
Re: How to start rxvt via .xinitrc?
On 22 Oct, To: [EMAIL PROTECTED] wrote: > But what's the right way to get it to start up via .xinitrc? It seems > wrong that I should do: > > DISPLAY=":0$DISPLAY" rxvt -sr -sk -backspacekey ^? & Well, experiments show that DISPLAY="$DISPLAY.0" rxvt -sr -sk -backspacekey ^? & appears to work, though it still seems like I'm being very kludgey there. luke
Re: Uses for Cygwin/XFree86
On 21 Oct, Randall R Schulz wrote: > Would that mail client be Sylpheed? > > I looked into it and generally liked what I saw, but the fact that it uses > MH style message storage (one file per message!!) led me to decide I could > not switch to it. That's far to much storage overhead for me to tolerate > since I keep very large archives of the many mailing lists to which I > subscribe. Actually, it's Postilion (http://www.postilion.org/), which is based on the Nextstep mail program (Mail.app). Problems with Postilion: 1) Nic Bernstein isn't actively developing it anymore - I think he may have decided that GNUMail would be a better long term area to devote his efforts. (GNUMail is based on GNUstep, and works. Big mailboxes require a lot of memory, though, currently.) 2) Postilion requires Tk/Tcl for the GUI, and a few other libraries, so it's not a complete piece of cake to compile and install. It can handle 100MB mail folders, though it starts getting very slow when the messages are in the 10 - 20 thousand range, IIRC. > If it's some other mail client, I'd like to hear about it, because I'm > looking to trade up from Eudora, but the only feature that it's missing > (apart from it's limited platform support) is message threading based on > message IDs (not merely subject headers). Everything else about it is > pretty good, especially it's searching and filtering capabilties Postilion allows mailboxes to be presented as sorted by date, in arrival order (mbox order), by subject, subject-by-date (which is *similar* to threading), by sender, reverse date, etc. It's also very extensible in editing messages being composed and operations on messages in mailboxes. I tried sylpheed maybe 6 months ago, but it didn't do enough (then). I think I have my hopes pinned on GNUMail, for the future. luke
How to start rxvt via .xinitrc?
I prefer rxvt over xterm, and it's great that it works with or without Cygwin/XFree86 running. But I just discovered that if I start rxvt like I do xterm from inside my .xinitrc, it starts up in non-X11 mode. It appears to depend on DISPLAY - if it's just ".0" it runs without X11, if it's ":0.0" it runs inside X11. But what's the right way to get it to start up via .xinitrc? It seems wrong that I should do: DISPLAY=":0$DISPLAY" rxvt -sr -sk -backspacekey ^? & luke
Re: Uses for Cygwin/XFree86
On 21 Oct, Harold L Hunt II wrote: > I also use Cygwin/XFree86 to display X forwarded windows via ssh from > other hosts... this is more convenient that XDMCP when the remote host > is running some crap WM like CDE, or when XDMCP logins are disabled to > save processing resources (like at the cyclotron lab that I work at). At home, my wife uses is to run a nice GUI mail client that's safe from Windows viruses etc. (since it's actually running on a Linux box), under Windows 95. I'm also doing the same thing on my laptop at work, for when I'm off site and want to slogin to read my email (which again, is delivered to my Linux machine there). luke
Re: xwinclip problem/puzzle
On 15 Oct, Chris Twiner wrote: > Thanks for the referal Jehan, > > >And maybe Chris has a newer version now. > > Unfortunately not. The version most recently posted had the ctrl+c and > server reset code in place but nothing much else. Oh. >This I had planned to do: > - get the windows clipboard only when something has changed on it (don't > unnecessarily grab the x selection) > - handle multiple X server screens (so you don't end up using windows as an > unnecessary intermediatary clipboard system). > When you run multiple screens do you keep the same display setting or does > it need to change? If it is the same display I can get it working (by > making sure the newly activated window is not a cygwin window). Do you mean multiple virtual desktops, or dual monitors? Though I haven't figured out how to do the former (esp. on Win95), and we don't have dual monitors, so I'll have to leave others to voice their opinions there. > As to further dev I want to contribute but my time is tight at the moment, > previously I was on a part time contract so I could devote time to xwinclip. >Now I'm full time so I don't know when I'll get round to it. I will do > them both, but I just can't say when. Fair enough! Regards, luke
xwinclip problem/puzzle
My wife's Windows config at home now is very functional, thanks to Cygwin and Cygwin-xfree (thanks Christopher, Harold, and everone else!) But, we still can't get copy and paste between XFree86 and Windows... xwinclip works exactly as advertised, but its insistence on de-selecting as it copies to the Windows clipboard means that a broad range of user interface actions inside X become impossible. One example is where you have to select an item from a list before applying some action to the selection; or selecting a piece of text for cut and paste. At home, my wife had to stop using xwinclip because of this. Could it be changed to not do this selection-clearing? I got the impression it was only done so that you knew the copy-to-Windows- clipboard action had happened. But I'm quite happy to take that on faith! At least, could there be a command line option to turn off this activity? luke
Re: wmaker signal 11
On 14 Oct, Harold L Hunt II wrote: > Did I build the wmaker package? I am guessing that I did... in that > case, I should be linking automode.o with the wmaker executable so that > we are not dependent upon binary mounts. Any objections? > > Harold Maybe ... I made a patch for WM that made sure to open all the files in binary mode. As far as I understand it, this means that that whether or not the file system is mounted as binary or text, the WM config files would always be written out in binary mode (i.e. just LF, no CR-LF). This patch was accepted into the post- wm 0.80.1 development version by the WM developers. SO I'd expect it to be fine when the next version is released. Would automode.o help or hinder all this? Note also that the config files are written out by the config program WPrefs, as well as by doing a Save Session from WM. What my WM patch does *not* fix is files that have been modified outside WM, and somehow get CR-LF line endings. *That* would be guaranteed to crash WM still. BTW, I currently have a temporary workaround for the problem - a WM exitscript that trims off the CRs. Might be worth mentioning my home page that tries to make Cygwin installation easy for novice users, coincidentally updated last night: http://members.optushome.com.au/lukekendall/xwin-network.html The post-install.sh script is quite nice, I think. I'd welcome comments and feedback about any of the above info. NOTE: don't run post-install.sh with the "-fresh" option that is recommended for new users if you already have your home directory set up. It does a mount -t $CYGDRIVE:\\home /home which might hide your existing home directory! We use a modified form of this to install Cygwin on all the Windows PCs at work now. It's taken years to get the okay to do this, and for Cygwin or U/Win to be as beautifully capable as they now are. Regards, luke > Gerald S. Williams wrote: > > >Vikram [mailto:[EMAIL PROTECTED]] wrote: > > > > > >>I downloaded cygwin afresh on a new box yesterday. For the first time > >>decided to try out wmaker.exe wmaker got signal 11 everytime I started. > >> > >> > > > >I had similar problems at first. I believe I had to switch > >to a binary mount point. Something like this: > > $ mount -f -s -b "C:/cygwin" "/" > > > >But make sure you know what you're doing before you try it. > > > >:-) > > > >-Jerry
xcb port to Cygwin; questions about packaging
xcb --- xcb gives GUI access to all the X cut buffers. I also find it useful to copy and paste between applications that `resist' the normal X11 selection and middle mouse pasting. On Monday, I compiled up xcb 2.3 for Cygwin. I've popped it onto my web page at http://members.optushome.com.au/lukekendall/useful/xcb.zip along with the man page and the original README file. I had to explicitly add $(XPMLIB) to the link line for xcb.exe in the Makefile constructed via xmkmf. I don't know enough about xmkmf to diagnose what actually went wrong. :-( I just found a good page on xcb here, if you want much better informat ion about it: http://www.goof.com/pcg/marc/xcb.html (I should probably build that internationalised version, instead, actually. Anyway, I've Bcc-ed the current maintainer this email too. Bcc so he should be safe from spamming eyes.) Packaging - BTW, http://www.cygwin.com/setup.html, but doesn't describe how to determine package names for the "required:" line when you're trying t o do the right thing and package stuff up for inclusion in Cygwin. (E.g. is X's package name "X" or "X11" or "XFree86"; what about normal system dependencies like cygwin.dll - what is their package name; etc. How do you find out?) I gather that since I had to kludge a fix, and since it is built by xmkmf; make rathern than by ./configure; make, and even then needed a fiddle, the only way to construct the necessary setup files for xcb for Cygwin would be via a hand-written shell script to run xmkmf then apply my kludge, which doesn't sound like an elegant solution! BTW, is it possible to run some utility that would automatically tell you what packages a utility depended on? How accurate do the package names have to be? Are they used in some automated process, or are they just rough guides for humans to see? I'm hoping that, like Window Maker, xcb will be found to be so useful that someone else will add it in as part of the XFree86 stuff for Cygwin. Window Maker news - Oh, I also patched and built Window Maker 0.80.1 (the latest release), and submitted my patches back to the WM developers, and they've been included. So, future builds of WM should be as simple as running ./configure; make; make install. (Then each user runs wmaker.inst in the usual way from a shell prompt to create the necessary files in their home directory.) luke
Re: twm iconmngr missing inputs
On 12 Sep, Harold L Hunt II wrote: > You now need to do three things before we can comment on your problem: > > 1) Run ``xev'' (X Event Viewer) before the problem occurs. Press a few > combinations of keys involving Ctrl, Shift, and some letters. Keep it > simple and document exactly what you push. Save the output of xev to a > file. > > 2) Run ``xev'' after the problem occurs but before you reboot. Repeat > the EXACT combinations of keys that you pressed above. Save this output > to another file. > > 3) Email the contents of both files into [EMAIL PROTECTED], along > with a description of which keys you pressed in which order. > > With that information we should be able to figure out what is going on. The problem that Dai reported sounds similar to a problem my wife has on her Win95 machine using Window Maker as the window mgr. Double- clicking on a title bar "rolls up" the window into just the title bar, clicking on a title bar focuses that window, etc. Every now and then all this stops working. Restarting X will correct it, but using a keyboard shortcut to cycle between the windows will also "unstick" X - and all the queued events flow through to all the windows affected (sometimes with unfortunate results, actually). The window with focus still accepts input while things are "stuck", so next time it happens we'll start up xev and see what we can learn. luke
Re: Window Maker crashing
In-Reply-To: <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> On 6 Sep, larsen587 wrote: > there is an bug in wmaker. They are storing property files in binary > mode and restoring them in text mode. Just check out the > sources, grep -lr for fopen, change the mode string of the property > related source file from "r" to "rb", and finally invoke *make". Actually, that's basically what I did for the port (except I did it for all open()s except popen()). I suspect the problem may be with libproplist - I recall that it's now separate from WM, and so I would not have applied the same mods to it; and it is used by WPrefs. The consequence is that after you use WPrefs.app to modify any of your look and feel preferences, the file ~/GNUstep/Defaults/WMState (and maybe WMWindowAttributes), gets written out with CR/LF and when you *next* start WM, it crashes. My 0-effort workaround was to modify ~/GNUstep/Library/WindowMaker/exitscript to convert the files back to Unix line endings via a utility called flip that I found via Google. I'll have to dig up my notes on compiling WM, since it's stopping with a complaint that _Xsetlocale is undefined, so I'll have to sort that out. And this time I'll track down liproplist and make the rb/wb changes there, too. luke
