Re: 64-bit xfree86 failing?
On 04/12/2014 02:53, l.w...@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?
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/
64-bit xfree86 failing?
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 0015 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: 00ff ff00 00ff 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: 0409 (0409) 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
I see the same issue, and it looks like this is because I have an empty (commented-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 command therein must be run in the foreground, and that command's exiting will end the X session, just like with startx and ~/.xinitrc or ~/.Xclients. This causes another problem for me because my .bashrc calls startxwin to make 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 infinitely (probably from startxwin now finding a new DISPLAY, and if I specify both :0 and -silent-dup-error, XWin still writes an error to the console that display 0 is already active, and displays a Windows dialog with an error about not being able to move XWin.0.log to XWin.0.log.old ). I'll keep playing with this to see if I can come up with a solution 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 shells don't pop up any 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
On 12/1/2014 8:35 AM, Tim Kingman wrote: I see the same issue, and it looks like this is because I have an empty (commented-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 command therein must be run in the foreground, and that command's exiting will end the X session, just like with startx and ~/.xinitrc or ~/.Xclients. This causes another problem for me because my .bashrc calls startxwin to make 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 infinitely (probably from startxwin now finding a new DISPLAY, and if I specify both :0 and -silent-dup-error, XWin still writes an error to the console that display 0 is already active, and displays a Windows dialog with an error about not being able to move XWin.0.log to XWin.0.log.old ). I'll keep playing with this to see if I can come up with a solution 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 shells don't pop up any display already exists errors. Thanks, Tim Tim, Are you opposed to having the X Server start when you log into the Windows machine? This is what I do and it works well. The X server is always running when I need it. I created a desktop shortcut with the following command: C:\Apps\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -emulate3buttons 100 -multiwindow -clipboard -swcursor and then just place that shortcut in the programs - startup start menu folder. -- 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
On Mon, Dec 1, 2014 at 3:32 PM, Mark Hansen m...@winfirst.com wrote: On 12/1/2014 8:35 AM, Tim Kingman wrote: *snip* my .bashrc calls startxwin to make sure I always have an X server running ( per http://stackoverflow.com/a/9301966 ) *snip* I'll keep playing with this to see if I can come up with a solution 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 shells don't pop up any display already exists errors. Thanks, Tim Tim, Are you opposed to having the X Server start when you log into the Windows machine? This is what I do and it works well. The X server is always running when I need it. I created a desktop shortcut with the following command: C:\Apps\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe -- -emulate3buttons 100 -multiwindow -clipboard -swcursor and then just place that shortcut in the programs - startup start menu folder. Mark, That's probably what I should be doing to start the X server. That would avoid the dup-error warnings, and I can manually restart the server if it dies. But I think this method won't work with xinit 1.3.4, because startxwin.bat from xinit 1.3.4 no longer leaves the X server running after the last command in .startxwinrc (or the default xterm) exits. Another request for this: https://cygwin.com/ml/cygwin-xfree/2014-11/msg00039.html with a suggestion to run sleep from .startxwinrc. I haven't tried that yet, but that may be the best option for now. 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?
(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/
