Re: Problem trying to build Cygwin X server from source

[Mark Lillibridge]

Jon TURNEY  writes:

>  This looks like [1], a mis-match in TLS-ness between XWin and libglapi.
>  
>  If you are building using the .cygport file it should have ./configure'ed 
> with
>  --disable-glx-tls?
>  
>  [1] http://www.cygwin.com/ml/cygwin-xfree/2011-10/msg00065.html

Ah!  I had indeed screwed up the configuration -- I was manually
building in src using autogen.sh rather than in build and thus had lost
the configuration set up by cygport.  When I blew everything away and
did the cygport stuff again,

cd /usr/src/
cygport xorg-server.cygport prep
cd /usr/src/
cygport xorg-server.cygport compile

things built fine.  Thank you for all your help!  (To be clear, this
didn't work before the 2 patches you had me make.)

- Mark

--
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: Problem trying to build Cygwin X server from source

[Mark Lillibridge]

Jon TURNEY  writes:

> You will need to apply the attached change to /usr/include/Xpoll.h to fix
> xserver compilation with w32api-headers >= 3.0.0-1, which adds a new WIN32
> define somewhere, which breaks this test.

It's /usr/include/X11/Xpoll.h on my system.  That patch indeed makes
the compilation proceed further.  It's now stuck at:

  CCLD XWin.exe
../../glx/.libs/libglx.a(glxcmds.o): In function `FlushContext':
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:221: 
undefined reference to `__emutls_v._glapi_tls_Dispatch'
../../glx/.libs/libglx.a(glxcmds.o): In function `DoMakeCurrent':
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:623: 
undefined reference to `__emutls_v._glapi_tls_Dispatch'
../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_WaitGL':
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:806: 
undefined reference to `__emutls_v._glapi_tls_Dispatch'
../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_CopyContext':
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:904: 
undefined reference to `__emutls_v._glapi_tls_Dispatch'
../../glx/.libs/libglx.a(glxcmds.o): In function `_glXDisp_SwapBuffers':
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:1647: 
undefined reference to `__emutls_v._glapi_tls_Dispatch'
../../glx/.libs/libglx.a(glxcmds.o):/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/glx/glxcmds.c:1851:
 more undefined references to `__emutls_v._glapi_tls_Dispatch' follow
collect2: error: ld returned 1 exit status
Makefile:890: recipe for target `XWin.exe' failed



> > Tip: Use setup -q -Ppackagename,packagename,etc. to quickly install
> > the required packages.
> > 
> > Darn if I could make this work no matter what I tried.  Really, you
> > should just give the actual code here so people can cut-and-paste.
> > Ideally, you should also specify how to get the needed packages via the
> > setup GUI.
> 
> It's not really the function of that document to tell people how to install
> packages on cygwin.
> 
> I don't really want to put the package list there twice and have to keep both
> copies updated.
> 
> If you're doing the package installation manually, you just find them (perhaps
> using the search function), and select them for installation.

I found that tip useless as in I couldn't make any form of "setup -q
-Pfoo" install a package.  As for the GUI, I believe I just set:

  * X11, editors, shells, net: install
  * X11->xorg-server: source
  * devel: install  [need for cygport]
  * Python: install [for lxml for X server compiling]

This is *way* easier than trying to find the dozens of packages by name
and trying to figure out what to check to get them.

- Mark

--
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: Problem trying to build Cygwin X server from source

[Mark Lillibridge]

Jon TURNEY  writes:

>  On 19/10/2013 20:54, Mark Lillibridge wrote:
>  > 
>  > This is xserver-cygwin-1.14.3-1, the latest as of several weeks ago.
>  > 
>  > The part that is failing (make done in
>  > /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/glx):
>  > 
>  >   CC   wgl_ext_api.lo
>  > In file included from wgl_ext_api.c:72:0:
>  > generated_wgl_wrappers.c:79:1: error: unknown type name 
> 'PFNWGLDXSETRESOURCESHAREHANDLENVPROC'
>  > generated_wgl_wrappers.c:79:1: warning: initialization makes integer from 
> pointer without a cast [enabled by default]
>  > generated_wgl_wrappers.c:80:1: error: unknown type name 
> 'PFNWGLDXOPENDEVICENVPROC'
>  > generated_wgl_wrappers.c:80:1: warning: initialization makes integer from 
> pointer without a cast [enabled by default]
>  > generated_wgl_wrappers.c:81:1: error: unknown type name 
> 'PFNWGLDXCLOSEDEVICENVPROC'
>  > generated_wgl_wrappers.c:81:1: warning: initialization makes integer from 
> pointer without a cast [enabled by default]
>  > ...
>  
>  I think this is error is due to the khronos-opengl-registry package being 
> more
>  recent than the wglext.h provided by w32api-headers.
>  
>  I think the easiest way to work around this is to update wglext.h from
>  http://www.opengl.org/registry/api/GL/wglext.h

Hmmm.  Which occurrence should I replace?

mdl [103]# find /usr -name wglext.h -print
/usr/i686-w64-mingw32/sys-root/mingw/include/GL/wglext.h
/usr/include/GL/wglext.h
/usr/include/w32api/GL/wglext.h
/usr/x86_64-w64-mingw32/sys-root/mingw/include/GL/wglext.h

mdl [112]# grep wglext *
wgl_ext_api.c:#include 
wgl_ext_api.h:#include 

mdl [118]# grep usr/include *
Makefile:DBUS_CFLAGS = -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include  
Makefile:DIX_CFLAGS = -DHAVE_DIX_CONFIG_H $(CWARNFLAGS) 
-fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT 
-I/usr/include/pixman-1 -I/usr/include/freetype2   -I$(top_srcdir)/include 
-I$(top_builddir)/include -I$(top_srcdir)/Xext -I$(top_srcdir)/composite 
-I$(top_srcdir)/damageext -I$(top_srcdir)/xfixes -I$(top_srcdir)/Xi 
-I$(top_srcdir)/mi -I$(top_srcdir)/miext/sync -I$(top_srcdir)/miext/shadow  
-I$(top_srcdir)/miext/damage -I$(top_srcdir)/render -I$(top_srcdir)/randr 
-I$(top_srcdir)/fb -I$(top_srcdir)/dbe
Makefile:PIXMAN_CFLAGS = -I/usr/include/pixman-1  
Makefile:XSERVERCFLAGS_CFLAGS = -D_BSD_SOURCE -DHAS_FCHOWN 
-DHAS_STICKY_DIR_BIT -I/usr/include/pixman-1 -I/usr/include/freetype2  
Makefile:XSERVERLIBS_CFLAGS = -I/usr/include/pixman-1 
-I/usr/include/freetype2  
Makefile:oldincludedir = /usr/include

mdl [119]# grep mingw/include *

I'm guessing from the above that it's this one:

/usr/include/GL/wglext.h

I replaced that one and the code in
/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/glx
now compiles.  Unfortunately, code now fails elsewhere:

cd /usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin
make

gives:
...
make[2]: Leaving directory 
`/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin/winclipboard'
Making all in .
make[2]: Entering directory 
`/usr/src/xorg-server-1.14.3-1/src/xserver-cygwin-1.14.3-1/hw/xwin'
  CC   InitInput.o
  CC   InitOutput.o
InitOutput.c: In function ‘ddxGiveUp’:
InitOutput.c:240:9: warning: ISO C90 forbids mixed declarations and code 
[-Wdeclaration-after-statement]
InitOutput.c: In function ‘winCheckMntOpt’:
InitOutput.c:284:16: warning: cast discards ‘__attribute__((const))’ qualifier 
from pointer target type [-Wcast-qual]
  CC   winallpriv.o
  CC   winauth.o
In file included from 
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winsock2.h:56:0,
 from /usr/include/X11/Xwinsock.h:55,
 from /usr/include/X11/Xpoll.h:163,
 from ../../os/osdep.h:85,
 from winauth.c:39:
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/psdk_inc/_fd_types.h:100:2:
 warning: #warning "fd_set and associated macros have been defined in 
sys/types.  This can cause runtime problems with W32 sockets" [-Wcpp]
In file included from /usr/include/X11/Xwinsock.h:55:0,
 from /usr/include/X11/Xpoll.h:163,
 from ../../os/osdep.h:85,
 from winauth.c:39:
/usr/lib/gcc/i686-pc-cygwin/4.7.3/../../../../include/w32api/winsock2.h:995:34: 
error: conflicting types for ‘select’
In file included from /usr/include/cygwin/sys_time.h:13:0,
 from /usr/include/sys/time.h:61,
 from /usr/include/sys/_default_fcntl.h:186,
 from /usr/include/sys/fcntl.h:3,
 from /usr/include/fcntl.h:14,
 from /usr/include/X11/Xos.h

Re: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

>  On 08/04/2010 04:47, Mark Lillibridge wrote:
>  >> Can you pull this patch and include it in the next X server release, 
> please.
>  >
>  >  Excellent.  Thank you.  Do we need to do anything special for this
>  > to get picked up for Xming as well?
>  
>  Assuming I don't receive too much hatemail about this breaking stuff after 
> the 
>  next X server release, I'll push it upstream to X.Org.

Thanks!  Any idea when the next X server release is?

- Mark

--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Jon wrote:
> Yaakov,
> 
> Can you pull this patch and include it in the next X server release, please.

Excellent.  Thank you.  Do we need to do anything special for this
to get picked up for Xming as well?

- Mark

--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

On February 23, 2010, Jon Turney wrote:
> On 13/02/2010 20:24, Mark Lillibridge wrote:
> > Jon wrote:
> >>   Thanks for the patch.  Have you actually tested that this resolves your 
> >> problem?
> >
> >  Yes.  Of course, really, really large bursts will still fail, but
> > they should be very rare.
> >
> 
> Perhaps you might try the attached patch, instead, and see if that helps.

Yes, your (previously) attached patch seems to solve the problem
without wasting memory or only working for a finite number of keys.
Nice job.  What's the next step towards getting this patch added to the
source/sent upstream/to Xming?

- Thanks,
  Mark

--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Jon wrote:
>  Thanks for the patch.  Have you actually tested that this resolves your 
> problem?

Yes.  Of course, really, really large bursts will still fail, but
they should be very rare.


>  I'll add some words about contributing patches to the CG guide 
> documentation, 
>  thanks for pointing out this oversight.
>  
>  Perhaps that's the reason we hardly ever get any :-)

You think?  :-)



>  On 23/01/2010 22:02, Mark Lillibridge wrote:
>  >  I am not a Windows programmer.  Can someone tell me if it's okay for
>  > winWindowProc to block?  In particular, could we make it block until the
>  > mieq queue is not full?
>  
>  I think blocking would just result in a deadlock, as the X server is only 
>  single-threaded.  The windows message pump is called when the server has no 
>  other work to do.
>  
>  This should be documented in [1], although perhaps that is lacking in detail.
>  
> I notice that winWakeHandler()/winBlockHandler() try to completely empty the 
> windows message queue, which leads to this problem as the server won't get a 
> chance to process anything (draining the mieq queue) until they return.
> 
> It might be enough to resolve this problem to allow those functions to 
> complete after processing a limited number of events (chosen so as to not 
> overflow the mieq queue), or if they notice that the event queue has crossed 
> some high-water mark threshold.

This is an interesting idea; I spent a while looking at
WaitFor.c/WaitForSomething, but it's pretty opaque -- couldn't figure
out when/under what conditions winWakeHandler is called by it.  E.g.,
what's the actual priority between emptying the queue and processing
window messages?

- Mark

--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Given there doesn't seem to be anyone competent enough to attempt a
more ambitious patch, I think we should apply the temporary patch.  How
should we/I. go about doing this?  The Cygwin X website and contributors
documentation doesn't actually say how to do this.

   The patch is enclosed at the end.

- Thanks,
  Mark


$ diff -u mieq.c~ mieq.c
--- mieq.c~ 2009-10-15 21:38:27.0 -0700
+++ mieq.c  2010-02-04 16:42:30.773405200 -0800
@@ -58,7 +58,7 @@
 # include 
 #endif
 
-#define QUEUE_SIZE  512
+#define QUEUE_SIZE  25000
 
 #define EnqueueScreen(dev) dev->spriteInfo->sprite->pEnqueueScreen
 #define DequeueScreen(dev) dev->spriteInfo->sprite->pDequeueScreen


--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

I've done a bit more investigating.

It appears that winWindowProc can block at the cost of preventing
processing of any Windows messages until it returns.  Does anyone know
how fast the mieq queue drains?  If this isn't very fast, then having
winWindowProc block waiting for the mieq queue is probably a bad idea.


There are a number of comments in mieq.c that may shed light on why
the queue is statically allocated:

mieq.c:76:
EventRec events[QUEUE_SIZE]; /* static allocation for signals */

mieq.c:138:
/*
 * Must be reentrant with ProcessInputEvents.  Assumption: mieqEnqueue
 * will never be interrupted.  If this is called from both signal
 * handlers and regular code, make sure the signal is suspended when
 * called from regular code.
 */

void
mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e)


Does anyone understand this?  Does this bar dynamically allocating the
queue?  The queue does not appear to use locking unless XQUARTZ is
defined.  Does anyone know what conditions that is defined under?

I'm beginning to think that simply patching the queue to be very large
is the best solution.

- Mark


--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Dennis wrote:
> Hi Mark.
> 
> I am a bit new to this list, but not THAT new to programming.  If you don't
> know how many keystrokes you need to have a buffer for, then you have 2
> choices:
> 
> 1.  Have a ridiculously huge buffer.
> 2.  Setup a dynamic array.
> 
> Using a 25000 character buffer seems like overkill.  But mieq.c is probably
> reading just from the Operating Systems' keyboard buffer.
> 
> You may need to write an input function to feed mieq.c and somehow link to
> it.  Sadly, that level of coding is beyond my abilities.

Option 1 would be a temporary patch.  Browsing through the source
code, keypresses/releases come one at a time in via window messages to
the following routine in hw/xwin/winwndproc.c:

/*
 * Called by winWakeupHandler
 * Processes current Windows message
 */

LRESULT CALLBACK
winWindowProc (HWND hwnd, UINT message, 
   WPARAM wParam, LPARAM lParam)
{
...


case WM_SYSKEYDOWN:
case WM_KEYDOWN:
  if (s_pScreenPriv == NULL || s_pScreenInfo->fIgnoreInput)
break;

  ...

  /* Translate Windows key code to X scan code */
  winTranslateKey (wParam, lParam, &iScanCode);

  /* Ignore repeats for CapsLock */
  if (wParam == VK_CAPITAL)
lParam = 1;

  /* Send the key event(s) */
  for (i = 0; i < LOWORD(lParam); ++i)
winSendKeyEvent (iScanCode, TRUE);
  return 0;


winSendKeyEvent in turn lives in hw/xwin/winkeybd.c:

/*
 * Take a raw X key code and send an up or down event for it.
 *
 * Thanks to VNC for inspiration, though it is a simple function.
 */

void
winSendKeyEvent (DWORD dwKey, Bool fDown)
{
  EventListPtr events;
  int i, nevents;

  /*
   * When alt-tabing between screens we can get phantom key up messages
   * Here we only pass them through it we think we should!
   */
  if (g_winKeyState[dwKey] == FALSE && fDown == FALSE) return;

  /* Update the keyState map */
  g_winKeyState[dwKey] = fDown;

  GetEventList(&events);
  nevents = GetKeyboardEvents(events, g_pwinKeyboard, fDown ? KeyPress : 
KeyRele
ase, dwKey + MIN_KEYCODE);

  for (i = 0; i < nevents; i++)
mieqEnqueue(g_pwinKeyboard, events[i].event);

#if CYGDEBUG
  ErrorF("winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n",
  dwKey, fDown, nevents);
#endif
}


Note the call to mieqEnqueue there.  


I am not a Windows programmer.  Can someone tell me if it's okay for
winWindowProc to block?  In particular, could we make it block until the
mieq queue is not full?

- Mark



--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

> Larry Hall wrote:
> On 01/19/2010 01:17 PM, Mark Lillibridge wrote:
> > 
> > Hi.
> > 
> >I don't appear to have gotten any response to my message sent to
> > this list January 12 (copied below).  Do I have the right list?  Am I
> > supposed to use a different mechanism to report bugs with the Cygwin X
> > server?  Please help.
> 
> Thanks for the information you've provided. This is the correct list for
> Cygwin X issues. I can't engage you on this topic because I'm not
> knowledgeable about the area you investigated. However, a couple of
> questions come to my mind about what you've found:
> 
>   1. Is this Cygwin-specific?

The Xming server, which I understand shares source code, also has
this bug.  The commercial X server, Reflection, does not have this bug.
This bug is specific to Windows implementations so I presume it does not
belong in the generic Xorg source.


>   2. If not, what's the upstream solution?
> 
> 
> This information might help you decide if your issue is better reported
> upstream.  It may also help developers here decide how to solve the
> problem.



--
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: bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Hi.

  I don't appear to have gotten any response to my message sent to
this list January 12 (copied below).  Do I have the right list?  Am I
supposed to use a different mechanism to report bugs with the Cygwin X
server?  Please help.

- Thanks,
  Mark

  
>  Background: 
>  
>  I use Nuance's Dragon NaturallySpeaking voice recognition software
>  to control remote Linux systems from a Windows box.  I open up xterms
>  and emacs windows on a local Cygwin X server.  Occasionally the voice
>  recognizer makes a mistake, which has to be corrected.  The mechanics of
>  how this is done are unimportant; what matters is how Dragon applies the
>  correction.  It does this by sending a large burst of keystrokes via
>  something like SendKeys.  (E.g., many (shift) arrow keys to select the
>  text to be changed, a backspace to delete it, then the replacement
>  text.)
>  
>  Unfortunately, there is a bug in the current released Cygwin X
>  server that causes it to drop sent keystrokes when the burst exceeds a
>  given size (roughly 64 or 128 keys depending on the version).  This
>  breaks correction, and forces painful manual fix up of the text.  Note
>  that what is really dropped are key events so the system can get into
>  the state where the shift key remains pressed or a key starts repeating
>  forever because the key up event was dropped.
>  
>  
>  Problem/temporary patch:
>  
>  I investigated and found that the problem appears to be that the X
>  event queue (miEventQueue) in hw/mi/mieq.c is statically allocated with
>  a ridiculously small value (512).  When keyboard bursts come in, this
>  queue overflows, causing the problem.  If I set this queue to a more
>  reasonable value of 5120:
>  
>  mieq.c:62:#define QUEUE_SIZE  5120/* was 512 */
>  
>  then 10 times larger key bursts can be accommodated without problem.
>  This value is probably still too small in practice so it would be safer
>  to go with a larger value like 25000.
>  
>  I characterize this as a temporary patch because ideally either the
>  queue would be made dynamic with no upper bound in size, or some kind of
>  flow control would be implemented so the code that receives Windows key
>  events does not overflow the event queue.
>  
>  
>  Reproducing the problem:
>  
>  Dragon NaturallySpeaking costs money, so I will instead describe how
>  to demonstrate the problem using AutoHotkey, which is a free download
>  from http://www.autohotkey.com/.  Download that program then create and
>  run the following script, burst.ahk:
>  
>    cut here for burst.ahk 
>  #space::
>  Send ** ** ** ** 
> **{enter}** ** ** ** 
> **{enter}** ** ** ** 
> **{enter}** ** ** ** 
> **{enter}** ** ** ** **{enter}
>  =
>  
>  Finally, type the Windows key and space together while focus is on an X
>  application.  The bug is not present, the following will be typed:
>  
>  ** ** ** ** **
>  ** ** ** ** **
>  ** ** ** ** **
>  ** ** ** ** **
>  ** ** ** ** **
>  
>  
>  On the other hand, if the bug is present you'll get something more like:
>  
>  ** ** ** ** **
>  ** ** ** ** **
>  *** 
>  
>  
>  - Mark
>  


--
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/

bug report/suggested temp. patch: handling bursts of sent keys

[Mark Lillibridge]

Background: 

I use Nuance's Dragon NaturallySpeaking voice recognition software
to control remote Linux systems from a Windows box.  I open up xterms
and emacs windows on a local Cygwin X server.  Occasionally the voice
recognizer makes a mistake, which has to be corrected.  The mechanics of
how this is done are unimportant; what matters is how Dragon applies the
correction.  It does this by sending a large burst of keystrokes via
something like SendKeys.  (E.g., many (shift) arrow keys to select the
text to be changed, a backspace to delete it, then the replacement
text.)

Unfortunately, there is a bug in the current released Cygwin X
server that causes it to drop sent keystrokes when the burst exceeds a
given size (roughly 64 or 128 keys depending on the version).  This
breaks correction, and forces painful manual fix up of the text.  Note
that what is really dropped are key events so the system can get into
the state where the shift key remains pressed or a key starts repeating
forever because the key up event was dropped.


Problem/temporary patch:

I investigated and found that the problem appears to be that the X
event queue (miEventQueue) in hw/mi/mieq.c is statically allocated with
a ridiculously small value (512).  When keyboard bursts come in, this
queue overflows, causing the problem.  If I set this queue to a more
reasonable value of 5120:

mieq.c:62:#define QUEUE_SIZE  5120/* was 512 */

then 10 times larger key bursts can be accommodated without problem.
This value is probably still too small in practice so it would be safer
to go with a larger value like 25000.

I characterize this as a temporary patch because ideally either the
queue would be made dynamic with no upper bound in size, or some kind of
flow control would be implemented so the code that receives Windows key
events does not overflow the event queue.


Reproducing the problem:

Dragon NaturallySpeaking costs money, so I will instead describe how
to demonstrate the problem using AutoHotkey, which is a free download
from http://www.autohotkey.com/.  Download that program then create and
run the following script, burst.ahk:

  cut here for burst.ahk 
#space::
Send ** ** ** ** 
**{enter}** ** ** ** 
**{enter}** ** ** ** 
**{enter}** ** ** ** 
**{enter}** ** ** ** **{enter}
=

Finally, type the Windows key and space together while focus is on an X
application.  The bug is not present, the following will be typed:

** ** ** ** **
** ** ** ** **
** ** ** ** **
** ** ** ** **
** ** ** ** **


On the other hand, if the bug is present you'll get something more like:

** ** ** ** **
** ** ** ** **
*** 


- Mark


--
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/