working again. my mistake was in years of using
startx -- -multiwindow -clipboard & because /usr/bin/startx no longer starts x Once I switched to xinit -- -multiwindow -clipboard & I was fine. Remember that startx doesn't startx, on either 32- or 64-bit cygwin (I did a fresh 32-bit install and checked) and you're good to go. You'll still get complaints like XFree86_VT property unexpectedly has 0 items instead of 1 but at least you'll have a working xterm to type about them in. cheers L. On 2 Dec 2014, at 15:34, Wood L Dr (Electronic Eng) wrote: >> (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.king...@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/