Re: considering modifier keys after gaining focus
Hi Jon, On 1/11/2012 6:16 PM, Jon TURNEY wrote: I think it is useful to consider this history when reviewing a patch, Are we going in circles? Are we doing in the wrong direction? I appreciate your carefulness und thoroughness. It's of course always better to understand what is going on, especially in a large code base with a long history. Anyhow, in a brief look at some mailing list discussions from 2002 or so, it seems that: i) We must release modifier keys when focus leaves the X server, as modifier keys may be part of a Windows shell shortcut which moves the focus elsewhere, e.g. alt-tab) so the key-release isn't received by the X server. Ah ok, so my guess was in the right direction ;-) ii) We must release non-modifier keys when focus leaves the X server, or they continue to auto-repeat in the X server (specifically a problem when a key-press closes a window (such as typing ctrl-d or exit into an Xterm), as the key-release goes to the next window to receive focus, which may not be an X window) Interesting, I didn't know this. Thank you for figuring this out from the malinglists archives. iv) What should we do about held non-modifier keys when focus enters the X server? It looks like these should be pressed as well for strict correctness. If we hold down a non-modifier key so it auto-repeats, and move the focus between X and native windows, the native windows receive repeats, but the the X windows do not. I doubt many people care about this behaviour, though :-) Yes, you are right: I can reproduce this phenomenon by holding down Ctrl+N for opening windows and the key is not autorepeated (so only one window is opened, whereas under Linux xserver many windows are opened). In my daily usage I didn't discover this phenomenon. My patch only addresses the problem, that the modifier keys are not right after keyboard driven focus change, disrupting my workflow. So I agree that there might not many people caring about this behaviour. Hm... on looking at this again, isn't that code you are adding checking the internal state of non-latching modifiers bogus? If we release all keys on WM_KILLFOCUS, then the non-latching modifiers will always be clear when the WM_SETFOCUS occurs, so we will always generate the keypress for the modifier. Yes, my patch also generates key release events for modifiers despite the fact, that all modifier have been released after the xserver looses the window focus. When writing the patch, I wasn't sure if this is always the case, so I made the code a little bit more robust in the sense that it tries to correct the modifier keys in any case (so it will always work, even if something goes wrong in other code locations). Best regards, Oliver -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: considering modifier keys after gaining focus
On 1/12/2012 1:19 PM, Oliver Schmidt wrote: On 1/11/2012 6:16 PM, Jon TURNEY wrote: Hm... on looking at this again, isn't that code you are adding checking the internal state of non-latching modifiers bogus? If we release all keys on WM_KILLFOCUS, then the non-latching modifiers will always be clear when the WM_SETFOCUS occurs, so we will always generate the keypress for the modifier. Yes, my patch also generates key release events for modifiers despite the fact, that all modifier have been released after the xserver looses the window focus. When writing the patch, I wasn't sure if this is always the case, so I made the code a little bit more robust in the sense that it tries to correct the modifier keys in any case (so it will always work, even if something goes wrong in other code locations). My answer is perhaps a little bit unexact. To be more precise: +BOOL ctrl = (GetAsyncKeyState (VK_CONTROL) 0); +if (WIN_XOR (internalKeyStates ControlMask, ctrl)) + winSendKeyEvent (KEY_LCtrl, ctrl); The above code fragment will send a key press event for the ctrl key, if the current real ctrl modifier state is pressed and differs from the xserver's internal key state for ControlMask. It will send a key release event for the ctrl key, if the current real ctrl modifier state is not pressed and differs from the xserver's internal key state for ControlMask. Best regards, Oliver -- 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/
Shift Function Key not working because of a bug in xkeyboard-config-2.4.1
Please be aware that Shift Function Key (e.g., Shift + F3) is not working with xkeyboard-config-2.4.1-1. You can verify that by running xev. This problem is known in X11 community and apparently a fix is on its way and may already be available in 2.4.1-r2 - see http://forums.funtoo.org/viewtopic.php?id=817. In the meantime you can avoid this problem by going back to xkeyboard-config-2.3-1. -- 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/
src/winsup/doc ChangeLog new-features.sgml
CVSROOT:/cvs/src Module name:src Changes by: yselkow...@sourceware.org 2012-01-12 17:42:11 Modified files: winsup/doc : ChangeLog new-features.sgml Log message: * new-features.sgml (ov-new1.7.10): Document tgmath.h. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/ChangeLog.diff?cvsroot=srcr1=1.372r2=1.373 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/doc/new-features.sgml.diff?cvsroot=srcr1=1.97r2=1.98
[PATCH] doc: tgmath.h
New header just committed to newlib. Patch attached. Yaakov 2012-01-?? Yaakov Selkowitz yselkowitz@... * new-features.sgml (ov-new1.7.10): Document tgmath.h. Index: new-features.sgml === RCS file: /cvs/src/src/winsup/doc/new-features.sgml,v retrieving revision 1.97 diff -u -p -r1.97 new-features.sgml --- new-features.sgml 6 Jan 2012 07:13:11 - 1.97 +++ new-features.sgml 12 Jan 2012 11:25:14 - @@ -72,6 +72,10 @@ Also, perror and strerror_r no longer cl /para/listitem listitempara +C99 gt;tgmath.hlt; type-generic macros. +/para/listitem + +listitempara /proc/loadavg now shows the number of currently running processes and the total number of processes. /para/listitem
Re: [PATCH] doc: tgmath.h
On Jan 12 05:28, Yaakov (Cygwin/X) wrote: New header just committed to newlib. Patch attached. Yup, go ahead. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Cannot implement -x switch for diff
Hello, I want to compare the contents of two large directories whilst omitting two subdirectories console5/ and console7/ common to both. But using any combination of diff -rq /d1 /d2 -x console diff -rq /d1 /d2 -x console. diff -rq /d1 /d2 -x console./ (and several others I thought might work) the subdirectories are not skipped. (I've tried -X with a file argument though I prefer -x with a pattern argument as above with no requirement to create files. Also, I would like to utilise the trailing / after -x so that any files that happened to be named console* would undergo comparison, only the subdirectories are skipped.) Any ideas? Fergus -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Opening new cygwin window with arguments
On 12 January 2012 03:07, Jon Hughes wrote: What I want to do is open a new cygwin window with a tail command, so I have the parent process still running, and this runoff process in another window. I've found cygstart, but I can't figure out the syntax to do essentially this: cygstart sh tail -f foo Just do: cygstart tail -f foo This works because Windows automatically creates a console window for programs that need one, i.e. you don't need sh in there. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Can't get includes untangled
On 10/01/2012 19:25, Larry Hall (Cygwin) wrote: On 1/10/2012 2:17 PM, Jarome wrote: When I make my Windows 7 cygwin project, I keep getting In file included from /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../ include/w32api/windows.h:98:0, from src/tkfPusher.c:23: /usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../include/w32api/ winsock2.h:103:2: warning: #warning fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets Everything works in MinGW. Don't include windows files for Cygwin. Think of Cygwin as a UNIX/Linux environment. Anything you wouldn't include there shouldn't be included when building for Cygwin. That's a simple rule to follow that will avoid some problems, but I thought mixed-mode coding wasn't actually prohibited and we don't actually go out of our way to break it - hence the existence of __USE_W32_SOCKETS in the first place, no? To Jarome: I tried adding the #define __USE_W32_SOCKETS to try and fix this because if defined, it should ignore the fd things in types.h, but no success. The problem is that you're not defining it early enough: #define GPC_CYGWIN #define GPC_WIN #include stdio.h #include errno.h #include dirent.h // This includes sys/types.h Yes, it does, so __USE_W32_SOCKETS should already have been defined by that point or it's too late; both winsock2.h *and* sys/types.h have to be #included while it is already in effect (they both contain #ifdefs that test it). And in fact, stdio.h also indirectly include sys/types.h, so the simple answer is just to define __USE_W32_SOCKETS right at the top alongside the other defines before you even include the first file. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cannot implement -x switch for diff
On 12/01/2012 09:17, Fergus wrote: Hello, I want to compare the contents of two large directories whilst omitting two subdirectories console5/ and console7/ common to both. But using any combination of diff -rq /d1 /d2 -x console diff -rq /d1 /d2 -x console. diff -rq /d1 /d2 -x console./ That's regex notation. Have you tried a glob pattern instead? cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Intermittent crashes of tcsh...
As described in several reports over the past couple of years, such as: http://cygwin.com/ml/cygwin/2011-01/msg00390.html I too am seeing regular (once or twice per day) crashes from tcsh. I'm also running Windows 7 (64-bit) with rxvt (several running). This has been an ongoing irritation. It's clearly not really an out of memory problem. It's more likely an uninitialized variable type of issue. Regards. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: MinGW gfortran and OpenMP issues...
Andrey, I have done this, but no difference. I copied the pthreadGC2.dll from the appropriate MinGW lib in cygwin to the folder and it runs fine! There is another problem however. While the program says it is running with 3 threads, it only runs using 25% cpu, spread over 3 cores (Core i5, quad core) (when I say spread, it's not constant, it seems to jump about over the cores 0, 1 and 2) . This occurs when I run from cmd or cygwin. Interstingly, the same behaviour is observed when I only run it with one thread. The same code compiled with ifort on linux runs great with the same input on 3 threads using 3 cores (i.e. 300% cpu) or 1 core if I choose. Is there a way to flex all cores on a windows box with OpenMP?? Nick -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Opening new cygwin window with arguments
On 1/11/2012 10:38 PM, Paul Allen Newell wrote: On 1/11/2012 10:26 PM, Daniel Colascione wrote: Are you using Cygwin vim or a native win32 vim? Win32 console programs generally aren't happy in mintty, and you should use their Cygwin equivalents. Daniel: Thanks for the prompt reply. I just did a which on vim and can see that it is referencing /cygdrive/c/Program Files/Vim/vim72/vim. My bad as I should have checked that .. I somehow was convinced that I had gotten a vim from cygwin setup. Let me correct that and see if things work. Once again, thanks, Paul Daniel: Installing and running /usr/bin/vim sure works alot better ... thanks for pointing out my oversight. Things are a bit screwy on the Windows side, but that's not a Cygwin issue. Paul -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
trouble with cgreen test runner in cygwin
Hi gang, Long time no post :) We wrote a kind of reflective test runner for the cgreen unit testing framework, which uses dlopen() and dlsym(). We're getting a failure under Cygwin and could use some guidance on how to debug the issue. While we suspect it's related to this post, http://cygwin.com/ml/cygwin/2010-02/msg00109.html , we can't be sure. Steps: -install required cygwin packages: cmake, gcc4, g++4, make, subversion, etc -check out cgreen: svn co http://cgreen.svn.sourceforge.net/svnroot/cgreen/trunk/cgreen -cd cgreen mkdir obj cd obj cmake .. -make -verify the tests pass: tests/test_cgreen -now try the test-runner: tools/cgreen-runner tests/cygcgreen_tests.dll the test-runner discovers the tests correctly, but when it goes to run them, it fails. this is because the CgreenTest* we fetch via dlsym() appears to be corrupt. We'll reduce it to an even smaller, self-contained test case tomorrow. If anyone has ideas/suggestions in the meantime, please let me know. Thanks in advance! -- tangled strands of DNA explain the way that I behave. http://www.clock.org/~matt -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bad address error with redirection (stdout and stderr) in background process
Christopher Faylor writes: No need to answer that. The upcoming snapshot should fix the problem. I forgot to say: Thanks for the simple test case. Those are always much appreciated. thanks a lot for your great work. Is it possible to create a new snapshot til monday? best regards Heiko -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Bad address error with redirection (stdout and stderr) in background process
On Fri, Jan 13, 2012 at 05:32:02AM +, Heiko Elger wrote: Christopher Faylor writes: No need to answer that. The upcoming snapshot should fix the problem. I forgot to say: Thanks for the simple test case. Those are always much appreciated. thanks a lot for your great work. Is it possible to create a new snapshot til monday? ? The snapshot that I was referring to was created shortly after my above email went out. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
