From kare.edvardsen@uit.no Tue Nov 1 08:22:00 2011 From: kare.edvardsen@uit.no (=?utf-8?B?RWR2YXJkc2VuIEvDpXJl?=) Date: Tue, 01 Nov 2011 08:22:00 -0000 Subject: Default settings for XTerm Message-ID: <1320135692.5480.54.camel@kare-desktop> On Mon, 31 Oct 2011, Eliot Moss wrote: On 10/31/2011 3:45 PM, Eliot Moss wrote: I think that's "customization: -color" (note the dash), but yes :-) ... Eliot Moss Sheesh, I also typed it wrong, corrected above! EM :-) I think I'll find it :) Cheers, K?re From jon.turney@dronecode.org.uk Tue Nov 1 13:52:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Tue, 01 Nov 2011 13:52:00 -0000 Subject: -nolisten tcp -multiwindow combination crashes in XWin startup In-Reply-To: <1320088928.33967.YahooMailNeo@web114410.mail.gq1.yahoo.com> References: <1319954770.81475.YahooMailNeo@web114412.mail.gq1.yahoo.com> <4EAEB486.5090002@dronecode.org.uk> <1320088071.46008.YahooMailNeo@web114420.mail.gq1.yahoo.com> <1320088928.33967.YahooMailNeo@web114410.mail.gq1.yahoo.com> Message-ID: <4EAFF999.7010301@dronecode.org.uk> On 31/10/2011 19:22, Dave wrote: > Sadly this one wants to play a little hard to get... > > I have tried this on two somewhat similar machines - 5 years difference in hardware, but both XP Pro up-to-date on Microsoft Update, and both running the cygwin versions present on mirror.mcs.anl.gov as of this weekend - both were upgraded, then after both were, I checked that there were no further upgrades posted in between. The two differ regarding which packages are present, but for those present, they'd seem to be at the same versions. > > One shows this problem quite consistently, the other doesn't show it at all. It's the newer one, which has a good amount of memory to spare and is usually the more reliable these days, that is showing the problem. > > I can recreate the problem at will on the one that shows it by starting XWin at the command line directly, under xinit, or under startxwin. But if I try to start XWin under gdb, I don't see the problem; see below. (The page you pointed me to suggests attaching gdb after startup, but that doesn't seem reasonable in this case.) > > I notice in the output from starting XWin at the command line there's the line > 3 [main] XWin 4520 fork: child 5408 - died waiting for dll loading, errno 11 > I didn't see this output or captured in /var/log/xwin/XWin.0.log when I ran via xinit or startxwin. I don't know if that line got generated but lost in output redirections, or if this way of starting X is maybe seeing yet a different problem. This line seems similar to that reported by Denis Beauchemin, Wed, 19 Oct 2011 14:17:54 +0000. Yes, this line is output directly by the cygwin DLL, so you won't see it in XWin.0.log This output is typical of some other software causing cygwin problems with fork emulation, see [1] and [2] in the FAQ. > Any suggestions re how else to get the backtrace you desire, or any other info that might be helpful? You may be able to get something useful using the JIT debugger, by setting the error_start token in the CYGWIN env var, prior to invoking the command which crashes, e.g. CYGWIN="error_start=C:\cygwin\bin\dumper" CYGWIN="error_start=C:\cygwin\bin\gdb" > The below were run within a shell within Emacs running on an X server other than :0. The behavior looks the same as when running in a Windows CMD shell, except here the XWin output seems to be printing locally rather than going to XWin.0.log. The "@@@@@@@"s are hand-edited whiteouts. > > The note below about Zonealarm is "interesting". No Zonealarm, tho do have McAfee's firewall enabled. Apparently cygcheck detects ZoneAlarm by looking for the registry key "SYSTEM\\CurrentControlSet\\Services\\vsdatant", or the file "%windir%\\System32\\vsdatant.sys". > The run under gdb seemed to startup ok; I closed up X after a little while via "Exit..." on the taskbar icon. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-fork-failures [2] http://cygwin.com/faq-nochunks.html#faq.using.bloda -- 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/ From jofferman@gmail.com Tue Nov 1 17:58:00 2011 From: jofferman@gmail.com (J. Offerman) Date: Tue, 01 Nov 2011 17:58:00 -0000 Subject: wglext.h In-Reply-To: <4EAEA60D.5070301@dronecode.org.uk> References: <4EADABED.5060309@dronecode.org.uk> <4EAEA60D.5070301@dronecode.org.uk> Message-ID: FYI, I also had to specify --disable-unit-test to finish compiling successfully. Thanks for your help. I really appreciate your perpetual efforts on this. I admire you. People should worship you. If I were 20 years younger with a tank full of energy... :-) On Mon, Oct 31, 2011 at 6:43 AM, Jon TURNEY wrote: > On 31/10/2011 03:33, J. Offerman wrote: >> >> Okay, I went with --disable-aiglx, and it moved on, but I got this at >> the very last stage of the build process: >> >> >> ? CCLD ? XWin.exe >> ../../glx/.libs/libglx.a(glxcmds.o): In function `FlushContext': >> >> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:219: >> undefined reference to `__glapi_tls_Dispatch' >> ../../glx/.libs/libglx.a(glxcmds.o): In function `DoMakeCurrent': >> >> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:598: >> undefined reference to `__glapi_tls_Dispatch' >> ../../glx/.libs/libglx.a(glxcmds.o): In function `__glXDisp_WaitGL': >> >> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:767: >> undefined reference to `__glapi_tls_Dispatch' >> ../../glx/.libs/libglx.a(glxcmds.o): In function `__glXDisp_CopyContext': >> >> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:864: >> undefined reference to `__glapi_tls_Dispatch' >> ../../glx/.libs/libglx.a(glxcmds.o): In function `__glXDisp_SwapBuffers': >> >> /usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:1578: >> undefined reference to `__glapi_tls_Dispatch' >> >> ../../glx/.libs/libglx.a(glxcmds.o):/usr/src/xorg-server-1.11.1-1/src/xserver-cygwin-1.11.1-1/glx/glxcmds.c:1777: >> more undefined references to `__glapi_tls_Dispatch' follow >> collect2: ld returned 1 exit status >> make[4]: *** [XWin.exe] Error 1 >> >> >> Who has "__glapi_tls_Dispatch"? > > The short answer is ./configure with --disable-glx-tls > > (In general I would suggest always looking at the .cygport file and checking > you understand if you need to use the configuration options used there :-) > > Slightly longer answer is because XWin links with mesa's libGL to provide > the glapi functions (to avoid other problems which PE/COFF linkage causes > us), XWin needs to be built with the same TLS-ness as libGL. ?Since X server > 1.10, X has changed from disabling TLS by default to autodetecting if TLS is > available, but mesa doesn't build with TLS enabled on cygwin for reasons I > never got around to looking into... > > -- > 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/ From rpavlik@iastate.edu Tue Nov 1 20:40:00 2011 From: rpavlik@iastate.edu (Ryan Pavlik) Date: Tue, 01 Nov 2011 20:40:00 -0000 Subject: Built XWin on mingw - with patches Message-ID: All, Not sure if this is the right forum for this, but it seemed more specific and probably more appropriate than the overall xorg lists. I wanted to build a native windows X server (essentially an open-source Xming). I had to patch a number of the packages along the way, but did eventually arrive at a build that worked. ?I looked at and used a few of the Xming patches, but only generally went to those when the naive approach didn't work. I'm looking for some feedback on the patches so that they can get into the main line of the projects. I built using mingw-cross-env, with my fork here that includes the dependency packages:?https://bitbucket.org/rpavlik/mingw-cross-env/ This builds everything except the xorg-server module (ignore the fact there's an xorg-server makefile there - the patches aren't up to date for that module.) Patches for these dependencies are as follows, in that mingw-cross-env repo (These should all have commit messages from being exported from git format-patch): libX11-1-add-xwinsock-include,?libX11-2-windows-threads, libX11-3-MinGW-lacks-caddr_t libXaw-1-need-winsock libXfont-1-dummy-readlink libxcb-1-fix-include-order-with-Xdmcp,?libxcb-2-wsastartup?- this last one fixes running libX11 apps built for Windows, including the integrated multi-window WM. xkbcomp-1-Use-X11-Xwindows.h,?xkbcomp-2-Look-in-windows-base-dir-too?- this last one supports the "RELOCATE_PROJECTROOT" option in the XWin server - should still work fine in the normal case though. Then, the xorg-server is here: https://github.com/rpavlik/Xserver/commits/patched-1.11-branch I've tried to make the commits independent, atomic changes. (For some of the patches from XMing, this does mean that I split some patches, and combined some from multiple files, since those patches are offered per-file, not per-topic.) With this, I can run in -rootless or default mode (metacity over ssh forwarding as well as local, patched Fluxbox work great for window managers), as well as -multiwindow, on a Windows 7 machine. This should run fine when installed to its prefix, as well, so I have hopefully not negatively affected a Cygwin build with any of my changes. I've put up some information on the wiki of my github repo, including full build instructions: https://github.com/rpavlik/Xserver/wiki I would appreciate any feedback either through this list, or through comments on the github commits, whichever is easier. A number of the xorg-server patches are not XWin specific, and most are not even XWin on MinGW-specific (that is, they may apply to Cygwin/X as well), so I'd like to see as much as you're comfortable with merged. Thanks for your time! Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpavlik@iastate.edu http://academic.cleardefinition.com -- 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/ From temp131@ymail.com Tue Nov 1 21:50:00 2011 From: temp131@ymail.com (Dave) Date: Tue, 01 Nov 2011 21:50:00 -0000 Subject: -nolisten tcp -multiwindow combination crashes in XWin startup In-Reply-To: <4EAFF999.7010301@dronecode.org.uk> References: <1319954770.81475.YahooMailNeo@web114412.mail.gq1.yahoo.com> <4EAEB486.5090002@dronecode.org.uk> <1320088071.46008.YahooMailNeo@web114420.mail.gq1.yahoo.com> <1320088928.33967.YahooMailNeo@web114410.mail.gq1.yahoo.com> <4EAFF999.7010301@dronecode.org.uk> Message-ID: <1320184235.73485.YahooMailNeo@web114404.mail.gq1.yahoo.com> Jon:? Thanks for the?pointers to the fork() problem faqs.? That and a bit of googling led?me to give rebaseall a try, and that appears to have cured my issue.? (For others, instructions can be found at http://www.heikkitoivonen.net/blog/2008/11/26/cygwin-upgrades-and-rebaseall/?.) Suggestion, perhaps more to the main cygwin team:? Since this issue is cygwin specific and?is a bit obscure (I've been using cygwin for a good many years, but this is the first time I've recognized I had issues from this), it'd be nice if users didn't have to learn about this the hard way.? Could running?rebaseall perhaps be automated as part of setup.com? ----- Original Message ----- From: Jon TURNEY Sent: Tuesday, November 1, 2011 6:52 AM Subject: Re: -nolisten tcp -multiwindow combination crashes in XWin startup On 31/10/2011 19:22, Dave wrote: > Sadly this one wants to play a little hard to get... > > I have tried this on two somewhat similar machines - 5 years difference in hardware, but both XP Pro up-to-date on Microsoft Update, and both running the cygwin versions present on mirror.mcs.anl.gov as of this weekend - both were upgraded, then after both were, I checked that there were no further upgrades posted in between.? The two differ regarding which packages are present, but for those present, they'd seem to be at the same versions. > > One shows this problem quite consistently, the other doesn't show it at all.? It's the newer one, which has a good amount of memory to spare and is usually the more reliable these days, that is showing the problem. > > I can recreate the problem at will on the one that shows it by starting XWin at the command line directly, under xinit, or under startxwin.? But if I try to start XWin under gdb, I don't see the problem; see below.? (The page you pointed me to suggests attaching gdb after startup, but that doesn't seem reasonable in this case.) > > I notice in the output from starting XWin at the command line there's the line >? ? ? ? 3 [main] XWin 4520 fork: child 5408 - died waiting for dll loading, errno 11 > I didn't see this output or captured in /var/log/xwin/XWin.0.log when I ran via xinit or startxwin.? I don't know if that line got generated but lost in output redirections, or if this way of starting X is maybe seeing yet a different problem.? This line seems similar to that reported by Denis Beauchemin, Wed, 19 Oct 2011 14:17:54 +0000. Yes, this line is output directly by the cygwin DLL, so you won't see it in XWin.0.log This output is typical of some other software causing cygwin problems with fork emulation, see [1] and [2] in the FAQ. > Any suggestions re how else to get the backtrace you desire, or any other info that might be helpful? You may be able to get something useful using the JIT debugger, by setting the error_start token in the CYGWIN env var, prior to invoking the command which crashes, e.g. CYGWIN="error_start=C:\cygwin\bin\dumper" CYGWIN="error_start=C:\cygwin\bin\gdb" > The below were run within a shell within Emacs running on an X server other than :0.? The behavior looks the same as when running in a Windows CMD shell, except here the XWin output seems to be printing locally rather than going to XWin.0.log.? The "@@@@@@@"s are hand-edited whiteouts. > > The note below about Zonealarm is "interesting".? No Zonealarm, tho do have McAfee's firewall enabled. Apparently cygcheck detects ZoneAlarm by looking for the registry key "SYSTEM\\CurrentControlSet\\Services\\vsdatant", or the file "%windir%\\System32\\vsdatant.sys". > The run under gdb seemed to startup ok; I closed up X after a little while via "Exit..." on the taskbar icon. [1] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-fork-failures [2] http://cygwin.com/faq-nochunks.html#faq.using.bloda -- 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/ From cygwin@cwilson.fastmail.fm Tue Nov 1 22:34:00 2011 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Tue, 01 Nov 2011 22:34:00 -0000 Subject: -nolisten tcp -multiwindow combination crashes in XWin startup In-Reply-To: <1320184235.73485.YahooMailNeo@web114404.mail.gq1.yahoo.com> References: <1319954770.81475.YahooMailNeo@web114412.mail.gq1.yahoo.com> <4EAEB486.5090002@dronecode.org.uk> <1320088071.46008.YahooMailNeo@web114420.mail.gq1.yahoo.com> <1320088928.33967.YahooMailNeo@web114410.mail.gq1.yahoo.com> <4EAFF999.7010301@dronecode.org.uk> <1320184235.73485.YahooMailNeo@web114404.mail.gq1.yahoo.com> Message-ID: <4EB073F4.9090707@cwilson.fastmail.fm> On 11/1/2011 5:50 PM, Dave wrote: > Suggestion, perhaps more to the main cygwin team: Since this issue is cygwin specific and is a bit obscure (I've > been using cygwin for a good many years, but this is the first time I've recognized I had issues from this), it'd be nice > if users didn't have to learn about this the hard way. Could running rebaseall perhaps be automated as part of setup.com? Rebase recently (4.0) gained the ability to use a database of already-rebased DLLs, thanks to Corinna's efforts. I think part of the purpose was to enable this setup-triggered behavior. IF setup always ran rebase(all), then with the old rebase, (a) it would appear to hang for a long time every time you tried to install anything, while rebaseall was running, and (b) you'd always have to kill ALL cygwin processes and services, even just to install some simple utility. With rebase-4.0, those drawbacks won't occur (unless you have to rebase, say, cygintl-8.dll for some reason). But, since rebase-4.0 was just released, I think we're letting it simmer on low heat for a while, before "forcing" everybody to use it during every setup.exe instance. It'd be a real shame if rebase-4.0 had some undiscovered bug...and EVERYBODY got bit with it at once due to a new "feature" of setup.exe! -- Chuck -- 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/ From jon.turney@dronecode.org.uk Thu Nov 3 19:18:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Thu, 03 Nov 2011 19:18:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: References: Message-ID: <4EB2E8FE.6020305@dronecode.org.uk> On 01/11/2011 20:39, Ryan Pavlik wrote: > Not sure if this is the right forum for this, but it seemed more This is absolutely the correct list. Thanks very much for putting in the effort to do this. > specific and probably more appropriate than the overall xorg lists. > I wanted to build a native windows X server (essentially an > open-source Xming). I had to patch a number of the packages along the > way, but did eventually arrive at a build that worked. I looked at > and used a few of the Xming patches, but only generally went to those > when the naive approach didn't work. This may be a problem. The material on the Xming website is licensed under a Creative Commons license, which is not compatible with the X11 license. So, patches from the Xming website are not acceptable unless the author has agreed to re-license them appropriately. > I'm looking for some feedback on the patches so that they can get into > the main line of the projects. > > I built using mingw-cross-env, with my fork here that includes the > dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/ > This builds everything except the xorg-server module (ignore the fact > there's an xorg-server makefile there - the patches aren't up to date > for that module.) > > Patches for these dependencies are as follows, in that mingw-cross-env > repo (These should all have commit messages from being exported from > git format-patch): > libX11-1-add-xwinsock-include, libX11-2-windows-threads, > libX11-3-MinGW-lacks-caddr_t > libXaw-1-need-winsock > libXfont-1-dummy-readlink > libxcb-1-fix-include-order-with-Xdmcp, libxcb-2-wsastartup - this last > one fixes running libX11 apps built for Windows, including the > integrated multi-window WM. > xkbcomp-1-Use-X11-Xwindows.h, xkbcomp-2-Look-in-windows-base-dir-too - > this last one supports the "RELOCATE_PROJECTROOT" option in the XWin > server - should still work fine in the normal case though. I've quickly looked over these patches and in general they look good, and I'd be happy to help get them merged upstream. A couple of general points I'd make though: It helps a great deal in reviewing if the comments state why the change is a good idea (e.g. what problem it fixes), rather than just describing the change which is made. I also noticed that a bit more care might be needed with the define you are using to enable platform specific code: WIN32 and __MINGW__ should not be used interchangeably. WIN32 will also be defined when building VcXsrv, and neither is defined on Cygwin. So, can you post your patches here, preferably in git-send-email format so we can review them in detail? -- 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/ From terminatorul@gmail.com Thu Nov 3 19:35:00 2011 From: terminatorul@gmail.com (Timothy Madden) Date: Thu, 03 Nov 2011 19:35:00 -0000 Subject: Title bar of X apps, no host name? In-Reply-To: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: On 24.10.2010 04:59, Jerry Cloe wrote: > When I start individual windows between two linux boxes I always get the > host name in the title bar of the window. > > For example from my desktop linux box: > > ssh -X jerry@prodserver > then > gedit& > > The title bar of the resulting gedit window will be along the lines of: > "gedit (on prodserver.host.com)" > > But, when I do this from my windows/cygwin desktop, the title bar is simply > "gedit" without the host name. > > On the linux side, I've never done anything to set this up or make it work, > it just always worked, so I'm not even sure where to begin looking. > > Any ideas? Does anyone know how to change the window title to include the hostname please ? Connecting to 4 machines (with *ssh -Y*) and starting the *gvim* on all of them can be really frustrating when you have no indication what machine each instance is running on. Thank you, Timothy Madden -- 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/ From rcsaba@gmail.com Fri Nov 4 09:09:00 2011 From: rcsaba@gmail.com (Csaba Raduly) Date: Fri, 04 Nov 2011 09:09:00 -0000 Subject: Title bar of X apps, no host name? In-Reply-To: References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden wrote: > > Does anyone know how to change the window title to include the hostname > please ? > Put the following into your PS1 (on the remote machines) : \[\e]0;\h:\w\a\] Or you could google for "xterm window title" Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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/ From terminatorul@gmail.com Fri Nov 4 11:46:00 2011 From: terminatorul@gmail.com (Timothy Madden) Date: Fri, 04 Nov 2011 11:46:00 -0000 Subject: Title bar of X apps, no host name? In-Reply-To: References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: On 04.11.2011 11:09, Csaba Raduly wrote: > On Thu, Nov 3, 2011 at 8:27 PM, Timothy Madden wrote: >> >> Does anyone know how to change the window title to include the hostname >> please ? >> > > Put the following into your PS1 (on the remote machines) : > > \[\e]0;\h:\w\a\] > > Or you could google for "xterm window title" I would like to change the title of all my X windows, so as to include the hostname of the X client for the window (that is, the hostname running the application in the window). If you connect with *ssh -Y* to several machines, than you can run GUI applications on those machines, and the windows will open up on your X desktop. If you start gvim on each of these machines, you have 4 gvim windows on your desktop, with no easy way to tell to which machine each window belongs. Some Linux X servers have this by default (I have CentOS), and it allows me to run *knosole* or *gnome-terminal* or *gvim* or any other application on several machines at the same time, with the X windows for them all on my desktop, without confusing the host machine for each window. Thank you, Timothy Madden -- 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/ From JayGoldman@crd.com Fri Nov 4 12:28:00 2011 From: JayGoldman@crd.com (Jay Goldman) Date: Fri, 04 Nov 2011 12:28:00 -0000 Subject: Title bar of X apps, no host name? References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: <8483108B583CFC4FAEFEE85B95CF015C30BCEB8363@MAIL4.crd.com> You can put what you want in the title by setting PROMPT_COMMAND - e.g., set PROMPT_COMMAND="setWindowTitle $(uname -n)" where setWindowTitle is a shell script like: echo -ne "\e]2;$*\a" by putting it in the PROMPT_COMMAND you handle the case where some command sets the window title while it is processing (I do this to provide feedback for long running scripts without filling up the screen). Once the command finishes the window title gets set back to your desired value. Btw, I use different foreground/background color combinations to distinguish between xterms on different machines - some of the color combinations are ugly but they are different :-) -- 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/ From rpavlik@iastate.edu Fri Nov 4 23:39:00 2011 From: rpavlik@iastate.edu (Ryan Pavlik) Date: Fri, 04 Nov 2011 23:39:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: <4EB2E8FE.6020305@dronecode.org.uk> References: <4EB2E8FE.6020305@dronecode.org.uk> Message-ID: On Thu, Nov 3, 2011 at 2:18 PM, Jon TURNEY wrote: > > On 01/11/2011 20:39, Ryan Pavlik wrote: >> >> Not sure if this is the right forum for this, but it seemed more > > This is absolutely the correct list. > > Thanks very much for putting in the effort to do this. > >> specific and probably more appropriate than the overall xorg lists. >> I wanted to build a native windows X server (essentially an >> open-source Xming). I had to patch a number of the packages along the >> way, but did eventually arrive at a build that worked. ?I looked at >> and used a few of the Xming patches, but only generally went to those >> when the naive approach didn't work. > > This may be a problem. > > The material on the Xming website is licensed under a Creative Commons license, which is not compatible with the X11 license. ?So, patches from the Xming website are not acceptable unless the author has agreed to re-license them appropriately. I emailed him and he indicated that he already has a process worked out for re-licensing a patch at a time to submit to you. As such, I have re-worked my patch queue to remove all patches derived from the Xming web site. It doesn't add everything that the previous branch did, but it does build and start to work, and all these patches are licensed like the X11 source itself as they are my work. ?I also re-worked the commit messages and patches a bit, and added some additional patches. https://github.com/rpavlik/Xserver/tree/cleanpatches-1.11-branch >> >> I'm looking for some feedback on the patches so that they can get into >> the main line of the projects. >> >> I built using mingw-cross-env, with my fork here that includes the >> dependency packages: https://bitbucket.org/rpavlik/mingw-cross-env/ >> This builds everything except the xorg-server module (ignore the fact >> there's an xorg-server makefile there - the patches aren't up to date >> for that module.) >> >> Patches for these dependencies are as follows, in that mingw-cross-env >> repo (These should all have commit messages from being exported from >> git format-patch): >> libX11-1-add-xwinsock-include, libX11-2-windows-threads, >> libX11-3-MinGW-lacks-caddr_t >> libXaw-1-need-winsock >> libXfont-1-dummy-readlink >> libxcb-1-fix-include-order-with-Xdmcp, libxcb-2-wsastartup - this last >> one fixes running libX11 apps built for Windows, including the >> integrated multi-window WM. >> xkbcomp-1-Use-X11-Xwindows.h, xkbcomp-2-Look-in-windows-base-dir-too - >> this last one supports the "RELOCATE_PROJECTROOT" option in the XWin >> server - should still work fine in the normal case though. > > I've quickly looked over these patches and in general they look good, and I'd be happy to help get them merged upstream. > > A couple of general points I'd make though: > > It helps a great deal in reviewing if the comments state why the change is a good idea (e.g. what problem it fixes), rather than just describing the change which is made. I've revised the commit messages for xorg-server accordingly - hopefully these are better. > > I also noticed that a bit more care might be needed with the define you are using to enable platform specific code: WIN32 and __MINGW__ should not be used interchangeably. ?WIN32 will also be defined when building VcXsrv, and neither is defined on Cygwin. > Ah, true. I have gone through and improved this in my cleanpatches branch, and have also added some convenience defines to make this easier to get right - this is the last half of the commits. > > So, can you post your patches here, preferably in git-send-email format so we can review them in detail? > I wasn't sure if you wanted one email per patch, and 43 emails seemed like an awful lot, so I've attached them all (git format-patch) to this one. If you prefer, I can send them individually to this (or another) list with git send-email. These are just the xserver patches, not the ones for other packages that I mentioned in the mingw-cross-env repository. Thanks! Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpavlik@iastate.edu http://academic.cleardefinition.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch Type: application/octet-stream Size: 877 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-os-xsha1.c-Preemptively-include-X11-Xwindows.h-on-Wi.patch Type: application/octet-stream Size: 925 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-os-utils.c-sigaction-is-POSIX.patch Type: application/octet-stream Size: 869 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-os-utils.c-Windows-non-cygwin-get-only-stubs-for-Loc.patch Type: application/octet-stream Size: 1893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-hw-xwin-XWin.exe.manifest-Modify-to-be-more-generic.patch Type: application/octet-stream Size: 864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch Type: application/octet-stream Size: 667 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-configure.ac-use-ws2_32-instead-of-winsock2-on-MinGW.patch Type: application/octet-stream Size: 942 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-os-osinit.c-no-getpgrp-and-friends-on-windows-except.patch Type: application/octet-stream Size: 629 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch Type: application/octet-stream Size: 644 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-include-xwin-config.h.in-Add-RELOCATE_PROJECTROOT-to.patch Type: application/octet-stream Size: 684 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-hw-xwin-InitOutput.c-Only-reset-the-xkb-directory-if.patch Type: application/octet-stream Size: 2148 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-hw-xwin-InitOutput.c-reformat-winGetBaseDir.patch Type: application/octet-stream Size: 1768 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch Type: application/octet-stream Size: 6069 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-hw-xwin-winwindow.h-Add-missing-include-xwin-config..patch Type: application/octet-stream Size: 623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-hw-xwin-winwindow.h-change-window-class-and-window-c.patch Type: application/octet-stream Size: 971 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-hw-xwin-winwindow.h-make-project-name-aware-of-non-C.patch Type: application/octet-stream Size: 903 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch Type: application/octet-stream Size: 1480 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-hw-xwin-winrandr.c-Fix-function-pointer-mismatch.patch Type: application/octet-stream Size: 711 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-hw-xwin-winmultiwindowwm.c-fix-memory-leak.patch Type: application/octet-stream Size: 1111 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-hw-xwin-winengine.c-clarify-if-statement-mixed-with-.patch Type: application/octet-stream Size: 866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-hw-xwin-winnativegdi.c-Fix-potential-null-ptr-deref.patch Type: application/octet-stream Size: 1312 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-hw-xwin-winpfbdd.c-fix-possible-null-ptr-deref.patch Type: application/octet-stream Size: 1291 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0023-hw-xwin-winshadgdi.c-fix-double-free.patch Type: application/octet-stream Size: 662 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0024-hw-xwin-winwin32rootless.c-Fix-possible-null-ptr-der.patch Type: application/octet-stream Size: 829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0025-hw-xwin-winwin32rootlesswindow.c-Fix-possible-null-p.patch Type: application/octet-stream Size: 1232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0026-hw-xwin-winwin32rootless.c-remove-empty-if0.patch Type: application/octet-stream Size: 827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch Type: application/octet-stream Size: 778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0028-os-access.c-Windows-non-cygwin-isn-t-just-mingw.patch Type: application/octet-stream Size: 654 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0029-os-utils.c-core-policy-needs-non-Windows-or-Cygwin.patch Type: application/octet-stream Size: 747 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0030-os-utils.c-All-Windows-gets-GetTimeInMillis.patch Type: application/octet-stream Size: 617 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0031-os-xdmcp.c-fix-_XSERVTransWSAStartup-warning.patch Type: application/octet-stream Size: 551 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0032-dix-dispatch.c-os-utils.c-Disable-smart-scheduler-fo.patch Type: application/octet-stream Size: 2638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0033-include-misc.h-Add-simplified-defines-for-windowsnes.patch Type: application/octet-stream Size: 975 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0034-xkb-xkbInit.c-use-new-Win32-defines.patch Type: application/octet-stream Size: 761 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0035-os-utils.c-New-win32-defines.patch Type: application/octet-stream Size: 1280 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0036-miext-rootless-rootlessConfig.h-New-win32-defines.patch Type: application/octet-stream Size: 905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0037-hw-xwin-winclipboard.h-Fix-duplicate-definition.patch Type: application/octet-stream Size: 618 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0038-dix-registry.c-New-win32-defines.patch Type: application/octet-stream Size: 1236 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0039-dix-dispatch.c-New-win32-defines.patch Type: application/octet-stream Size: 720 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0040-os-utils.c-include-misc.h.patch Type: application/octet-stream Size: 606 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch Type: application/octet-stream Size: 754 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0042-configure.ac-auto-disable-MITSHM-if-we-lack-IPC.patch Type: application/octet-stream Size: 2014 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0043-configure.ac-Fix-typo-in-extension-flag-help.patch Type: application/octet-stream Size: 1653 bytes Desc: not available URL: -------------- next part -------------- -- 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/ From d.sastre.medina@gmail.com Sat Nov 5 09:58:00 2011 From: d.sastre.medina@gmail.com (David Sastre) Date: Sat, 05 Nov 2011 09:58:00 -0000 Subject: Title bar of X apps, no host name? In-Reply-To: References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: <20111105095831.GB6441@jethro.local.lan> On Thu, Nov 03, 2011 at 09:27:16PM +0200, Timothy Madden wrote: > On 24.10.2010 04:59, Jerry Cloe wrote: > >When I start individual windows between two linux boxes I always get the > >host name in the title bar of the window. > > > >For example from my desktop linux box: > > > >ssh -X jerry@prodserver > >then > >gedit& > > > >The title bar of the resulting gedit window will be along the lines of: > >"gedit (on prodserver.host.com)" > > > >But, when I do this from my windows/cygwin desktop, the title bar is simply > >"gedit" without the host name. > > > >On the linux side, I've never done anything to set this up or make it work, > >it just always worked, so I'm not even sure where to begin looking. > > > >Any ideas? > > Does anyone know how to change the window title to include the > hostname please ? > > Connecting to 4 machines (with *ssh -Y*) and starting the *gvim* on > all of them can be really frustrating when you have no indication > what machine each instance is running on. One different approach is to use 'screen' and have a hardstatus line: hardstatus alwayslastline "%{wk}%-w%{Gk}[%n %t]%{wk}%+w%=%{Ck}%d %M %Y %c:%s" That way, you always know which screen belongs to which host. However, I find opening several vim in several hosts wasteful. It's quite better to use netrw? to edit remote files within a single vim instance and list your buffers to identify the files/hosts. HTH. ? http://www.vim.org/scripts/script.php?script_id=1075 -- Huella de clave primaria: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: Digital signature URL: From jon.turney@dronecode.org.uk Sun Nov 6 00:39:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Sun, 06 Nov 2011 00:39:00 -0000 Subject: [ANNOUNCEMENT] Updated: xorg-server-1.11.2-1 Message-ID: The following packages have been updated in the Cygwin distribution: *** xorg-server-1.11.2-1 *** xorg-server-dmx-1.11.2-1 These packages contain XWin and the other X.Org X11 servers. In addition to upstream fixes [1], this contains the following cygwin-specific changes since 1.11.1-1: * Use spawn() rather than pipe() & fork() to invoke xkbcomp. This should improve X server startup reliability, avoiding being unable to start when cygwin's fork() emulation is unable to work successfully. (This workaround was added in 1.10.2-1, but in a form which didn't work :( ) 2baaff23a96d11aa5638b60a5d190608 *xorg-server-1.11.2-1.tar.bz2 c73c6b5bbb42dfeae74fb92a8bcbad2a *xorg-server-dmx-1.11.2-1.tar.bz2 e1bbc83b4299a4966b3bc4c4683c02db *xorg-server-1.11.2-1-src.tar.bz2 [1] http://lists.freedesktop.org/archives/xorg-announce/2011-November/001751.html -- 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/ From jon.turney@dronecode.org.uk Mon Nov 7 18:10:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 07 Nov 2011 18:10:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: References: <4EB2E8FE.6020305@dronecode.org.uk> Message-ID: <4EB81EF8.5060107@dronecode.org.uk> On 04/11/2011 23:39, Ryan Pavlik wrote: > On Thu, Nov 3, 2011 at 2:18 PM, Jon TURNEY wrote: >> On 01/11/2011 20:39, Ryan Pavlik wrote: >>> specific and probably more appropriate than the overall xorg lists. >>> I wanted to build a native windows X server (essentially an >>> open-source Xming). I had to patch a number of the packages along the >>> way, but did eventually arrive at a build that worked. I looked at >>> and used a few of the Xming patches, but only generally went to those >>> when the naive approach didn't work. >> >> This may be a problem. >> >> The material on the Xming website is licensed under a Creative Commons license, which is not compatible with the X11 license. So, patches from the Xming website are not acceptable unless the author has agreed to re-license them appropriately. > > I emailed him and he indicated that he already has a process worked > out for re-licensing a patch at a time to submit to you. > > As such, I have re-worked my patch queue to remove all patches derived > from the Xming web site. It doesn't add everything that the previous > branch did, but it does build and start to work, and all these patches > are licensed like the X11 source itself as they are my work. I also > re-worked the commit messages and patches a bit, and added some > additional patches. Okay, thank you. > https://github.com/rpavlik/Xserver/tree/cleanpatches-1.11-branch > >> I've quickly looked over these patches and in general they look good, and I'd be happy to help get them merged upstream. >> >> A couple of general points I'd make though: >> >> It helps a great deal in reviewing if the comments state why the change is a good idea (e.g. what problem it fixes), rather than just describing the change which is made. > > I've revised the commit messages for xorg-server accordingly - > hopefully these are better. > >> >> I also noticed that a bit more care might be needed with the define you are using to enable platform specific code: WIN32 and __MINGW__ should not be used interchangeably. WIN32 will also be defined when building VcXsrv, and neither is defined on Cygwin. >> > > Ah, true. I have gone through and improved this in my cleanpatches > branch, and have also added some convenience defines to make this > easier to get right - this is the last half of the commits. I see what you are trying to do here, but I'm not sure it actually adds any clarity. I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN are mutually exclusive, so '#if defined(WIN32) && !defined(__CYGWIN__)' can just be written '#ifdef WIN32' >> So, can you post your patches here, preferably in git-send-email format so we can review them in detail? > > I wasn't sure if you wanted one email per patch, and 43 emails seemed > like an awful lot, so I've attached them all (git format-patch) to > this one. If you prefer, I can send them individually to this (or > another) list with git send-email. These are just the xserver > patches, not the ones for other packages that I mentioned in the > mingw-cross-env repository. Sorry, I should have mentioned this before, but please can you add a 'Signed-off-by' line to these (git commit --amend --signoff will add one for you) A few comments, I'll take a deeper look later: 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch Good catch! :-) 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch I am a bit unclear why this is needed, surely the winsock API predates XP? It might be better to add this define to CFLAGS rather than to start sprinkling it around source files as needed? 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch Comment should probably say 'Consolidate duplicate code' rather than 'Remove' It seems this changes more than that, though, as it now looks for the files in both PROJECTROOT and basedir? 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch I think the answer to the question 'Should this actually be checking RELOCATE_PROJECTROOT ?' is yes I think it would probably be neater to do something like arrange for FILENAME to start with the platform-appropriate path separator, rather than to define FILENAME_ONLY as the same name without an initial path separator? 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch Interesting. It would probably be useful to quote the language from the appropriate standard which describes the behavior of realloc() in this error case in the comment. I don't think this change is fully correct however. If the realloc'ed size is 0, realloc() may return NULL, but the previously allocated memory has been freed. Perhaps you need to check if errno has been set by realloc to distinguish these two cases? Did you notice this by inspection or actually have a problem caused by this code? Have you audited the rest of the xserver code for this class of error? 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch Use whitespace consistently with the context, please -- 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/ From jon.turney@dronecode.org.uk Mon Nov 7 18:23:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Mon, 07 Nov 2011 18:23:00 -0000 Subject: Title bar of X apps, no host name? In-Reply-To: References: <5F294971C00A184CB8687A4A191A9CD00133043B@JTCLOE3> Message-ID: <4EB82222.7030804@dronecode.org.uk> On 03/11/2011 19:27, Timothy Madden wrote: > On 24.10.2010 04:59, Jerry Cloe wrote: >> When I start individual windows between two linux boxes I always get the >> host name in the title bar of the window. >> >> For example from my desktop linux box: >> >> ssh -X jerry@prodserver >> then >> gedit& >> >> The title bar of the resulting gedit window will be along the lines of: >> "gedit (on prodserver.host.com)" >> >> But, when I do this from my windows/cygwin desktop, the title bar is simply >> "gedit" without the host name. >> >> On the linux side, I've never done anything to set this up or make it work, >> it just always worked, so I'm not even sure where to begin looking. >> >> Any ideas? > > Does anyone know how to change the window title to include the hostname please ? > > Connecting to 4 machines (with *ssh -Y*) and starting the *gvim* on all of > them can be really frustrating when you have no indication what machine each > instance is running on. This is a feature of the Window Manager you are using on your linux hosts (I guess metacity, which appears to add the WM_CLIENT_MACHINE window property onto the end of the window title (if it is not the local hostname)). Unfortunately, the integrated WM built into the Cygwin X server (which manages each X window as a native window in multi-window mode) doesn't have this feature. I can see it would be kind of useful, but then again, I'm sure some people would hate it, so if added, it would need to configurable. -- 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/ From cygwin@cwilson.fastmail.fm Mon Nov 7 19:36:00 2011 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Mon, 07 Nov 2011 19:36:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: <4EB81EF8.5060107@dronecode.org.uk> References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> Message-ID: <4EB83346.8090007@cwilson.fastmail.fm> On 11/7/2011 1:10 PM, Jon TURNEY wrote: > I see what you are trying to do here, but I'm not sure it actually adds > any clarity. > > I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN > are mutually exclusive, so '#if defined(WIN32) && !defined(__CYGWIN__)' > can just be written '#ifdef WIN32' But this isn't true if you ever #include any of the w32api headers. Then you get WIN32 defined, even on cygwin... windef.h: #ifndef WIN32 #define WIN32 #endif #ifndef _WIN32 #define _WIN32 #endif -- Chuck -- 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/ From jon.turney@dronecode.org.uk Wed Nov 9 18:46:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Wed, 09 Nov 2011 18:46:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: <4EB83346.8090007@cwilson.fastmail.fm> References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> <4EB83346.8090007@cwilson.fastmail.fm> Message-ID: <4EBACA74.3090704@dronecode.org.uk> On 07/11/2011 19:36, Charles Wilson wrote: > On 11/7/2011 1:10 PM, Jon TURNEY wrote: >> I see what you are trying to do here, but I'm not sure it actually adds >> any clarity. >> >> I think I'd just prefer to assume the knowledge that WIN32 and CYGWIN >> are mutually exclusive, so '#if defined(WIN32)&& !defined(__CYGWIN__)' >> can just be written '#ifdef WIN32' > > But this isn't true if you ever #include any of the w32api headers. Then > you get WIN32 defined, even on cygwin... True. I guess what I meant to say is that there isn't any compiler which defines both WIN32 and CYGWIN (I hope :-)). Any portable code which includes w32api headers before checking if WIN32 is defined isn't going to be very portable :-) -- 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/ From cygwin@cwilson.fastmail.fm Wed Nov 9 19:11:00 2011 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Wed, 09 Nov 2011 19:11:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: <4EBACA74.3090704@dronecode.org.uk> References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> <4EB83346.8090007@cwilson.fastmail.fm> <4EBACA74.3090704@dronecode.org.uk> Message-ID: <4EBAD044.50306@cwilson.fastmail.fm> On 11/9/2011 1:46 PM, Jon TURNEY wrote: > On 07/11/2011 19:36, Charles Wilson wrote: >> But this isn't true if you ever #include any of the w32api headers. Then >> you get WIN32 defined, even on cygwin... > > True. I guess what I meant to say is that there isn't any compiler which > defines both WIN32 and CYGWIN (I hope :-)). > > Any portable code which includes w32api headers before checking if WIN32 > is defined isn't going to be very portable :-) But it's perfectly portable to check for __CYGWIN__ (or, for that matter, __MINGW32__) instead of WIN32 before #including w32api headers, because you know that the windows API will be available in those cases as well. The difference is, IF you do this (perfectly fine, legal, and portable) thing: #if defined(WIN32) || defined(__CYGWIN__) # include #endif then you can no longer rely on #if defined(WIN32) ...stuff that applies only for truly "native" windows (e.g. ...msvc or mingw), but not cygwin #endif even though both hunks above are legal and make perfect sense *in isolation*. The problem occurs when both hunks are present in the same translation unit -- and that's not always under your control. What if libjpeg's header does the first hunk (it doesn't, but assume that it does for argument's sake), and your project's headers only do the second? You *think* you're safe in assuming that WIN32 == !__CYGWIN__, but...#include breaks all your assumptions. But jpeg.h *did nothing wrong*. It's better to be explicit. -- Chuck -- 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/ From ziser@arlut.utexas.edu Wed Nov 9 23:25:00 2011 From: ziser@arlut.utexas.edu (Jesse Ziser) Date: Wed, 09 Nov 2011 23:25:00 -0000 Subject: XTerm metaSendsEscape not working Message-ID: <4EBB0BC3.2020309@arlut.utexas.edu> Hello, I find that adding the following: XTerm*vt100.metaSendsEscape: true XTerm*vt100.altSendsEscape: true XTerm*vt100.eightBitInput: false to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key handling. It still sends 0xF7 for meta-W, for example (or the UTF-8 equivalent, depending on how I set LANG in the environment). I've also tried this: XTerm*metaSendsEscape: true XTerm*altSendsEscape: true XTerm*eightBitInput: false to no avail. However, adding lines like the following: Meta W: string(0x1b) string("w") \n to my XTerm*translations does the trick (though I would have to add a line like this for every key on the keyboard). The fact that this fixes it seems to be evidence that my problem really is at the XTerm level and not bash or readline or the X server or Windows key mappings or something like that. I'm using Windows 7 64-bit. Any ideas appreciated. Thank you. -- 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/ From dickey@his.com Thu Nov 10 02:09:00 2011 From: dickey@his.com (Thomas Dickey) Date: Thu, 10 Nov 2011 02:09:00 -0000 Subject: XTerm metaSendsEscape not working In-Reply-To: <4EBB0BC3.2020309@arlut.utexas.edu> References: <4EBB0BC3.2020309@arlut.utexas.edu> Message-ID: <20111109210509.W6702@mail101.his.com> On Wed, 9 Nov 2011, Jesse Ziser wrote: > Hello, > > I find that adding the following: > > XTerm*vt100.metaSendsEscape: true > XTerm*vt100.altSendsEscape: true > XTerm*vt100.eightBitInput: false > > to my .Xdefaults does not seem to change the way XTerm behaves WRT meta-key > handling. It still sends 0xF7 for meta-W, for example (or the UTF-8 > equivalent, depending on how I set LANG in the environment). > > I've also tried this: > > XTerm*metaSendsEscape: true > XTerm*altSendsEscape: true > XTerm*eightBitInput: false > > to no avail. However, adding lines like the following: > > Meta W: string(0x1b) string("w") \n well, there's more than one aspect to the problem. xterm is looking for whatever is used for the modifier which corresponds to the meta key. But X doesn't have that as a standard modifier. So xterm looks at the modifiers and determines which one it is. It might be the same as an Alt-key, and it might not. So there's altSendsEscape as a workaround for that case. On the other hand, if there are translations using the key that xterm finds to be the "meta" key, then xterm refrains from using it as a modifier, unless (for example) the alwaysUseMods resource is set to true. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- 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/ From ziser@arlut.utexas.edu Thu Nov 10 15:14:00 2011 From: ziser@arlut.utexas.edu (Jesse Ziser) Date: Thu, 10 Nov 2011 15:14:00 -0000 Subject: XTerm metaSendsEscape not working In-Reply-To: <20111109210509.W6702@mail101.his.com> References: <4EBB0BC3.2020309@arlut.utexas.edu> <20111109210509.W6702@mail101.his.com> Message-ID: <4EBBEA3E.7050007@arlut.utexas.edu> On 11/9/2011 8:09 PM, Thomas Dickey wrote: > On Wed, 9 Nov 2011, Jesse Ziser wrote: > >> Hello, >> >> I find that adding the following: >> >> XTerm*vt100.metaSendsEscape: true >> XTerm*vt100.altSendsEscape: true >> XTerm*vt100.eightBitInput: false >> >> to my .Xdefaults does not seem to change the way XTerm behaves WRT >> meta-key handling. It still sends 0xF7 for meta-W, for example (or the >> UTF-8 equivalent, depending on how I set LANG in the environment). >> >> I've also tried this: >> >> XTerm*metaSendsEscape: true >> XTerm*altSendsEscape: true >> XTerm*eightBitInput: false >> >> to no avail. However, adding lines like the following: >> >> Meta W: string(0x1b) string("w") \n > > well, there's more than one aspect to the problem. xterm is looking for > whatever is used for the modifier which corresponds to the meta key. But > X doesn't have that as a standard modifier. So xterm looks at the > modifiers and determines which one it is. It might be the same as an > Alt-key, and it might not. So there's altSendsEscape as a workaround for > that case. > > On the other hand, if there are translations using the key that xterm > finds to be the "meta" key, then xterm refrains from using it as a > modifier, unless (for example) the alwaysUseMods resource is set to true. OK, removing all translations involving Meta did indeed fix it, and so did setting alwaysUseMods to true. So I guess it wasn't a Cygwin-specific issue then after all, just a manpage comprehension issue. Thanks! -- 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/ From rpavlik@iastate.edu Thu Nov 10 16:50:00 2011 From: rpavlik@iastate.edu (Ryan Pavlik) Date: Thu, 10 Nov 2011 16:50:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: <4EB81EF8.5060107@dronecode.org.uk> References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> Message-ID: On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY wrote: > Sorry, I should have mentioned this before, but please can you add a > 'Signed-off-by' line to these (git commit --amend --signoff will add one for > you) > > A few comments, I'll take a deeper look later: > > 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch > > Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? Good catch, thanks! > > 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch > > Good catch! :-) > Yeah, notices this when trying to build for tarballs. > 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch > > I am a bit unclear why this is needed, surely the winsock API predates XP? > It might be better to add this define to CFLAGS rather than to start > sprinkling it around source files as needed? > Yes, but one of the calls in that file uses a part of the winsock API introduced in XP - getaddrinfo and freeaddrinfo. http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src > 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch > > Comment should probably say 'Consolidate duplicate code' rather than > 'Remove' > > It seems this changes more than that, though, as it now looks for the files > in both PROJECTROOT and basedir? > > 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch > > I think the answer to the question 'Should this actually be checking > RELOCATE_PROJECTROOT ?' is yes > The catch here is that RELOCATE_PROJECTROOT is currently (added by me, since it wasn't in any header except the unused autogenerated one) in xwin-config.h. Would it be appropriate to move it to dix-config.h for this purpose? > I think it would probably be neater to do something like arrange for > FILENAME to start with the platform-appropriate path separator, rather than > to define FILENAME_ONLY as the same name without an initial path separator? > The difference is not just the path separator - the FILENAME also includes the macro define (string literal) of the install location, which is concatenated with the filename by the preprocessor. > 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch > > Interesting. > > It would probably be useful to quote the language from the appropriate > standard which describes the behavior of realloc() in this error case in the > comment. > > I don't think this change is fully correct however. ?If the realloc'ed size > is 0, realloc() may return NULL, but the previously allocated memory has > been freed. ?Perhaps you need to check if errno has been set by realloc to > distinguish these two cases? > > Did you notice this by inspection or actually have a problem caused by this > code? Have you audited the rest of the xserver code for this class of error? > Good point. I found this with cppcheck - a static analysis tool that, despite its name, is useful for C code as well. There were other issues it mentioned in the xserver code, but I didn't get to any of the others yet. In any case, it's a completely orthogonal patch. Might be useful for someone more familiar with the code to run cppcheck and address the issues. > 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch > > Use whitespace consistently with the context, please Oops - will correct. > > -- > Jon TURNEY > Volunteer Cygwin/X X Server maintainer > -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpavlik@iastate.edu http://academic.cleardefinition.com -- 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/ From cygwin@cwilson.fastmail.fm Thu Nov 10 22:58:00 2011 From: cygwin@cwilson.fastmail.fm (Charles Wilson) Date: Thu, 10 Nov 2011 22:58:00 -0000 Subject: Built XWin on mingw - with patches In-Reply-To: References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> <4EB83346.8090007@cwilson.fastmail.fm> <4EBACA74.3090704@dronecode.org.uk> <4EBAD044.50306@cwilson.fastmail.fm> Message-ID: <4EBC56E8.2020001@cwilson.fastmail.fm> On 11/10/2011 11:29 AM, Ryan Pavlik wrote: > On Wed, Nov 9, 2011 at 1:11 PM, Charles Wilson wrote: >> You *think* you're safe in assuming that WIN32 == !__CYGWIN__, >> but...#include breaks all your assumptions. But jpeg.h *did >> nothing wrong*. >> >> It's better to be explicit. >> >> -- >> Chuck > > OK, so this leads me to the next question: The existing codebase has > substantial numbers of places with #if defined(WIN32) - do these all > imply #if defined(WIN32)&& !defined(__CYGWIN__) ? That I don't know. > I generally > avoided touching things I didn't have to, A good policy. > but this may be worth > clarifying codebase-wide. Perhaps -- I'll leave that call to others. I suspect a global patch that affected only #if lines should be a separate patch from any other changes, if taking this action was desirable. -- Chuck -- 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/ From pfaff@hl.net.ua Fri Nov 11 12:06:00 2011 From: pfaff@hl.net.ua (Junkina Larisa) Date: Fri, 11 Nov 2011 12:06:00 -0000 Subject: =?UTF-8?B?UGlla3LEq3R1LA==?= velakamies? =?UTF-8?B?QnXEjWEh?= Message-ID: Klau, mo??ka aizstaig??jam uz klubu? Atceros, ka toreiz tu man teici, ka gribi kaut ko uzbudino????ku k?? parasti. Es mazliet pas??rfoju pa netu un atradu, manupr??t, ??ooooti labu, variantu: http://northstarpads.co.uk/generic-webuser/action/last.php Un atsauksmes liecina, ka sviediena nav, b??rs, laba m??zika, ugun??gi seks??gas meitenes un cenas - nav p??rsp??l??tas, t??das, ka ar?? m??s??jie, ne tikai ??rzemnieki, var at??auties.. -- 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/ From jon.turney@dronecode.org.uk Fri Nov 11 14:12:00 2011 From: jon.turney@dronecode.org.uk (Jon TURNEY) Date: Fri, 11 Nov 2011 14:12:00 -0000 Subject: [ANNOUNCEMENT] Updated: ddd-3.3.12-1 Message-ID: The following packages have been updated in the Cygwin distribution: *** ddd-3.3.12-1 GNU DDD is a graphical front-end for command-line debuggers such as GDB, DBX, WDB, Ladebug, JDB, XDB, the Perl debugger, the bash debugger bashdb, the GNU Make debugger remake, or the Python debugger pydb. Besides 'usual' front-end features such as viewing source texts, DDD has become famous through its interactive graphical data display, where data structures are displayed as graphs. This release is an update to the latest upstream release. bc67d2c19b00b7b49b931ba38acf6232 *ddd-3.3.12-1.tar.bz2 68dbb0be98257e8c3b197f44b52ab3da *ddd-3.3.12-1-src.tar.bz2 -- 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/ From jenlwong@yahoo.com Tue Nov 15 19:30:00 2011 From: jenlwong@yahoo.com (jenw) Date: Tue, 15 Nov 2011 19:30:00 -0000 Subject: frequently getting a =?utf-8?b?U1RBVFVTX0FDQ0VTU19WSU9MQVRJT04=?= exception under win7 References: Message-ID: Thank you, Whatzit Toya, your solution compatibility mode/run as admin solution worked like a charm for me! -jw -- 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/ From jjreisert@alum.mit.edu Mon Nov 21 17:14:00 2011 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Mon, 21 Nov 2011 17:14:00 -0000 Subject: XWin.exe causes Windows apps. to freeze Message-ID: I have a persistent problem at work after XWin has been running for a while (sometimes hours, sometimes days). Windows programs will spontaneously freeze I am running Windows XP SP3 on a Dell Latitude D810 laptop (Intel T7200 @ 2.0 GHz, 2 GB RAM). I typically run MS Outlook 2007, some form of Firefox (either release or beta), and Citrix (remote-access software), all at the same time, though I have run the various flavors of VNC (Real, Tight, Tiger) in the past. Graphics is an NVIDIA Quadro NVS 110M with two monitors connected (one digital, one analog), using the 197.68 driver. What happens is that windows will spontaneously freeze. For example, I'm composing a message in Outlook, and all of a sudden, my keyboard stops responding, then I'll get the Windows hourglass in that window. Or I'll be surfing in Firefox and window changes just stop, again hourglass. Once this happens, killing XWin.exe from the task manager immediately releases the hang condition(s), though the hang may release itself if I wait several minutes (yeah, right). At this point, I can re-start XWin, but later on, it will happen again. I'm starting XWin.exe from the install shortcut: C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe I'm running the latest of Cygwin everything, the problem has been across several (many) releases of the Xorg server. I think it's using the default options for multi-monitor, cut/paste, etc. I can usually copy/paste between XWin and MS Windows (and usually Citrix) without any problems. I keep thinking that the problem is something in the XWin code that interfaces to Windows' copy/paste engine (OLE?). Is there any way to debug this problem? It would be great to get it resolved. Thanks - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From ryan.johnson@cs.utoronto.ca Mon Nov 21 17:40:00 2011 From: ryan.johnson@cs.utoronto.ca (Ryan Johnson) Date: Mon, 21 Nov 2011 17:40:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: Message-ID: <4ECA8CEB.7080805@cs.utoronto.ca> On 21/11/2011 12:14 PM, Jim Reisert AD1C wrote: > I have a persistent problem at work after XWin has been running for a > while (sometimes hours, sometimes days). Windows programs will > spontaneously freeze > For example, > I'm composing a message in Outlook, and all of a sudden, my keyboard > stops responding, then I'll get the Windows hourglass in that window. > Or I'll be surfing in Firefox and window changes just stop, again > hourglass. Once this happens, killing XWin.exe from the task manager > immediately releases the hang condition(s), though the hang may > release itself if I wait several minutes (yeah, right). At this > point, I can re-start XWin, but later on, it will happen again. > > I'm starting XWin.exe from the install shortcut: > > C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c /usr/bin/startxwin.exe > > I'm running the latest of Cygwin everything, the problem has been > across several (many) releases of the Xorg server. I think it's using > the default options for multi-monitor, cut/paste, etc. I can usually > copy/paste between XWin and MS Windows (and usually Citrix) without > any problems. I keep thinking that the problem is something in the > XWin code that interfaces to Windows' copy/paste engine (OLE?). If you think it's clipboard related, try running with -noclipboard and see if that fixes it. Downside is, you lose all clipboard functionality... BTW, what do you use x11 for? Other than the odd gnuplot session, I've not needed an X server since switching from xterm to mintty (which just became the official cygwin terminal). If a similar situation applies to you, you could temporarily switch to mintty while doing the above experiment and still be able to use clipboard in the meantime. Finally, I've never used a multi-monitor setup myself, but according to the XWin man page you should specify the -multimonitors option since you apparently (really??) don't run in -multiwindow mode. Or maybe the man page is just out of date and -multiwindow is the default now, in which case multiple monitor support comes for free. Ryan -- 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/ From jjreisert@alum.mit.edu Mon Nov 21 17:58:00 2011 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Mon, 21 Nov 2011 17:58:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: <4ECA8CEB.7080805@cs.utoronto.ca> References: <4ECA8CEB.7080805@cs.utoronto.ca> Message-ID: On Mon, Nov 21, 2011 at 10:39 AM, Ryan Johnson wrote: > If you think it's clipboard related, try running with -noclipboard and see > if that fixes it. Downside is, you lose all clipboard functionality... Duh, I should have though of that. Where do these settings reside now, since I'm no longer starting XWin using the batch file? > BTW, what do you use x11 for? Other than the odd gnuplot session, I've not > needed an X server since switching from xterm to mintty (which just became > the official cygwin terminal). All my "work" work is X-based, I'm super-comfortable with the interface, for example, using the mouse for copy/paste which is a little more awkward in mintty. Plus I love Xemacs. > Finally, I've never used a multi-monitor setup myself, but according to the > XWin man page you should specify the -multimonitors option since you > apparently (really??) don't run in -multiwindow mode. I think I do, because I can move the windows to the other monitor and they still function. Again, I don't know/remember where these settings reside now. They're not in my .startxwinrc -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From andy.koppe@gmail.com Mon Nov 21 20:07:00 2011 From: andy.koppe@gmail.com (Andy Koppe) Date: Mon, 21 Nov 2011 20:07:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: <4ECA8CEB.7080805@cs.utoronto.ca> Message-ID: On 21 November 2011 17:57, Jim Reisert AD1C wrote: > All my "work" work is X-based, I'm super-comfortable with the > interface, for example, using the mouse for copy/paste which is a > little more awkward in mintty. In what way? Andy -- 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/ From ryan.johnson@cs.utoronto.ca Mon Nov 21 20:21:00 2011 From: ryan.johnson@cs.utoronto.ca (Ryan Johnson) Date: Mon, 21 Nov 2011 20:21:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: <4ECA8CEB.7080805@cs.utoronto.ca> Message-ID: <4ECAB291.6030801@cs.utoronto.ca> On 21/11/2011 12:57 PM, Jim Reisert AD1C wrote: > On Mon, Nov 21, 2011 at 10:39 AM, Ryan Johnson > wrote: > >> If you think it's clipboard related, try running with -noclipboard and see >> if that fixes it. Downside is, you lose all clipboard functionality... > Duh, I should have though of that. Where do these settings reside > now, since I'm no longer starting XWin using the batch file? I think you have to modify the shortcut (or run the command from a terminal) to add extra command-line options. >> BTW, what do you use x11 for? Other than the odd gnuplot session, I've not >> needed an X server since switching from xterm to mintty (which just became >> the official cygwin terminal). > All my "work" work is X-based, I'm super-comfortable with the > interface, for example, using the mouse for copy/paste which is a > little more awkward in mintty. Plus I love Xemacs. Eh? Mouse copy/paste in mintty is identical to xterm AFAIK... select = copy, middle button = paste. If you're in a mouse-using terminal app you have to hold down [shift] but that's the same in xterm, I think. Re xemacs: fair enough. I mostly stick with emacs + xt-mouse because of slow/unreliable network connections to the servers I do most of my work on. Ryan -- 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/ From jjreisert@alum.mit.edu Mon Nov 21 21:26:00 2011 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Mon, 21 Nov 2011 21:26:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: <4ECAB291.6030801@cs.utoronto.ca> References: <4ECA8CEB.7080805@cs.utoronto.ca> <4ECAB291.6030801@cs.utoronto.ca> Message-ID: On Mon, Nov 21, 2011 at 1:20 PM, Ryan Johnson wrote: > Eh? Mouse copy/paste in mintty is identical to xterm AFAIK... select = copy, > middle button = paste. If you're in a mouse-using terminal app you have to > hold down [shift] but that's the same in xterm, I think. Not on mine it isn't: * double-click on word hightlights, but does not copy * middle button paste does work In my xterms, I just have to double-click LMB to copy, then MMB pastes. -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From ryan.johnson@cs.utoronto.ca Mon Nov 21 23:46:00 2011 From: ryan.johnson@cs.utoronto.ca (Ryan Johnson) Date: Mon, 21 Nov 2011 23:46:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: <4ECA8CEB.7080805@cs.utoronto.ca> <4ECAB291.6030801@cs.utoronto.ca> Message-ID: <4ECAE2AF.7020601@cs.utoronto.ca> On 21/11/2011 4:25 PM, Jim Reisert AD1C wrote: > On Mon, Nov 21, 2011 at 1:20 PM, Ryan Johnson wrote: > >> Eh? Mouse copy/paste in mintty is identical to xterm AFAIK... select = copy, >> middle button = paste. If you're in a mouse-using terminal app you have to >> hold down [shift] but that's the same in xterm, I think. > Not on mine it isn't: > > * double-click on word hightlights, but does not copy > * middle button paste does work > > In my xterms, I just have to double-click LMB to copy, then MMB pastes. That's very strange... I can't tell you how many ad-hoc excel graphs I've populated with numbers grabbed by double-click from experiment output. Triple-clicking to get the whole line also comes in handy at times. I just tested again in case it changed since yesterday, and it still works for me. Ryan -- 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/ From seongnam.oh@gmail.com Tue Nov 22 02:55:00 2011 From: seongnam.oh@gmail.com (SeongNam Oh) Date: Tue, 22 Nov 2011 02:55:00 -0000 Subject: Built XWin on mingw - with patches References: <4EB2E8FE.6020305@dronecode.org.uk> <4EB81EF8.5060107@dronecode.org.uk> Message-ID: Ryan Pavlik iastate.edu> writes: > > On Mon, Nov 7, 2011 at 12:10 PM, Jon TURNEY dronecode.org.uk> wrote: > > Sorry, I should have mentioned this before, but please can you add a > > 'Signed-off-by' line to these (git commit --amend --signoff will add one for > > you) > > > > A few comments, I'll take a deeper look later: > > > > 0001-os-osinit.c-Exclude-new-signal-sigaction-code-on-non.patch > > > > Shouldn't this be X_NOT_POSIX rather than X_NO_POSIX? > > Good catch, thanks! > > > > > 0006-hw-xwin-Makefile.am-Include-manifest-in-the-dist-tar.patch > > > > Good catch! > > > > Yeah, notices this when trying to build for tarballs. > > > 0009-os-utils.c-Use-winxp-or-better-for-Winsock-API.patch > > > > I am a bit unclear why this is needed, surely the winsock API predates XP? > > It might be better to add this define to CFLAGS rather than to start > > sprinkling it around source files as needed? > > > > Yes, but one of the calls in that file uses a part of the winsock API > introduced in XP - getaddrinfo and freeaddrinfo. > http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/w32api/include/ws2tcpip.h?rev=1.12&content-type=text/x-cvsweb-markup&cvsroot=src > > > 0013-hw-xwin-InitOutput.c-Remove-duplicated-code-for-sett.patch > > > > Comment should probably say 'Consolidate duplicate code' rather than > > 'Remove' > > > > It seems this changes more than that, though, as it now looks for the files > > in both PROJECTROOT and basedir? > > > > 0017-dix-registry.c-non-cygwin-find-protocol.txt-in-reloc.patch > > > > I think the answer to the question 'Should this actually be checking > > RELOCATE_PROJECTROOT ?' is yes > > > > The catch here is that RELOCATE_PROJECTROOT is currently (added by me, > since it wasn't in any header except the unused autogenerated one) in > xwin-config.h. Would it be appropriate to move it to dix-config.h for > this purpose? > > > I think it would probably be neater to do something like arrange for > > FILENAME to start with the platform-appropriate path separator, rather than > > to define FILENAME_ONLY as the same name without an initial path separator? > > > > The difference is not just the path separator - the FILENAME also > includes the macro define (string literal) of the install location, > which is concatenated with the filename by the preprocessor. > > > 0027-dix-registry.c-Free-old-memory-upon-realloc-failure.patch > > > > Interesting. > > > > It would probably be useful to quote the language from the appropriate > > standard which describes the behavior of realloc() in this error case in the > > comment. > > > > I don't think this change is fully correct however. ??If the realloc'ed size > > is 0, realloc() may return NULL, but the previously allocated memory has > > been freed. ??Perhaps you need to check if errno has been set by realloc to > > distinguish these two cases? > > > > Did you notice this by inspection or actually have a problem caused by this > > code? Have you audited the rest of the xserver code for this class of error? > > > > Good point. I found this with cppcheck - a static analysis tool that, > despite its name, is useful for C code as well. There were other > issues it mentioned in the xserver code, but I didn't get to any of > the others yet. In any case, it's a completely orthogonal patch. Might > be useful for someone more familiar with the code to run cppcheck and > address the issues. > > > 0041-configure.ac-mingw-doesn-t-have-setuid-either.patch > > > > Use whitespace consistently with the context, please > > Oops - will correct. > > > > > -- > > Jon TURNEY > > Volunteer Cygwin/X X Server maintainer > > > I have successfully built XWin with some Xming project patches( manually adopted line by line after understanding the purpose) on MINGW environment and also activated GLX. not AIGLX yet because I couldn't find a way to build swrast driver of Mesa with xlib option, but server side is activated. I am finalizing my built, and I am facing on an issue point. 1. in MINGW environment, I could successfully compile xkeyboard-config 1.3 version package, but higher version is failed. below is an error message from version 2.3 interesting thing is "xkbcomp -lfhlpR -o compat.dir '*'" command doesn't generate the compat.dir file and even command from 1.3 also doesn't generate the file when I manually wrote in MINGW shell. but 1.3 version is working in script operation in the shell. why I am trying to do this is to figure out an root error point after calling XSync() command in XMesaSwapBuffers() which is the last call after rendering 3D objects. Now, XWin is working fine before calling the command and the command is generating "BadRequest" and I believe that it comes from Xi module and then digging the root cause. ( to clean out a possibility because I used too old xkeyboard-config ) *********************************************************** [ Client End ] seongnam@Panda ~/build/bin $ ./GLlesson05.exe Got Doublebuffered Visual! glX-Version 1.4 Resolution 600x600 Depth 24 Congrats, you have Direct Rendering! X Error: BadRequest Request Major code 0 () Error Serial #35 Current Serial #38 *********************************************************** [ Server End ] REPLY: ClientIDX: 4 Xerror: Code: 0x1 resID: 0xffffffe6 maj: 0x0 min: 0 REQUEST: ClientIDX: 4, type: 0x0 data: 0x0 len: 0 REPLY: ClientIDX: 4 Xerror: Code: 0x1 resID: 0xffffffe6 maj: 0x0 min: 0 REPLY: ClientIDX: 1 XEvent: type: 0x12 detail: 0x0 seq#: 0x19 REPLY: ClientIDX: 1 XEvent: type: 0x11 detail: 0x0 seq#: 0x19 *********************************************************** [ xkeyboard-config error message ] xkeyboard-config is configured with the following parameters: XKB base directory: ${datarootdir}/X11/xkb Symbolic link(s) to legacy rules are not created Compatibility rules are included *********************************************************** Making all in compat make[1]: Entering directory `/home/seongnam/src/xkeyboard-config-2.3/compat' rm -f compat.dir /home/seongnam/build/bin/xkbcomp -lfhlpR -o compat.dir '*' make[1]: *** [compat.dir] Error 1 make[1]: Leaving directory `/home/seongnam/src/xkeyboard-config-2.3/compat' make: *** [all-recursive] Error 1 build.sh: "make " failed on xkeyboard-config/xkeyboard-config build.sh: error processing module/component: "xkeyboard-config/xkeyboard-config -- 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/ From andy.koppe@gmail.com Tue Nov 22 05:27:00 2011 From: andy.koppe@gmail.com (Andy Koppe) Date: Tue, 22 Nov 2011 05:27:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: <4ECAE2AF.7020601@cs.utoronto.ca> References: <4ECA8CEB.7080805@cs.utoronto.ca> <4ECAB291.6030801@cs.utoronto.ca> <4ECAE2AF.7020601@cs.utoronto.ca> Message-ID: On 21 November 2011 23:45, Ryan Johnson wrote: > On 21/11/2011 4:25 PM, Jim Reisert AD1C wrote: >> >> On Mon, Nov 21, 2011 at 1:20 PM, Ryan Johnson wrote: >> >>> Eh? Mouse copy/paste in mintty is identical to xterm AFAIK... select = >>> copy, >>> middle button = paste. If you're in a mouse-using terminal app you have >>> to >>> hold down [shift] but that's the same in xterm, I think. >> >> Not on mine it isn't: >> >> * double-click on word ?hightlights, but does not copy >> * middle button paste does work >> >> In my xterms, I just have to double-click LMB to copy, then MMB pastes. > > That's very strange... I can't tell you how many ad-hoc excel graphs I've > populated with numbers grabbed by double-click from experiment output. > Triple-clicking to get the whole line also comes in handy at times. I just > tested again in case it changed since yesterday, and it still works for me. Options -> Mouse -> Copy on select This is on by default these days, but wasn't originally. Evidence again that functionality that isn't enabled by default might as well not be there as far as most users are concerned. Speaking of which, my own favourite mintty feature is 'Clicks place command line cursor' on the same page, which can greatly speed up navigating long command lines. Andy -- 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/ From ryan.johnson@cs.utoronto.ca Tue Nov 22 05:47:00 2011 From: ryan.johnson@cs.utoronto.ca (Ryan Johnson) Date: Tue, 22 Nov 2011 05:47:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: <4ECA8CEB.7080805@cs.utoronto.ca> <4ECAB291.6030801@cs.utoronto.ca> <4ECAE2AF.7020601@cs.utoronto.ca> Message-ID: <4ECB376C.1040305@cs.utoronto.ca> On 22/11/2011 12:27 AM, Andy Koppe wrote: > On 21 November 2011 23:45, Ryan Johnson wrote: >> On 21/11/2011 4:25 PM, Jim Reisert AD1C wrote: >>> On Mon, Nov 21, 2011 at 1:20 PM, Ryan Johnson wrote: >>> >>>> Eh? Mouse copy/paste in mintty is identical to xterm AFAIK... select = >>>> copy, >>>> middle button = paste. If you're in a mouse-using terminal app you have >>>> to >>>> hold down [shift] but that's the same in xterm, I think. >>> Not on mine it isn't: >>> >>> * double-click on word hightlights, but does not copy >>> * middle button paste does work >>> >>> In my xterms, I just have to double-click LMB to copy, then MMB pastes. >> That's very strange... I can't tell you how many ad-hoc excel graphs I've >> populated with numbers grabbed by double-click from experiment output. >> Triple-clicking to get the whole line also comes in handy at times. I just >> tested again in case it changed since yesterday, and it still works for me. > Options -> Mouse -> Copy on select > > This is on by default these days, but wasn't originally. Evidence > again that functionality that isn't enabled by default might as well > not be there as far as most users are concerned. Speaking of which, my > own favourite mintty feature is 'Clicks place command line cursor' on > the same page, which can greatly speed up navigating long command > lines. Holy smokes Batman! How long has that been there? A quick test confirms that it also works for readline-enabled app prompts (python, gnuplot, gdb). And here I've been copying long commands to notepad for editing all this time... Too bad screen spoils the fun for the prompts it manages. Ryan -- 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/ From jjreisert@alum.mit.edu Tue Nov 22 21:28:00 2011 From: jjreisert@alum.mit.edu (Jim Reisert AD1C) Date: Tue, 22 Nov 2011 21:28:00 -0000 Subject: XWin.exe causes Windows apps. to freeze In-Reply-To: References: <4ECA8CEB.7080805@cs.utoronto.ca> <4ECAB291.6030801@cs.utoronto.ca> <4ECAE2AF.7020601@cs.utoronto.ca> Message-ID: > Options -> Mouse -> Copy on select mintty has *options*? :-) Thanks! It would still be good to nail down the cause of the non-X application pauses when the server is running. I've been running the server with cut/paste turned off since yesterday (as Jon Stewart would say, "Awkward...."). Anyway, no pauses yet, will keep trying. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- 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/ From apregean@tulane.edu Wed Nov 23 11:52:00 2011 From: apregean@tulane.edu (Ling) Date: Wed, 23 Nov 2011 11:52:00 -0000 Subject: Both Of Us11/23/2011 Message-ID: <0378e1d9-40870-23c91608724653@justice-hp> Hello I have a Business Bequest for you to Handle with me. Kindly forward to me your Names, Address,Contact Telephone Number for Further info. Regards, LIu -- 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/ From yselkowitz@users.sourceforge.net Thu Nov 24 01:32:00 2011 From: yselkowitz@users.sourceforge.net (Yaakov (Cygwin/X)) Date: Thu, 24 Nov 2011 01:32:00 -0000 Subject: [ANNOUNCEMENT] Updated: GNOME 3.2 libraries Message-ID: The GNOME libraries in the distro have been updated to the latest 3.2 release. The following packages have been added accordingly: * gtk3 * gnome-themes-standard and font-cantarell-otf * dconf and gsettings-desktop-schemas (for glib GSettings API) * glib2.0-networking (for libsoup) * libcanberra and sound-theme-freedesktop (for sound events) * libdatrie and libthai (for pango) * p11-kit (for gnome-keyring) * vala * gnome-doc-utils, itstool, yelp-tools, yelp-xsl (build tools) The deprecated GNOME 2 libraries have also been updated to their most recent (and likely final) releases: * gnome-vfs2 * libart_lgpl_2 * libglade2 * libgnome2 * libgnomecanvas2 * libgnomeprint2.2 * libgnomeprintui2.2 * libgnomeui2 * libIDL2 * ORBit2 These libraries are subject to eventual removal once nothing depends on them anymore. 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/ From kbrown@cornell.edu Sat Nov 26 00:39:00 2011 From: kbrown@cornell.edu (Ken Brown) Date: Sat, 26 Nov 2011 00:39:00 -0000 Subject: Problems with emacs built against gtk3 Message-ID: <4ED03512.7080607@cornell.edu> When I build emacs against gtk3, it is unusable. Here are the symptoms when the resulting emacs is started in an xterm window: $ ./emacs -Q& [1] 3344 (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of a child process was requested but SIGCHLD action was set to SIG_IGN and ECHILD was received by waitpid(), so exit status can't be returned. This is a bug in the program calling g_spawn_sync(); either don't request the exit status, or don't set the SIGCHLD action. ** (emacs:3344): WARNING **: Abnormal program termination spawning command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 --binary-syntax --close-stderr': (emacs:3344): Pango-WARNING **: No such file or directory A few seconds later, emacs dies (the window disappears and the process is gone, with no error messages), and two dbus processes remain: $ ps | grep dbus 5188 1 3344 5188 7 1002 19:07:31 /usr/bin/dbus-launch 6452 1 6452 6452 ? 1002 19:07:31 /usr/bin/dbus-daemon If I start emacs again without killing the dbus processes, I don't get the first two warnings but I still get the third. Again, emacs dies after a few seconds. I think the pango warning is Cygwin specific, but the rest of it might not be. Similar symptoms were reported on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=654027 But there are some differences, so I thought I should report it here just in case part of the problem is Cygwin specific. My cygcheck output is attached but probably not relevant. Ken -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cygcheck.out URL: -------------- next part -------------- -- 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/ From kbrown@cornell.edu Sat Nov 26 13:40:00 2011 From: kbrown@cornell.edu (Ken Brown) Date: Sat, 26 Nov 2011 13:40:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: <4ED03512.7080607@cornell.edu> References: <4ED03512.7080607@cornell.edu> Message-ID: <4ED0EC50.4090300@cornell.edu> On 11/25/2011 7:38 PM, Ken Brown wrote: > When I build emacs against gtk3, it is unusable. Here are the symptoms > when the resulting emacs is started in an xterm window: > > $ ./emacs -Q& > [1] 3344 > > (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of > a child process was requested but SIGCHLD action was set to SIG_IGN and > ECHILD was received by waitpid(), so exit status can't be returned. This > is a bug in the program calling g_spawn_sync(); either don't request the > exit status, or don't set the SIGCHLD action. > > ** (emacs:3344): WARNING **: Abnormal program termination spawning > command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 > --binary-syntax --close-stderr': > > (emacs:3344): Pango-WARNING **: No such file or directory > > A few seconds later, emacs dies (the window disappears and the process > is gone, with no error messages), and two dbus processes remain: > > $ ps | grep dbus > 5188 1 3344 5188 7 1002 19:07:31 /usr/bin/dbus-launch > 6452 1 6452 6452 ? 1002 19:07:31 /usr/bin/dbus-daemon > > If I start emacs again without killing the dbus processes, I don't get > the first two warnings but I still get the third. Again, emacs dies > after a few seconds. > > I think the pango warning is Cygwin specific, but the rest of it might > not be. Similar symptoms were reported on Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=654027 > > But there are some differences, so I thought I should report it here > just in case part of the problem is Cygwin specific. My cygcheck output > is attached but probably not relevant. Further info: 1. I don't think gtk3 is the culprit here after all. I uninstalled libgtk3_0 and libgtk3-devel and rebuilt emacs, but the problem persisted. It was only after uninstalling dconf-service (a dependency of libgtk3_0) that things went back to normal [except for the pango warning]. 2. The pango warning can already be observed with the current Cygwin emacs after the recent update of the GNOME libraries. To reproduce, install the emacs-X11 package and start emacs with the command `emacs &' in an xterm window. Ken -- 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/ From angelo.graziosi@alice.it Mon Nov 28 08:49:00 2011 From: angelo.graziosi@alice.it (Angelo Graziosi) Date: Mon, 28 Nov 2011 08:49:00 -0000 Subject: Problems with emacs built against gtk3 Message-ID: <4ED34B06.9060008@alice.it> Ken Brown wrote: > I don't think gtk3 is the culprit here after all. I uninstalled libgtk3_0 and libgtk3-devel and rebuilt emacs, but the problem persisted. It was only after uninstalling dconf-service (a dependency of libgtk3_0) that things went back to normal. I can confirm. I uninstalled (forcing) ONLY dconf-service and Emacs works again. Thanks to Ken for having found this workaround... Ciao, Angelo. -- 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/ From alexander.sahler@brodos.de Mon Nov 28 12:57:00 2011 From: alexander.sahler@brodos.de (alexander.sahler@brodos.de) Date: Mon, 28 Nov 2011 12:57:00 -0000 Subject: 1.11.2.0: Avoid dialogs to pop up in the center of a two-monitor setup Message-ID: <4ED3933A0200005600078729@pulsar.brodosmit.de> I use XWin to start remote applications (debian server) on a dual-headed Windows desktop environment. The login is done using putty with X forwarding enabled, as the server does not provide Xdmcp, the reason for which is out of scope here. When I start netbeans (for instance) the scplash screen and all dialogs are centered on the display :0 which is of size 3840x1080 because of the two monitors of having 1920x1080 px each. That is, the dialog is split by the monitor borders, which is very annoying. After some investigation I read about the xinerama extension, which should solve this problem. So I tried to start XWin this way: XWin +xinerama -screen 0 @1 -rootless -screen 1 @2 -rootless With this configuration the Server is able to place the dialogs correctly, that is, in the center of a monitor (not the whole workspace) - thanks to xinerama. But I don't have a Window manager that's decorating the windows! OK, I can start a window manager on the server side - that works for sure - but what if I minimize a window? For the windows aren't managed by the Window's window manager, they are not displayed at the task bar. So I have to start a panel on the server side as well (gnome panel for instance). I would prefer to use the xwinwm locally (by running DISPLAY=:0.0 xwinwm in a second bash), but this doesn't work. Xwinwm tells me: Xlib: extension "Windows-WM" missing on display ":0.0". BScreen::BScreen: managing screen 0 using visual 0x21, depth 24 Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". void* BlackboxWindow::getHWnd(void) - XGetWindowProperty failed. 0 0 0 0 0 and the decoration is not painted. I tried different things: XWin +xinerama -multiwindow -screen 0 @1 -screen 1 @2 ends up with all remote applications displayed *twice* - one time with borders, the other one without! Is there a solution to this? Did anyone have the same problems? Thanks, Alexander. -- Mit freundlichen Gr????en Dr. Alexander Sahler Brodos AG Erlanger Stra??e 9-13 D-91083 Baiersdorf Telefon: +49 9133 7770 ??? 4280 Fax: +49 9133 7770 ??? 4808 Email: alexander.sahler@brodos.de http://www.brodos.de ( http://www.brodos.de/ ) Vorsitzender des Aufsichtsrats: Dr. Horst Brokelmann Vorstand: Dominik Brokelmann (Vorsitzender), Stefan Vitzithum Brodos AG mit Sitz in Baiersdorf HRB Nr. B 7677 Amtsgericht F??rth Umsatzsteuer: ID Nr. DE159605590 -- 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/ From alexander.sahler@brodos.de Mon Nov 28 15:01:00 2011 From: alexander.sahler@brodos.de (alexander.sahler@brodos.de) Date: Mon, 28 Nov 2011 15:01:00 -0000 Subject: 1.11.2.0: Avoid dialogs to pop up in the center of a two-monitor setup Message-ID: <4ED3B0210200005600078789@pulsar.brodosmit.de> I use XWin to start remote applications (debian server) on a dual-headed Windows desktop environment. The login is done using putty with X forwarding enabled, as the server does not provide Xdmcp, the reason for which is out of scope here. When I start netbeans (for instance) the scplash screen and all dialogs are centered on the display :0 which is of size 3840x1080 because of the two monitors of having 1920x1080 px each. That is, the dialog is split by the monitor borders, which is very annoying. After some investigation I read about the xinerama extension, which should solve this problem. So I tried to start XWin this way: XWin +xinerama -screen 0 @1 -rootless -screen 1 @2 -rootless With this configuration the Server is able to place the dialogs correctly, that is, in the center of a monitor (not the whole workspace) - thanks to xinerama. But I don't have a Window manager that's decorating the windows! OK, I can start a window manager on the server side - that works for sure - but what if I minimize a window? For the windows aren't managed by the Window's window manager, they are not displayed at the task bar. So I have to start a panel on the server side as well (gnome panel for instance). I would prefer to use the xwinwm locally (by running DISPLAY=:0.0 xwinwm in a second bash), but this doesn't work. Xwinwm tells me: Xlib: extension "Windows-WM" missing on display ":0.0". BScreen::BScreen: managing screen 0 using visual 0x21, depth 24 Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". Xlib: extension "Windows-WM" missing on display ":0.0". void* BlackboxWindow::getHWnd(void) - XGetWindowProperty failed. 0 0 0 0 0 and the decoration is not painted. I tried different things: XWin +xinerama -multiwindow -screen 0 @1 -screen 1 @2 ends up with all remote applications displayed *twice* - one time with borders, the other one without! Is there a solution to this? Did anyone have the same problems? Thanks, Alexander. -- 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/ From yselkowitz@users.sourceforge.net Wed Nov 30 03:52:00 2011 From: yselkowitz@users.sourceforge.net (Yaakov (Cygwin/X)) Date: Wed, 30 Nov 2011 03:52:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: <4ED0EC50.4090300@cornell.edu> References: <4ED03512.7080607@cornell.edu> <4ED0EC50.4090300@cornell.edu> Message-ID: <1322625099.6420.9.camel@YAAKOV04> On Sat, 2011-11-26 at 08:40 -0500, Ken Brown wrote: > On 11/25/2011 7:38 PM, Ken Brown wrote: > > When I build emacs against gtk3, it is unusable. Here are the symptoms > > when the resulting emacs is started in an xterm window: > > > > $ ./emacs -Q& > > [1] 3344 > > > > (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of > > a child process was requested but SIGCHLD action was set to SIG_IGN and > > ECHILD was received by waitpid(), so exit status can't be returned. This > > is a bug in the program calling g_spawn_sync(); either don't request the > > exit status, or don't set the SIGCHLD action. > > > > ** (emacs:3344): WARNING **: Abnormal program termination spawning > > command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 > > --binary-syntax --close-stderr': > > > > I think the pango warning is Cygwin specific, but the rest of it might > > not be. Similar symptoms were reported on Fedora: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=654027 This appears to be the same bug. The solution is to launch a DBus session bus *before* starting emacs (or any other gtk3 programs for that matter), IOW: $ eval `dbus-launch --sh-syntax` $ emacs-X11 & The first command should be added to the beginning of your ~/.startxwinrc, if you're using startxwin (or its shortcut) to start the X server. BTW, please be sure to reinstall dconf-service, that's not the problem, and you're going to need it in the "new world order" of GNOME 3. > 2. The pango warning can already be observed with the current Cygwin > emacs after the recent update of the GNOME libraries. To reproduce, > install the emacs-X11 package and start emacs with the command `emacs &' > in an xterm window. I cannot reproduce this. Does installing font-cantarell-otf help? Perhaps another font? 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/ From pavel.holejsovsky@gmail.com Wed Nov 30 10:25:00 2011 From: pavel.holejsovsky@gmail.com (Pavel Holejsovsky) Date: Wed, 30 Nov 2011 10:25:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: <1322625099.6420.9.camel@YAAKOV04> References: <4ED03512.7080607@cornell.edu> <4ED0EC50.4090300@cornell.edu> <1322625099.6420.9.camel@YAAKOV04> Message-ID: On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: >> 2. The pango warning can already be observed with the current Cygwin >> emacs after the recent update of the GNOME libraries. To reproduce, >> install the emacs-X11 package and start emacs with the command `emacs&' >> in an xterm window. > > I cannot reproduce this. Does installing font-cantarell-otf help? > Perhaps another font? I can reproduce it, in fact almost every gtk-enabled application spits that out. I tried stracing, and I think (but I'm not sure) that the warning appears after pango tries to load /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll -> there is no /usr/lib/pango directory on my system, and it seems that no package in cygwin or ports repository provides it. HTH, Pavel -- 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/ From yselkowitz@users.sourceforge.net Wed Nov 30 11:54:00 2011 From: yselkowitz@users.sourceforge.net (Yaakov (Cygwin/X)) Date: Wed, 30 Nov 2011 11:54:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: References: <4ED03512.7080607@cornell.edu> <4ED0EC50.4090300@cornell.edu> <1322625099.6420.9.camel@YAAKOV04> Message-ID: <1322654060.7644.0.camel@YAAKOV04> On Wed, 2011-11-30 at 11:17 +0100, Pavel Holejsovsky wrote: > On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: > >> 2. The pango warning can already be observed with the current Cygwin > >> emacs after the recent update of the GNOME libraries. To reproduce, > >> install the emacs-X11 package and start emacs with the command `emacs&' > >> in an xterm window. > > > > I cannot reproduce this. Does installing font-cantarell-otf help? > > Perhaps another font? > > I can reproduce it, in fact almost every gtk-enabled application spits > that out. I tried stracing, and I think (but I'm not sure) that the > warning appears after pango tries to load > /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll -> there is no > /usr/lib/pango directory on my system, and it seems that no package in > cygwin or ports repository provides it. That's the clue I needed. I switched pango to builtin modules over a year ago in Ports to help minimize fork() errors, but that didn't reach the distro until now. If I'm right, removing /etc/pango/pango.modules should fix it. 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/ From kbrown@cornell.edu Wed Nov 30 12:27:00 2011 From: kbrown@cornell.edu (Ken Brown) Date: Wed, 30 Nov 2011 12:27:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: <1322654060.7644.0.camel@YAAKOV04> References: <4ED03512.7080607@cornell.edu> <4ED0EC50.4090300@cornell.edu> <1322625099.6420.9.camel@YAAKOV04> <1322654060.7644.0.camel@YAAKOV04> Message-ID: <4ED62104.7080008@cornell.edu> On 11/30/2011 6:54 AM, Yaakov (Cygwin/X) wrote: > On Wed, 2011-11-30 at 11:17 +0100, Pavel Holejsovsky wrote: >> On 11/30/2011 4:51 AM, Yaakov (Cygwin/X) wrote: >>>> 2. The pango warning can already be observed with the current Cygwin >>>> emacs after the recent update of the GNOME libraries. To reproduce, >>>> install the emacs-X11 package and start emacs with the command `emacs&' >>>> in an xterm window. >>> >>> I cannot reproduce this. Does installing font-cantarell-otf help? >>> Perhaps another font? >> >> I can reproduce it, in fact almost every gtk-enabled application spits >> that out. I tried stracing, and I think (but I'm not sure) that the >> warning appears after pango tries to load >> /usr/lib/pango/1.6.0/modules/pango-basic-fc.dll -> there is no >> /usr/lib/pango directory on my system, and it seems that no package in >> cygwin or ports repository provides it. > > That's the clue I needed. I switched pango to builtin modules over a > year ago in Ports to help minimize fork() errors, but that didn't reach > the distro until now. If I'm right, removing /etc/pango/pango.modules > should fix it. That fixes it. Thanks. Ken -- 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/ From kbrown@cornell.edu Wed Nov 30 14:09:00 2011 From: kbrown@cornell.edu (Ken Brown) Date: Wed, 30 Nov 2011 14:09:00 -0000 Subject: Problems with emacs built against gtk3 In-Reply-To: <1322625099.6420.9.camel@YAAKOV04> References: <4ED03512.7080607@cornell.edu> <4ED0EC50.4090300@cornell.edu> <1322625099.6420.9.camel@YAAKOV04> Message-ID: <4ED6390C.2040708@cornell.edu> On 11/29/2011 10:51 PM, Yaakov (Cygwin/X) wrote: > On Sat, 2011-11-26 at 08:40 -0500, Ken Brown wrote: >> On 11/25/2011 7:38 PM, Ken Brown wrote: >>> When I build emacs against gtk3, it is unusable. Here are the symptoms >>> when the resulting emacs is started in an xterm window: >>> >>> $ ./emacs -Q& >>> [1] 3344 >>> >>> (emacs:3344): GLib-WARNING **: In call to g_spawn_sync(), exit status of >>> a child process was requested but SIGCHLD action was set to SIG_IGN and >>> ECHILD was received by waitpid(), so exit status can't be returned. This >>> is a bug in the program calling g_spawn_sync(); either don't request the >>> exit status, or don't set the SIGCHLD action. >>> >>> ** (emacs:3344): WARNING **: Abnormal program termination spawning >>> command line `dbus-launch --autolaunch=0b8f184fe6d82872ee8db8724ecfdb90 >>> --binary-syntax --close-stderr': >>> >>> I think the pango warning is Cygwin specific, but the rest of it might >>> not be. Similar symptoms were reported on Fedora: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=654027 > > This appears to be the same bug. The solution is to launch a DBus > session bus *before* starting emacs (or any other gtk3 programs for that > matter), IOW: > > $ eval `dbus-launch --sh-syntax` > $ emacs-X11& That gets rid of the warning, but emacs still dies after a few seconds (no error message, no stackdump), unless I uninstall dconf-service. I'll see if I can get more information by running emacs under gdb. I'd appreciate any suggestions you might have as to where I should look. I forgot to say in my first post that the emacs I'm testing is a pretest of the upcoming emacs-24.1. If I'm not able to figure out what's going on, maybe I'll make an experimental version available so that you can try to reproduce the problem. Ken -- 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/