This is the mail archive of the
cygwin-xfree
mailing list for the Cygwin XFree86 project.
Re: /usr/bin/startx fails on new x.org install?
- From: Lloyd Wood <L dot Wood at surrey dot ac dot uk>
- To: cygwin-xfree at cygwin dot com
- Cc: jon dot turney at dronecode dot org dot uk
- Date: Wed, 18 Feb 2009 17:19:57 +0000
- Subject: Re: /usr/bin/startx fails on new x.org install?
- Authentication-results: ams-dkim-2; header.From=L.Wood@surrey.ac.uk; dkim=neutral
- Reply-to: cygwin-xfree at cygwin dot com
Jon,
thanks for your /usr/bin/startx patch. (repeated as text below since the cygwin
mailing list bounces attachments, so probably didn't make it to the list.)
Applying your patch allows startx to run and launch X - but in full desktop mode,
rather than the multiwindow mode that startx did for me previously.
Trying:
startx -multiwindow
leads to:
xterm: bad command line option "xterm". Interesting.
startx -- -multiwindow
works as xinit does, but is non-obvious to the user. I'd expect startx
to default to multiwindow mode.
So, your patch is a step in the right direction, at least, handles spaces
correctly, and should certainly be committed to the codebase.
I'm using SaVi and Geomview under Cygwin/X and WinXP SP2 (a 2MB Thinkpad
T43). See:
<https://outlook2003.surrey.ac.uk/exchweb/bin/redir.asp?URL=http://savi.sf.net/>http://savi.sf.net/
The new X server has a nasty habit of dying horribly when I begin
using SaVi and Geomview - there's your test case. I can live without the
hardware acceleration - it's a good way of tightening SaVi's
geomview commands to remove redundant drawing and group drawing commands
together to remove unnecessary geomview updates - but other geomview users
will have a different view.
And only getting thirty seconds or so of use before the X server dies
and takes everything else with it is a showstopper for all of us.
Geomview now seems to be easier to build under the new Xserver regime -
./configure and make just work and do the right thing without command-line
nudges - but it's far less robust and reliable in use under the new
X server.
(I'm not getting cut/paste between Windows and xterms in
multiwindow mode, either. Entirely separate clipboards.)
thanks,
L.
<<https://outlook2003.surrey.ac.uk/exchweb/bin/redir.asp?URL=http://www.ee.surrey.ac.uk/Personal/L.Wood/>http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@surrey.ac.uk>
--- /usr/bin/startx 2009-01-19 06:43:41.001000000 +0000
+++ startx 2009-02-16 20:30:15.062500000 +0000
@@ -159,9 +159,9 @@
add :$dummy . $mcookie
EOF
+ serverargs=${serverargs}" -auth '"${xserverauthfile}"'"
- serverargs=${serverargs}" -auth "${xserverauthfile}
# now add the same credentials to the client authority file
@@ -193,9 +193,9 @@
+eval xinit \"$client\" $clientargs -- \"$server\" $display $serverargs
-xinit "$client" $clientargs -- "$server" $display $serverargs
-----Original Message-----
From: Jon TURNEY [<mailto:jon.turney@dronecode.org.uk>mailto:jon.turney@dronecode.org.uk]
Sent: Wed 2009-02-18 16:23
To: cc
Cc: Wood L Dr (Electronic Eng)
Subject: Re: /usr/bin/startx fails on new x.org install?
Lloyd Wood wrote:
>> Lloyd Wood wrote:
>>> XWin was started with the following command line:
>>>
>>> /usr/bin/X :0 -auth /cygdrive/c/Documents and
>>> Settings/lwood/.serverauth.3000
>>>
>>> ddxProcessArgument - Initializing default screens
>>> winInitializeDefaultScreens - w 1400 h 1050
>>> winInitializeDefaultScreens - returning
>>> Unrecognized option: and
>>> [..]
>> This isn't X-specific; spaces and *NIX paths don't mix.
>
> Tell that to any Mac OS X user.
>
>> Please use a
>> sane home directory, like /home/lwood.
>
> startx used to work. Now, it doesn't. Ergo, like lack of opengl hardware acceleration, it can be argued that it's a regression in functionality. (I have to keep files under Documents\ and\ Settings. That has worked fine for for startx the last eight years. Now, it's broken.)
>
> handling of paths has been broken, due to lame programming practices. it needs to be fixed.
Thanks for identifying this as a regression. I wasn't sure if this used to
work or not.
I think that the attached patch for startx should fix this problem, if you
wouldn't mind testing it.
>>> 4. Hogging and not freeing menu/window resources in X, as my Insight Tcl
>>> program failing with 'unable to register Tk TopLevel class' or failing to
>>> draw a window properly indicates:
>>> <https://outlook2003.surrey.ac.uk/exchweb/bin/redir.asp?URL=http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2008-04/msg00769.html>http://coding.derkeiler.com/Archive/Tcl/comp.lang.tcl/2008-04/msg00769.html
>>> yes, Insight Tcl programs can be run without X being launched. But I have to
>>> quit X (desktop or multiwindow mode) to pull down and draw a menu in
>>>> e.g. the mail program where I'm writing this.
>> Cygwin's Tcl/Tk is currently Windows based, and this message is clearly
>> talking about a Windows version of Tcl/Tk. I don't see what that has to
>> do with X11?
>
> I'm walking you through visible symptoms, diagnosis, and explanation. the new
> Xserver is demonstrably a resource hog, in that it interferes with normal
> Windows operation.
Too bad you're not providing us with the solution as well :-)
I tried some brief experiments with the Dheapmon tool, but I didn't see any
obvious leaking and wasn't able to hit this Windows resource limit - the
desktop heap was only 50% full with 50 xterms, and then I hit some other limit
in cygwin.... ('open ttydev: No such file or directory'), so a few more
details about how to reproduce this problem would be very helpful.
It might be also helpful if you mentioned which particular version of windows
you are using, as I would guess they don't all behave the same in this regard.
--
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/