public inbox for
help / color / mirror / Atom feed
From: <>
To: <>
Cc: <>
Subject: Re: 64-bit xfree86 failing?
Date: Thu, 04 Dec 2014 02:53:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.



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
> ________________________________
> From: Tim Kingman <>
> Sent: Tuesday, 2 December 2014 3:22 AM
> To:; 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
> 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
> /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:
Problem reports:

  reply	other threads:[~2014-12-04  2:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2014-12-02  4:34 ` l.wood
2014-12-04  2:53   ` l.wood [this message]
2015-02-02 15:49     ` Jon TURNEY
2014-12-01  9:49 l.wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).