This is the mail archive of the
cygwin-xfree
mailing list for the Cygwin XFree86 project.
Re: 64-bit xfree86 failing?
- From: <l dot wood at surrey dot ac dot uk>
- To: <tim dot kingman at gmail dot com>
- Cc: <l dot wood at surrey dot ac dot uk>, <cygwin-xfree at cygwin dot com>
- Date: Tue, 2 Dec 2014 04:34:18 +0000
- Subject: Re: 64-bit xfree86 failing?
- Authentication-results: sourceware.org; auth=none
- References: <CAGZ6-67PP2LhWeeH6qGyNBfPJXmckWGyx3-s131O61QoGR66UQ at mail dot gmail dot com>
- Reply-to: cygwin-xfree at cygwin dot com
> (Resending because qmail can't handle mime)
I don't have a ~/.startxwinrc file, because the account home directory was created without one.
Creating one, making it executable, adding commands to it makes no difference - the X server launches (--muiltiwindow or not) and then decides to shut down.
Do not update your cygwin installations, would be my advice.
Lloyd Wood
http://about.me/lloydwood
________________________________
From: Tim Kingman <tim.kingman@gmail.com>
Sent: Tuesday, 2 December 2014 3:22 AM
To: cygwin-xfree@cygwin.com; Wood L Dr (Electronic Eng)
Subject: Re: 64-bit xfree86 failing?
I see the same issue, and it looks like this is because I have an empty (co=
mmented-out) ~/.startxwinrc
Removing this file causes X to open and start an xterm, probably because it=
broke several of the new rules in https://cygwin.com/ml/cygwin-xfree/2014-=
11/msg00029.html:
* User-defined ~/.startxwinrc files must now be executable, the final comma=
nd therein must be run in the foreground, and that command's exiting will e=
nd the X session, just like with startx and ~/.xinitrc or ~/.Xclients.
This is then another problem for me because my .bashrc calls startxwin to m=
ake sure I always have an X server running ( per http://stackoverflow.com/a=
/9301966 ), and then I get caught in a loop of launching new X servers infi=
nitely (probably from startxwin now finding a new DISPLAY, and specifying b=
oth :0 and -silent-dup-error doesn't seem to silence the error that :0 alre=
ady exists). I'll keep playing with this to see if I can come up with a sol=
ution to duplicate my previous behavior: Any new bash shell makes sure that=
X is running, with no X apps running, and only one X is running, and new s=
hells don't cause "display already exists" errors.
Thanks,
Tim
--
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/