Re: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. Attached is a small test-case which seems to demonstrate this problem. Run ./dev-windows-select-test and observe select() blocks for the full timeout, despite the fact that the /dev/windows fd is ready for reading (and it reported as such as the end of the timeout) If you run './dev-windows-select-test -skip' to skip the PeekMessage(), select() returns immediately, indicating the /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an invalid argument error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 30/08/2010 12:23, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. Attached is a small test-case which seems to demonstrate this problem. Run ./dev-windows-select-test and observe select() blocks for the full timeout, despite the fact that the /dev/windows fd is ready for reading (and it reported as such as the end of the timeout) If you run './dev-windows-select-test -skip' to skip the PeekMessage(), select() returns immediately, indicating the /dev/windows fd is ready for reading. Again, thanks for the testcase. I applied a patch to Cygwin which should make select on /dev/windows fully functional. The blessed solution is to replace the call to MsgWaitForMultipleObjects with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE flag set. This flag is defined to do exactly what we need. The only downside is that this flag does not exist on NT4 and its usage results in an invalid argument error. So, for NT4, I added the workaround I described in my yesterday's soliloquy. I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please give it a test as soon as possible. Here's a binary DLL for testing (build w/o optimization, so it's probably a bit slow): http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2 (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e) Thanks Corinna :-) I tried that cygwin DLL with my test case, and with an X server with what I now realize is the workaround I'd applied reverted [1] and it seems to work fine. [1] http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8id=6da3190eacae2c2b021060f8fd9427816ac06f21 -- 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/
/dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the full
timeout, despite the fact that the /dev/windows fd is ready for reading (and
it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the PeekMessage(),
select() returns immediately, indicating the /dev/windows fd is ready for reading.
#include stdio.h
#include fcntl.h
#include sys/select.h
#include errno.h
#include windows.h
// gcc -o dev-windows-select-test.exe dev-windows-select-test.c -Wall -mwindows
int main(int argc, char *argv[])
{
int fd = open(/dev/windows, O_RDONLY);
if (PostMessage(NULL, WM_USER, 0, 0) != 0)
printf(PostMessage succeeded\n);
else
printf(PostMessage failed\n);
if (argc = 1)
{
MSG msg;
if (PeekMessage(msg, NULL, 0, 0, PM_NOREMOVE))
printf(PeekMessage reports a message available\n);
}
struct timeval timeout;
timeout.tv_sec = 5;
timeout.tv_usec = 0;
fd_set readfds;
FD_ZERO(readfds);
FD_SET(fd, readfds);
int rc = select(fd+1, readfds, NULL, NULL, timeout);
printf(select returned %d %s\n, rc, strerror(errno));
return 0;
}
--
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: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 14:39, Jon TURNEY wrote:
On 08/08/2010 12:04, Andy Koppe wrote:
On 7 August 2010 23:07, Jon TURNEY wrote:
Hmmm, looking again at the implementation of select(), I don't immediately
see that when waiting on /dev/windows, it checks that the message queue has
old messages on it before waiting. The MSDN documentation for
MsgWaitForMultipleObjects() seems to says that messages which had arrived
before the last PeekMessage() etc. aren't considered new and so don't end
the wait?
I think you're right, a call to PeekMessage is needed for proper
select() semantics: it shouldn't block if data is available for
reading.
Attached is a small test-case which seems to demonstrate this problem.
Run ./dev-windows-select-test and observe select() blocks for the
full timeout, despite the fact that the /dev/windows fd is ready for
reading (and it reported as such as the end of the timeout)
If you run './dev-windows-select-test -skip' to skip the
PeekMessage(), select() returns immediately, indicating the
/dev/windows fd is ready for reading.
[...]
Thanks for the testcase. I examined this and I think I have a
workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for
MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the
wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I
did was to add the QS_ALLPOSTMESSAGE flag to the
MsgWaitForMultipleObjects call in select.cc, and to change the
PeekMessage call in select.cc:peek_windows() from
PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE)
to
PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE)
Same in your above test application. This appears to do the trick.
However, I'm not exactly sure if that's a valid fix. Patch below.
Corinna
Index: select.cc
===
RCS file: /cvs/src/src/winsup/cygwin/select.cc,v
retrieving revision 1.160
diff -u -p -r1.160 select.cc
--- select.cc 2 Apr 2010 22:36:44 - 1.160
+++ select.cc 29 Aug 2010 14:16:18 -
@@ -287,7 +287,8 @@ select_stuff::wait (fd_set *readfds, fd_
if (!windows_used)
wait_ret = WaitForMultipleObjects (m, w4, FALSE, ms);
else
- wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms, QS_ALLINPUT);
+ wait_ret = MsgWaitForMultipleObjects (m, w4, FALSE, ms,
+ QS_ALLINPUT | QS_ALLPOSTMESSAGE);
switch (wait_ret)
{
@@ -1531,7 +1532,7 @@ peek_windows (select_record *me, bool)
if (me-read_selected me-read_ready)
return 1;
- if (PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE))
+ if (PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE))
{
me-read_ready = true;
select_printf (window %d(%p) ready, me-fd, me-fh-get_handle ());
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: /dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]
We are listening and learning :-) Dave Sent from my iPad On Aug 29, 2010, at 9:51 AM, Corinna Vinschen corinna-cyg...@cygwin.com wrote: On Aug 29 16:41, Corinna Vinschen wrote: On Aug 29 16:17, Corinna Vinschen wrote: On Aug 29 14:39, Jon TURNEY wrote: On 08/08/2010 12:04, Andy Koppe wrote: On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? [...] Thanks for the testcase. I examined this and I think I have a workaround. MSDN states that there's a flag QS_ALLPOSTMESSAGE for MsgWaitForMultipleObjects, which is not cleared by PeekMessage, if the wMsgFilterMin and wMsgFilterMax arguments are not both 0. So, what I did was to add the QS_ALLPOSTMESSAGE flag to the MsgWaitForMultipleObjects call in select.cc, and to change the PeekMessage call in select.cc:peek_windows() from PeekMessage (m, (HWND) h, 0, 0, PM_NOREMOVE) to PeekMessage (m, (HWND) h, 1, UINT_MAX, PM_NOREMOVE) Same in your above test application. This appears to do the trick. However, I'm not exactly sure if that's a valid fix. Patch below. Hmm, this ignores the potential WM_NULL message, afaics. For some reason, using PeekMessage (m, (HWND) h, 0, UINT_MAX, PM_NOREMOVE) results in MsgWaitForMultipleObjects hanging, too. OTOH, using PeekMessage (m, (HWND) h, 0, 16, PM_NOREMOVE) PeekMessage (m, (HWND) h, 17, UINT_MAX, PM_NOREMOVE) does not. Go figure. Yeah, I realize I'm talking to myself, but this works, too: PeekMessage (m, (HWND) h, 0, UINT_MAX - 1, PM_NOREMOVE) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 7 August 2010 23:07, Jon TURNEY wrote: Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? I think you're right, a call to PeekMessage is needed for proper select() semantics: it shouldn't block if data is available for reading. I think it's a good idea anyway though to drain the message queue before invoking select() on /dev/windows, except if there's a possibility that message handling blocks out events on other files for too long. That's because select() has a lot more overhead than PeekMessage. 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/
Re: Slow response to keypresses in xorg-server-1.8.0-1
2010/8/5 Laurent Montaron l...@pobox.com: The workaround in XWin.20100630-git-bc2f74e105146c36.exe definitely fixes the problem. I have been running with it for two days now. Did anyone find out if root cause is a bug in /dev/windows implementation or something else? It just smells like so, because my perl-tk patches to use /dev/windows as messageloop fail, while the windows loop works fine. -- Reini Urban -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 07/08/2010 16:39, Reini Urban wrote: 2010/8/5 Laurent Montaronl...@pobox.com: The workaround in XWin.20100630-git-bc2f74e105146c36.exe definitely fixes the problem. I have been running with it for two days now. Did anyone find out if root cause is a bug in /dev/windows implementation or something else? It just smells like so, because my perl-tk patches to use /dev/windows as messageloop fail, while the windows loop works fine. That's interesting. Hmmm, looking again at the implementation of select(), I don't immediately see that when waiting on /dev/windows, it checks that the message queue has old messages on it before waiting. The MSDN documentation for MsgWaitForMultipleObjects() seems to says that messages which had arrived before the last PeekMessage() etc. aren't considered new and so don't end the wait? But I could easily be missing something... -- 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: Slow response to keypresses in xorg-server-1.8.0-1
The workaround in XWin.20100630-git-bc2f74e105146c36.exe definitely fixes the problem. I have been running with it for two days now. Did anyone find out if root cause is a bug in /dev/windows implementation or something else? On 11:59, Jon TURNEY wrote: Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.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/
Re: Re: Slow response to keypresses in xorg-server-1.8.0-1
On 8:59 PM, Jon TURNEY wrote: I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 I just downloaded this version, and it indeed fixes the slow [alt]-[tab] behavior, but I'm still having one problem: the invisible xterm root window covers my windows taskbar until I've moused over it for several seconds (or alt-tab somewhere else first). Ideas? 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/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 20/07/2010 00:00, Angelo Graziosi wrote: Il 19/07/2010 17.45, Simon Marlow ha scritto: On 19/07/2010 15:51, Angelo Graziosi wrote: Simon Marlow wrote: I use the VirtuaWin virtual-desktop tool, and found that often when switching to a desktop with XWin windows on it, the windows would remain blank until I right-clicked on the XWin icon in the tray, when they would refresh. Strange. It is more than an year I use VirtuaWin (now 4.2) without problems with X, and I use the not-patched XWin.exe, i.e. that from original 1.8.0-1 package. Perhaps you have a BLODA[*]? I have MS Forefront client security, configured to omit the Cygwin directories, but I really doubt that's the problem. Have you tried without it (uninstalled)? No, and I can't on this machine (local security policy). I did try using different hiding methods for XWin windows in VirtuaWin, but didn't find anything that worked. VirtuaWin comes in two 'flavors': *with* and *without* unicode support. Which are you using? Have you tried the other? That seems like a long shot to me. Do you have reason to believe it would make any difference? Cheers, Simon -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 30/06/2010 18:40, Jon TURNEY wrote: This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 I experienced similar symptoms after upgrading to 1.8 recently, and the above XWin binary seems to be doing the trick so far. I use the VirtuaWin virtual-desktop tool, and found that often when switching to a desktop with XWin windows on it, the windows would remain blank until I right-clicked on the XWin icon in the tray, when they would refresh. Incidentally even with previous versions of Cygwin/X, VirtuaWin and Cygwin/X don't cooperate very well - when I switch from one desktop containing X windows to another, I see the content of the previous desktop's windows in the new ones (i.e. the windows in the desktop I switched to haven't refreshed their content). I don't know whose fault this is, and I realise this isn't a well-characterised bug report, so feel free to take it or leave it. Cheers, Simon -- 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: Slow response to keypresses in xorg-server-1.8.0-1
Simon Marlow wrote: I use the VirtuaWin virtual-desktop tool, and found that often when switching to a desktop with XWin windows on it, the windows would remain blank until I right-clicked on the XWin icon in the tray, when they would refresh. Strange. It is more than an year I use VirtuaWin (now 4.2) without problems with X, and I use the not-patched XWin.exe, i.e. that from original 1.8.0-1 package. Perhaps you have a BLODA[*]? Ciao, Angelo. --- [*] http://cygwin.com/faq/faq.using.html#faq.using.bloda -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 19/07/2010 15:51, Angelo Graziosi wrote: Simon Marlow wrote: I use the VirtuaWin virtual-desktop tool, and found that often when switching to a desktop with XWin windows on it, the windows would remain blank until I right-clicked on the XWin icon in the tray, when they would refresh. Strange. It is more than an year I use VirtuaWin (now 4.2) without problems with X, and I use the not-patched XWin.exe, i.e. that from original 1.8.0-1 package. Perhaps you have a BLODA[*]? I have MS Forefront client security, configured to omit the Cygwin directories, but I really doubt that's the problem. More details about what I do to reproduce the not-refreshing problem (not the blank window problem, that seems to be fixed by the patched XWin binary, and judging by other comments in this thread seems to be a known issue unrelated to VirtuaWin). - multiple xterms running on remote machines displaying locally, over multiple 'ssh -Y' connections, i.e. I do ssh -Y remote-machine xterm - windows are on adjacent desktops, using overlapping areas of the screen - switch between the desktops, note how the windows on the new desktop are still displaying the content of the windows on the previous desktop. Alas, it doesn't always happen, but it happens a lot. In VirtuaWin I have Static taskbar Z order set for On desktop change preserve. I did try using different hiding methods for XWin windows in VirtuaWin, but didn't find anything that worked. Cheers, Simon -- 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: Slow response to keypresses in xorg-server-1.8.0-1
Il 19/07/2010 17.45, Simon Marlow ha scritto: On 19/07/2010 15:51, Angelo Graziosi wrote: Simon Marlow wrote: I use the VirtuaWin virtual-desktop tool, and found that often when switching to a desktop with XWin windows on it, the windows would remain blank until I right-clicked on the XWin icon in the tray, when they would refresh. Strange. It is more than an year I use VirtuaWin (now 4.2) without problems with X, and I use the not-patched XWin.exe, i.e. that from original 1.8.0-1 package. Perhaps you have a BLODA[*]? I have MS Forefront client security, configured to omit the Cygwin directories, but I really doubt that's the problem. Have you tried without it (uninstalled)? In VirtuaWin I have Static taskbar Z order set for On desktop change preserve. As mine... I did try using different hiding methods for XWin windows in VirtuaWin, but didn't find anything that worked. VirtuaWin comes in two 'flavors': *with* and *without* unicode support. Which are you using? Have you tried the other? 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/
Re: Slow response to keypresses in xorg-server-1.8.0-1
Hi, just joined the list. I updated to the latest cygwin today and was having the same problem with X just freezing up in the background. Your fix did the trick. I am profoundly grateful, it was making me batty. Since I've never overwritten an installed binary with cygwin before, wondering whether I will run into any problems later when I need to update. I presume the binary from the patched code won't make it to the mirrors for a while? Thanks, Leigh -- Leigh Orf Associate Professor of Atmospheric Science Room 130G Engineering and Technology Department of Geology and Meteorology Central Michigan University Mount Pleasant, MI 48859 (989)774-1923 Amateur radio callsign: KG4ULP -- 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: Slow response to keypresses in xorg-server-1.8.0-1
--- Mer 30/6/10, Jon TURNEY ha scritto: Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer Jon, the new version has much more responsiveness than 1.8.0-1 the ALT-TAB switch is fluent now. Regards Marco -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 7/1/2010 4:49 PM, Leigh Orf wrote: Hi, just joined the list. I updated to the latest cygwin today and was having the same problem with X just freezing up in the background. Your fix did the trick. I am profoundly grateful, it was making me batty. Since I've never overwritten an installed binary with cygwin before, wondering whether I will run into any problems later when I need to update. I presume the binary from the patched code won't make it to the mirrors for a while? 'setup.exe' will dutifully update it when a new package with an updated version is available. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On 02/05/2010 21:52, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? [1] http://cygwin.com/ml/cygwin-xfree/2010-02/msg00124.html [2] ftp://cygwin.com/pub/cygwinx/XWin.20100630-git-bc2f74e105146c36.exe.bz2 -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 6/30/2010 1:40 PM, Jon TURNEY wrote: On 02/05/2010 21:52, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Thanks for the clear reproduction steps. And thanks to the other reporters of this problem :-) This is fallout from a change [1] to the way we process Windows messages to handle large bursts of them overflowing the Xserver's internal event queue. It seems that sometimes /dev/windows doesn't seem ready to select() even when there is still Windows messages to process. I can't quite understand how this happens. I don't think this is a bug in cygwin, but probably something subtle to do with message ordering and nonqueued messages (like WM_ACTIVATE). Anyhow, I've cooked up a small additional change which should prevent this blocking behaviour and uploaded a build [2]. It seems to resolve the problem in this specific case. Perhaps you could try it out and see if it helps? That seems to have fixed it. I've run it for several hours without any problems. 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/
Re: Slow response to keypresses in xorg-server-1.8.0-1
Wed, 02 Jun 2010 09:52:28 -0700 I have this problem too. I found a weird, non-code partial solution: run some sort of constantly-updating graphical program in the background, like ico or something like that. This workaround is apparently avoiding the X 1.8.0 response problem. I am running xeyes and the slow response problem is no longer getting in the way of using X on a Dell E6410. I am using Version 1.8.0 with a build date of 2010-04-02 . -- 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: Slow response to keypresses in xorg-server-1.8.0-1
On Sat, 01 May 2010 09:49:21, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: I did an upgrade a few days ago and noticed the same thing. If I use another program for a few minutes then try to alt-tab or use the taskbar to go back to the xterm, the xterm will be unresponsive. The time the xterm is unresponsive appears to be related to the amount of time the xterm has not had focus. The longer the xterm is not used, the longer it takes to wake up. Right-clicking on the X icon in the system tray usually wakes the xterm back up. -- 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: Slow response to keypresses in xorg-server-1.8.0-1
I have this problem too. I found a weird, non-code partial solution: run some sort of constantly-updating graphical program in the background, like ico or something like that. I think the problem is that the X server or window manager goes to sleep and won't wake up until you get its attention. I also gave the X server real time priority in windows, but it didn't really help. With ico running in the background, alt-tab works fine. I didn't have it installed with cygwin, so I xhosted it back from my linux box. I hope this is a good enough clue for the X maintainers, I'd look for differences in the code around scheduling and see if there were any optimizations related to sleeping. Thanks, Tony -- 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: Slow response to keypresses in xorg-server-1.8.0-1
Yeah I just saw that as well. Today I upgraded my xserver from 1.7.3 to 1.8.0 and immediately noticed the awkwardness on Alt-Tab. What happened? -- 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: Re: Slow response to keypresses in xorg-server-1.8.0-1
On 8:59 PM, Ken Brown wrote: On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. Is there any progress on this? I'm also seeing these symptoms after upgrading to 1.8. Very annoying. Thanks, 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/
Re: Slow response to keypresses in xorg-server-1.8.0-1
On 5/1/2010 9:49 AM, Ken Brown wrote: I'm often seeing a very slow response to keypresses under xorg-server-1.8.0-1. The problem is intermittent, but it always happens within a few minutes after starting the server (via the start menu shortcut or a slight variant). Here are some examples: 1. Switching windows with Alt-Tab sometimes takes up to 15 seconds or doesn't work at all (i.e., I get tired of waiting to see if the focus is ever going to switch). 2. When using 'less' to view a file in an xterm window, there is sometimes a delayed response to 'space' or 'q'. 3. When viewing a directory in emacs-X11, pressing 'v' to start viewing a file can sometimes result in a long delay, pressing 'space' to scroll in view mode can be slow, and pressing 'q' to exit view mode can be slow. In some of these cases, I sometimes don't get a response to the first keypress until I press a second key. For example, if I'm viewing a file with 'less', I may press 'q' and get no response. Then pressing 'q' a second time exits 'less' and also produces an echoed 'q' in xterm. Similarly, I'll sometimes press a key, see no echo, and then get two characters echoed at once after pressing a second key. Reverting to xorg-server-1.7.6-2 solves the problem. I'm attaching cygcheck output and an XWin log. I found a test case that I can reproduce reliably on my system. 1. With no .Xdefaults or .startxwinrc, start the X server via the start menu shortcut. 2. Start xfig (with 'xfig ' in the xterm window). 3. Repeatedly press Alt-Tab to switch between the xterm and xfig windows. At some point the focus fails to switch. When this happens, press Alt and the focus switches. 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/
