Re: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
My solution was to write a quick C program that does nothing but block
on waiting to receive any signal. I named it 'xnoexit' and I call it
from my .startxwinrc script in my home directory. It's been working
well for me. Sorry - I'm extra picky. I didn't like seeing a
'sleep' in my 'ps' list. Now I see 'xnoexit' and I know exactly
what's going on. :)
---cut
#include signal.h
main (argc, argv) int argv; int *argc[];
{
sigset_t myset;
(void) sigemptyset(myset);
while (1) {
(void) sigsuspend(myset);
}
}
---cut
On Fri, Dec 5, 2014 at 7:35 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote:
On 29/11/2014 20:19, Nem W Schlecht wrote:
On Fri, Nov 28, 2014 at 8:46 PM, Marco Atzeri wrote:
On 11/29/2014 3:05 AM, Nem W Schlecht wrote:
* 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.
In most UNIX systems, this last command would be the window manager.
I'm not liking fbpanel (although I will give it a try) and I don't
like using an XTerm as my last command, since I often close/reopen
them all when making changes to my .bashrc/.bash_profile.
Are there any suggestions from the list for some *other* program that
won't use any resources that I can use as my final foreground command?
I don't want it to do anything, just not let X11 exit.
I just want X11 to *not*
launch fbpanel and to *not* quit. For now, I've settled on just
calling 'sleep' for 10 years.
If you previously had an empty ~/.startxwinrc, I'd suggest putting 'sleep
infinity' or even 'exec sleep infinity' into it.
--
Nem W Schlecht
--
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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
Yes, but both of those are applications that have an icon, display a window, etc. I don't want any of that. I just want X11 to *not* launch fbpanel and to *not* quit. For now, I've settled on just calling 'sleep' for 10 years. For now, I've settled on On Fri, Nov 28, 2014 at 8:46 PM, Marco Atzeri marco.atz...@gmail.com wrote: On 11/29/2014 3:05 AM, Nem W Schlecht wrote: In reference to: * 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. In most UNIX systems, this last command would be the window manager. I'm not liking fbpanel (although I will give it a try) and I don't like using an XTerm as my last command, since I often close/reopen them all when making changes to my .bashrc/.bash_profile. Are there any suggestions from the list for some *other* program that won't use any resources that I can use as my final foreground command? I don't want it to do anything, just not let X11 exit. xclock and xeye should be light enough Regards Marco -- Nem W Schlecht -- 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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
I had never used/run/heard of fbpanel before this release. I was seeing the same blank bar and had to do as you suggested: cp -f /usr/share/fbpanel/multiwindow ~/.config/fbpanel/ To get anything useful. Might want to add this command as part of the installation process (with a simple file check to make sure ~/.config/fbpanel/multiwndow doesn't exist before copying, of course). On Sat, Nov 29, 2014 at 10:02 PM, Yaakov Selkowitz yselkow...@cygwin.com wrote: On 2014-11-28 16:53, Ken Brown wrote: On 11/27/2014 10:03 PM, Yaakov Selkowitz wrote: * The new default startxwinrc also launches a miniature fbpanel in the upper left corner of the screen which contains an XDG application menu (the 'X' icon) for launching X applications, plus an on-demand area for X tray icons. After the first run, the panel and menu can be customized in ~/.config/fbpanel/multiwindow. This is not working well for me. I've tested on both 32-bit and 64-bit Cygwin with no .startxwinrc and no .[xX]* files, and I've tested on two different computers (both running Windows 7). I started the X server via the new start menu shortcut. What happens is that a band appears across the bottom of the screen (full width), hiding about 2/3 of the taskbar. This makes it impossible to access the icons on the right side of the taskbar. Also, there's no X icon in the upper left corner of the screen. But there is a large X icon in the taskbar, partially visible above the band, and when I mouse over it, I see a little window that says X panel. Closing this window makes the band go away. So I guess this band is the miniature fbpanel referred to above, but it's appearing in the wrong place. It does sound that way. Finally, ~/.config/fbpanel/multiwindow exists but is empty. I can't reproduce this. Do you have fbpanel-6.1-4? (The earlier releases from Ports do not include the multiwindow profile.) If you rm ~/.config/fbpanel/multiwindow, does it work after that? If not, if you 'cp -f /usr/share/fbpanel/multiwindow ~/.config/fbpanel/', does it work then? -- Yaakov -- 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/ -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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: [ANNOUNCEMENT] Updated: xinit-1.3.4-1 (Major overhaul of X session handling)
In reference to: * 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. In most UNIX systems, this last command would be the window manager. I'm not liking fbpanel (although I will give it a try) and I don't like using an XTerm as my last command, since I often close/reopen them all when making changes to my .bashrc/.bash_profile. Are there any suggestions from the list for some *other* program that won't use any resources that I can use as my final foreground command? I don't want it to do anything, just not let X11 exit. On Thu, Nov 27, 2014 at 9:03 PM, Yaakov Selkowitz yselkow...@cygwin.com wrote: The following package has been updated in the Cygwin distribution: * xinit-1.3.4-1 xinit contains commands used for starting X sessions. This is an update to the latest upstream release, and includes a number of major changes to X session handling: * startxwin is now a shell script instead of an executable; if you have any homemade links thereto, be sure to remember the .exe extension. * startxwin now automatically finds an unused DISPLAY number, just like startx. * startxwin now includes a default startxwinrc (if ~/.startxwinrc is absent) which launches a number of applicable autostart session services if present. * The new default startxwinrc also launches a miniature fbpanel in the upper left corner of the screen which contains an XDG application menu (the 'X' icon) for launching X applications, plus an on-demand area for X tray icons. After the first run, the panel and menu can be customized in ~/.config/fbpanel/multiwindow. * 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. * Both startx and startxwin now start a D-Bus session bus automatically. * X sessions (both multwindow and desktop) started with the newly revised Start Menu shortcuts now log stderr to ~/.xsession-errors. * startx now prefers ~/.Xclients (which must also be executable) instead of ~/.xinitrc; the latter can still be used, but doing so will override many of the new features mentioned here. * If startx is run from the command line and neither ~/.xinitrc nor ~/.Xclients are present, it will try to start a real desktop environment if present before falling back to twm/xterm. * startx and startxwin now pass '-nolisten tcp' to the server by default, which increases security in the X server by not opening a port to TCP connections. The '-listen' flag can be passed as a server argument to override this. -- Yaakov Cygwin/X -- 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/ -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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/
Clipboard error - trace owner?
After a *very* long time of the clipboard working perfectly, it just started to stop working on me: [252960.192] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [252960.192] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [253010.517] winWindowProc - WM_DISPLAYCHANGE - new width: 1600 new height: 1200 new bpp: 32 [253380.957] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e [253445.199] winClipboardFlushXEvents - OpenClipboard () failed: 0005 Owner 0002089e How do I trace the owner HEX code to the program that is causing the issue? (Or is the owner X11 here?) -- Nem W Schlecht -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.16.1-2
Just to confirm - I haven't had any crashes with 1.16.1-2 so far. Woot! :) On Wed, Oct 8, 2014 at 11:08 PM, Chris Carlson cwcarls...@cox.net wrote: No sooner did I respond than I see the update. Nevermind. Chris Carlson On 10/8/2014 8:31 PM, Nem W Schlecht wrote: I just remembered that my version of xv has been modified to place the current image filename in the X11 clipboard. That might have been the cause of the issue. Regardless, my crashes seem to have gone away with this update. Thanks for all the hard work on Cygwin X11! On Wed, Oct 8, 2014 at 3:09 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.16.1-1: * Fix transposed format specifiers in some logging added in 1.16.1-1, which is probably the cause of some crashes/hangs (Thanks to Colin Harrison for patch) x86: 2487d4ffba759b3023150298d53616e7 *xorg-server-1.16.1-2-src.tar.xz fba03eb030540c292188c736f410ab77 *xorg-server-1.16.1-2.tar.xz e988cd1a540f3b5a4ebc44619ca340fd *xorg-server-common-1.16.1-2.tar.xz 9b4ccf2d47947820eded95dcc4e855b8 *xorg-server-debuginfo-1.16.1-2.tar.xz 369e9a8ef1d80225d742dec17e69b88e *xorg-server-devel-1.16.1-2.tar.xz a091007b24dd1ae64d4a80be5a3ea279 *xorg-server-dmx-1.16.1-2.tar.xz ba1e3a9cbd7ffe4834b7387a09169528 *xorg-server-extra-1.16.1-2.tar.xz d19cd8a9cd65657c20af1c0f440cd40f *xwinclip-1.16.1-2.tar.xz x86_64: 78666e1511ce24b8786d4cc2697ca71d *xorg-server-1.16.1-2-src.tar.xz de105c6b353d0bc98493a80bc1bfe9d5 *xorg-server-1.16.1-2.tar.xz 5f8b3f6b6c63c7e99bf35a966a5b5252 *xorg-server-common-1.16.1-2.tar.xz 395931026c9f63d7cac23ac433931527 *xorg-server-debuginfo-1.16.1-2.tar.xz 4cfc2b7aac8e7ab18329303f3b378f42 *xorg-server-devel-1.16.1-2.tar.xz 8fa287196a578e4eeb2e8ec57bccf9a9 *xorg-server-dmx-1.16.1-2.tar.xz ae1207c3b901cbb0da96eaf55ff9c8be *xorg-server-extra-1.16.1-2.tar.xz 51a9cb28eaab5ae481aaa45283554e7f *xwinclip-1.16.1-2.tar.xz -- 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/ -- 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/ -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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/
X11 crashing - no errors in log file
X11 has been crashing on me in 2 cases since upgrading to 1.16.1-1 1) Using 'xv' on any image. I compiled this myself and it was running fine in the past, but now when I try to open any image, all of X11 crashes. I tried to recompile it, but same issue. Nothing is showing up in the XWin.0.log 2) Using 'rdesktop' to a remote Windows host and then selecting and hitting 'Ctrl-C' on a list of files. About 2 seconds after the Ctrl-C, X11 crashes (again, nothing in XWin.0.log). Is there additional debugging I can turn on to try to catch the error that is happening? -- Nem W Schlecht -- 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: [ANNOUNCEMENT] Updated: xorg-server-1.16.1-2
I just remembered that my version of xv has been modified to place the current image filename in the X11 clipboard. That might have been the cause of the issue. Regardless, my crashes seem to have gone away with this update. Thanks for all the hard work on Cygwin X11! On Wed, Oct 8, 2014 at 3:09 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: The following packages have been updated in the Cygwin distribution: *** xorg-server-*1.16.1-2 These packages contain XWin and the other X.Org X11 servers. The following cygwin-specific changes have been made since 1.16.1-1: * Fix transposed format specifiers in some logging added in 1.16.1-1, which is probably the cause of some crashes/hangs (Thanks to Colin Harrison for patch) x86: 2487d4ffba759b3023150298d53616e7 *xorg-server-1.16.1-2-src.tar.xz fba03eb030540c292188c736f410ab77 *xorg-server-1.16.1-2.tar.xz e988cd1a540f3b5a4ebc44619ca340fd *xorg-server-common-1.16.1-2.tar.xz 9b4ccf2d47947820eded95dcc4e855b8 *xorg-server-debuginfo-1.16.1-2.tar.xz 369e9a8ef1d80225d742dec17e69b88e *xorg-server-devel-1.16.1-2.tar.xz a091007b24dd1ae64d4a80be5a3ea279 *xorg-server-dmx-1.16.1-2.tar.xz ba1e3a9cbd7ffe4834b7387a09169528 *xorg-server-extra-1.16.1-2.tar.xz d19cd8a9cd65657c20af1c0f440cd40f *xwinclip-1.16.1-2.tar.xz x86_64: 78666e1511ce24b8786d4cc2697ca71d *xorg-server-1.16.1-2-src.tar.xz de105c6b353d0bc98493a80bc1bfe9d5 *xorg-server-1.16.1-2.tar.xz 5f8b3f6b6c63c7e99bf35a966a5b5252 *xorg-server-common-1.16.1-2.tar.xz 395931026c9f63d7cac23ac433931527 *xorg-server-debuginfo-1.16.1-2.tar.xz 4cfc2b7aac8e7ab18329303f3b378f42 *xorg-server-devel-1.16.1-2.tar.xz 8fa287196a578e4eeb2e8ec57bccf9a9 *xorg-server-dmx-1.16.1-2.tar.xz ae1207c3b901cbb0da96eaf55ff9c8be *xorg-server-extra-1.16.1-2.tar.xz 51a9cb28eaab5ae481aaa45283554e7f *xwinclip-1.16.1-2.tar.xz -- 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/ -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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: Clipboard interaction issues - breaks after awhile
Thanks so much for getting back to me, Jon. nxterm is Nem's Xterm - I've just recompiled xterm with some minor configuration differences. I backed out to 1.15.1-4 and rebooted and since then I have *not* had the issue, so I'm wondering if the reboot is needed for some reason. I'll be upgrading to 1.16.0-2 today and will reboot and test. Like you mention, I assume its one of my *Windows* apps that is really the cause of the issue. Not sure which one, though, if that's the case. If it comes back up again, I'll shoot out another note to the list. On Fri, Sep 19, 2014 at 8:46 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 10/09/2014 18:57, Nem W Schlecht wrote: That 'nedit' thread looks pretty old. Cut/Paste was working perfectly for me pre-1.16.0-1. I've decided to downgrade, as I was having zero issues with 1.15.1-4. I can see I'm getting winClipboardFlushXEvents errors in my XWin.0.log file (attached). First, multiple time out events after trying Conversion to format 242 refused. and then later OpenClipboard () failed: 0005 errors. On Wed, Sep 10, 2014 at 12:17 PM, mathog wrote: On 10-Sep-2014 09:33, Nem W Schlecht wrote: After the latest update to xorg-server (1.16.0-1), I've been having issues with clipboard interaction between my xterm windows and Windows apps. Bi-directional copy/paste works initially, but at some unknown point stops working. Anybody else seeing this as well? What can I do to help debug this issue? Thanks for reporting this problem, and the log file. Unfortunately, I can't reproduce this problem. winClipboardFlushXEvents - SelectionNotify - Conversion to format 242 refused. winClipboardWindowProc - timed out waiting for WIN_XEVENTS_NOTIFY_TARGETS I think the log timestamps indicate this occurs approximately 9 hours after the server was started. I guess that that format 242 is 'TARGETS' (The value of the atom will vary depending on circumstances. You could check with 'xlsatoms | grep 242'), in which case this means that something went wrong when asking the X client what conversion formats are supported for the selection, which is odd. I also notice an 'nxterm' process is started. Is this a wrapper for xterm, or some other terminal program? But are these errors actually correlated with your problem? About a day later we have: winClipboardFlushXEvents - SelectionRequest - OpenClipboard () failed: 0005 0005 is 'access denied', which typically means that the X server can't take ownership of the clipboard, because some other Windows program isn't letting go of it. On 10/09/2014 22:23, Nem W Schlecht wrote: Hmm.. I might have to reboot. I went back to 1.15.1-4 and everything was fine, but now its not working again and same errors as before. :( There should be no clipboard-related changes between 1.15.1-4 and 1.16.0-1, so perhaps something else changing is the cause of this problem? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Nem W Schlecht -- 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/
Clipboard interaction issues - breaks after awhile
After the latest update to xorg-server (1.16.0-1), I've been having issues with clipboard interaction between my xterm windows and Windows apps. Bi-directional copy/paste works initially, but at some unknown point stops working. Anybody else seeing this as well? What can I do to help debug this issue? -- Nem W Schlecht -- 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: Clipboard interaction issues - breaks after awhile
Hmm.. I might have to reboot. I went back to 1.15.1-4 and everything was fine, but now its not working again and same errors as before. :( On Wed, Sep 10, 2014 at 1:34 PM, mathog mat...@caltech.edu wrote: On 10-Sep-2014 10:57, Nem W Schlecht wrote: That 'nedit' thread looks pretty old. Sadly, yes. Fixing it seems to be nobody's priority. Regards, David Mathog mat...@caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech -- 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/ -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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: xterm crashing when trying to access Ctrl-mouse click menu items
Thanks for the reply, Jon! I'm happy you were able to reproduce the issue - I assumed I had screwed something up in my environment. :) Your attempted fix with rebase worked perfectly - all of my menus are now working correctly. If you'd like me to do any additional testing in the future, don't hesitate to ask. On Mon, May 12, 2014 at 5:34 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 05/05/2014 19:39, Nem W Schlecht wrote: For over a month now I've been having issues with my xterms in Cygwin. If I try to access *any* menu item under the Ctrl-mouse button menu items (change font, turn on/off scrollbar, redraw window, etc.), my xterm crashes the moment I un-press my mouse button. I don't access them all that often, so I don't know how long the issue has been around, but it's been a couple of months now. I've tried launching it with an empty .Xdefaults file (home dir) and by moving my .bashrc/.bash_profile files out of the way - still the same result. I've also gone out and downloaded the latest XTerm code and have a version compiled with debugging, but my C skills are really rusty and I'm not seeing anything terribly useful in gdb (I set my CYGWIN env var to error_start=dumper -d %1 %2 so I would get core dumps). I compiled a version with a different DEFCLASS set so that I *know* it's not a bad resource or resource file. I'm running 64 bit on Windows 7. More details in the attached cygcheck.out. Anybody else on 64bit Cygwin / Win 7 having the same issues? Thanks for reporting this issue. I can reproduce it. This appears to be an issue with Xt, as a Cygwin-specific patch does not work correctly on x86_64 when another DLL which is using Xt is loaded 2GB away from it. Until we have a fix, you *might* be able to work around this by rebasing the DLLs, e.g. in the specific case of xterm, which uses Xaw: cd /usr/bin rebase -v -b 0x4 cygXt-6.dll rebase -v -b 0x41000 cygXaw-7.dll -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Nem W Schlecht n...@emptec.com Empyreal Technologieshttp://www.emptec.com/ Perl did the magic. I just waved the wand. -- 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/
