Re: Slow response to keypresses in xorg-server-1.8.0-1

[Ken Brown <kbrown@cornell.edu>]

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/