64-bit xfree86 failing?

64-bit xfree86 failing?

[l.wood]

Just updated a fairly recent was-working two-months-old 64-bit cygwin install. (Asus X102BA, Win 8.1 - just a little AMD netbook.)

XFree86 now failing with the below. Ideas? thanks.


(--) Windows reports only 2 mouse buttons, defaulting to -emulate3buttons
(II) xorg.conf is not supported
(II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
LoadPreferences: /home/Lloyd/.XWinrc not found
LoadPreferences: Loading /etc/X11/system.XWinrc
LoadPreferences: Done parsing the configuration file...
winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
winDetectSupportedEngines - Returning, supported engines 00000015
winSetEngine - Using Shadow DirectDraw NonLocking
winScreenInit - Using Windows display depth of 32 bits per pixel
winWindowProc - WM_SIZE - new client area w: 1350 h: 689
winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
MIT-SHM extension disabled due to lack of kernel support
XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
(EE) AIGLX: No native OpenGL in modes with a root window
(II) AIGLX: enabled GLX_EXT_texture_from_pixmap
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
winPointerWarpCursor - Discarding first warp: 675 344
(--) 2 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "00000409" (00000409) "US", type 7
(--) Found matching XKB configuration "English (USA)"
(--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
winProcEstablishConnection - winInitClipboard returned.
winClipboardThreadProc - DISPLAY=:2.0
OS maintains clipboard viewer chain: yes
winClipboardProc - XOpenDisplay () returned and successfully opened the display.
xinit: XFree86_VT property unexpectedly has 0 items instead of 1
xinit: connection to X server lost

waiting for winClipboardProc - winClipboardFlushWindowsMessageQueue trapped WM_QUIT message, exiting main loop.
winClipboardProc - XDestroyWindow succeeded.
X server to shut down winDeinitMultiWindowWM - Noting shutdown in progress
(EE) Server terminated successfully (0). Closing log file.

Lloyd Wood
http://about.me/lloydwood
--
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/

Re: 64-bit xfree86 failing?

[Jon TURNEY]

On 04/12/2014 02:53, l.wood@surrey.ac.uk wrote:
> working again.
>
> my mistake was in years of using
>
> startx -- -multiwindow -clipboard &
>
> because /usr/bin/startx no longer starts x

I'm kind of surprised this used to work at all, since this is requesting 
both the internal multiwindow mode window manager, and whatever default 
window manager xinitrc decides to run.

Sorry about breaking that.

If you want a multiwindow mode session, the documented way to start it 
would be using startxwin, or the Start Menu link we provide to run that 
(See [1])

-clipboard has been the default for a number of years now, you don't 
need to explicitly provide it.

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

I think that you will find that running 'startx' without options does work.

While I'm sure sarcasm is very relieving for you, please don't use it here.

[1] http://x.cygwin.com/docs/ug/using.html#using-starting-exe

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

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

Re: 64-bit xfree86 failing?

[l.wood]

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/

Re: 64-bit xfree86 failing?

[l.wood]

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