Re: 64-bit xfree86 failing?

[<l dot wood at surrey dot ac dot uk>]

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.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/