nanogui: Thread: Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up

I have set HAVEBLIT = 0 in vgaplan4.h and got a little further.
I've got anohter assert though:
 assert ( "drivers/vgaplan4.c", line=173, 
           msg=0x129403 "y2 >= 0 && y2 < psd->yres")

See gdb call stack.

Thanks, Rosimildo.
-----------------------------------------------------
(gdb) backtrace
#0  _IBMPC_scankey (outChar=0x2b7797 "")
    at 
../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
sole/inch.c:122
#1  0x115dcd in BSP_wait_polled_input ()
    at 
../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
sole/inch.c:298
#2  0x10f4a3 in __assert (file=0x129366 "drivers/vgaplan4.c", line=173,
    msg=0x129403 "y2 >= 0 && y2 < psd->yres") at rtems/console.c:177
#3  0x10dd2a in ega_drawvertline (psd=0x14a9e0, x=250, y1=236, y2=480, c=7)
    at drivers/vgaplan4.c:173
#4  0x10d8d7 in VGA_drawvline (psd=0x14a9e0, x=250, y1=236, y2=479, c=7)
    at drivers/scr_bios.c:240
#5  0x10b5fd in drawcol (psd=0x14a9e0, x=250, y1=236, y2=553) at devdraw.c:546
#6  0x109646 in GdLine (psd=0x14a9e0, x1=250, y1=553, x2=250, y2=553,
    bDrawLastPoint=0) at devdraw.c:406
#7  0x1018d4 in LineTo (hdc=0x1ffcd80, x=250, y=235) at wingdi.c:306
#8  0x10674e in Draw3dBox (hDC=0x1ffcd80, x=250, y=235, w=320, h=320,
    crTop=12307669, crBottom=0) at draw3d.c:60
#9  0x104066 in DefWindowProc (hwnd=0x1ffe6b8, msg=133, wParam=0, lParam=0)
    at windefw.c:103
#10 0x1063bf in WndProc (hwnd=0x1ffe6b8, msg=133, wp=0, lp=0)
    at demos/microwin/demo.c:266
#11 0x100f03 in SendMessage (hwnd=0x1ffe6b8, Msg=133, wParam=0, lParam=0)
---Type <return> to continue, or q <return> to quit---


Rosimildo daSilva wrote:
 > 
 > Version: 0.87pre2
 > 
 > I am debuging the RTEMS porting, and get this assert()
 > after moving the mouse little bit. I am wondering if 
 > this is a bug in the Video driver or in the mouse
 > driver. Any points are appreciated.
 > 
 > Rosimildo.
 > 
 > --------------------------------------------------------------------
 > (gdb) backtrace
 > #0  0x116c6d in BSP_wait_polled_input ()
 >     at 
 > ../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
 > sole/inch.c:298
 > #1  0x110343 in __assert (file=0x12a40a "drivers/mempl4.c", line=237,
 >     msg=0x12a561 "w > 0") at rtems/console.c:177
 > #2  0x10ec82 in mempl4_to_vga_blit (dstpsd=0x14bac0, dstx=420, dsty=100,
 >     w=-43, h=277, srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0)
 >     at drivers/mempl4.c:237
 > #3  0x10df16 in ega_blit (dstpsd=0x14bac0, dstx=420, dsty=100, w=-43, 
 > h=277,
 >     srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0) at drivers/vgaplan4.c:211
 > #4  0x10b4ca in GdBlit (dstpsd=0x14bac0, dstx=63, dsty=76, width=314,
 >     height=301, srcpsd=0x1ffcd3c, srcx=0, srcy=0, rop=0) at devdraw.c:1458
 > #5  0x10216b in BitBlt (hdcDest=0x1ffcdb0, nXDest=0, nYDest=0, nWidth=314,
 >     nHeight=301, hdcSrc=0x1ffccfc, nXSrc=0, nYSrc=0, dwRop=13369376)
 >     at wingdi.c:898
 > #6  0x108db8 in paint3 (hDC=0x1ffcdb0) at graph3d.c:66
 > #7  0x106338 in WndProc (hwnd=0x1ffda54, msg=15, wp=0, lp=0)
 >     at demos/microwin/demo.c:237
 > #8  0x101073 in DispatchMessage (lpMsg=0x2b8d58) at winuser.c:27
 > #9  0x1064c6 in WinMain (hInstance=0x0, hPrevInstance=0x0, lpCmdLine=0x0,
 >     nShowCmd=5) at demos/microwin/demo.c:299
 > #10 0x1004e1 in rtems_main (ac=5, av=0x14c7d8) at winmain.c:49
 > #11 0x10e277 in POSIX_Init (argument=0x0) at rtems/rtems_init.c:80
 > ---Type <return> to continue, or q <return> to quit---
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > ______________________________________________________
 > Get your free web-based email at http://www.xoom.com
 > Birthday? Anniversary? Send FREE animated greeting
 > cards for any occasion at http://greetings.xoom.com
 > 
 > 
 > 
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: ####@####.####
 > For additional commands, e-mail: ####@####.####
 > 
 > 


Thanks,
Rosimildo

______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: I have set HAVEBLIT = 0 in vgaplan4.h and got a little further.

Fine for now, but I think you should add the negative blit fix and
see what happens.

: I've got anohter assert though:
:  assert ( "drivers/vgaplan4.c", line=173,
:            msg=0x129403 "y2 >= 0 && y2 < psd->yres")

This is because VGA_drawvertline took y2=479 and incremented
it, and called ega_drawvertline, which never draws the last point,
so, the assert is actually wrong.  Change it to:

    assert(y2>= 0 && y2 <= psd->yres);

Also fix the similar assert on ega_drawhorzline on line 121:

    assert(x2>= 0 && x2 <= psd->xres);

Regards,

Greg

:
: See gdb call stack.
:
: Thanks, Rosimildo.
: -----------------------------------------------------
: (gdb) backtrace
: #0  _IBMPC_scankey (outChar=0x2b7797 "")
:     at
: ../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
: sole/inch.c:122
: #1  0x115dcd in BSP_wait_polled_input ()
:     at
: ../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
: sole/inch.c:298
: #2  0x10f4a3 in __assert (file=0x129366 "drivers/vgaplan4.c", line=173,
:     msg=0x129403 "y2 >= 0 && y2 < psd->yres") at rtems/console.c:177
: #3  0x10dd2a in ega_drawvertline (psd=0x14a9e0, x=250, y1=236, y2=480, c=7)
:     at drivers/vgaplan4.c:173
: #4  0x10d8d7 in VGA_drawvline (psd=0x14a9e0, x=250, y1=236, y2=479, c=7)
:     at drivers/scr_bios.c:240
: #5  0x10b5fd in drawcol (psd=0x14a9e0, x=250, y1=236, y2=553) at devdraw.c:546
: #6  0x109646 in GdLine (psd=0x14a9e0, x1=250, y1=553, x2=250, y2=553,
:     bDrawLastPoint=0) at devdraw.c:406
: #7  0x1018d4 in LineTo (hdc=0x1ffcd80, x=250, y=235) at wingdi.c:306
: #8  0x10674e in Draw3dBox (hDC=0x1ffcd80, x=250, y=235, w=320, h=320,
:     crTop=12307669, crBottom=0) at draw3d.c:60
: #9  0x104066 in DefWindowProc (hwnd=0x1ffe6b8, msg=133, wParam=0, lParam=0)
:     at windefw.c:103
: #10 0x1063bf in WndProc (hwnd=0x1ffe6b8, msg=133, wp=0, lp=0)
:     at demos/microwin/demo.c:266
: #11 0x100f03 in SendMessage (hwnd=0x1ffe6b8, Msg=133, wParam=0, lParam=0)
: ---Type <return> to continue, or q <return> to quit---
:
:
: Rosimildo daSilva wrote:
:  >
:  > Version: 0.87pre2
:  >
:  > I am debuging the RTEMS porting, and get this assert()
:  > after moving the mouse little bit. I am wondering if
:  > this is a bug in the Video driver or in the mouse
:  > driver. Any points are appreciated.
:  >
:  > Rosimildo.
:  >
:  > --------------------------------------------------------------------
:  > (gdb) backtrace
:  > #0  0x116c6d in BSP_wait_polled_input ()
:  >     at
:  > ../../../../../../../../../rtems-19991117/c/src/lib/libbsp/i386/pc386/con
:  > sole/inch.c:298
:  > #1  0x110343 in __assert (file=0x12a40a "drivers/mempl4.c", line=237,
:  >     msg=0x12a561 "w > 0") at rtems/console.c:177
:  > #2  0x10ec82 in mempl4_to_vga_blit (dstpsd=0x14bac0, dstx=420, dsty=100,
:  >     w=-43, h=277, srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0)
:  >     at drivers/mempl4.c:237
:  > #3  0x10df16 in ega_blit (dstpsd=0x14bac0, dstx=420, dsty=100, w=-43,
:  > h=277,
:  >     srcpsd=0x1ffcd3c, srcx=357, srcy=24, op=0) at drivers/vgaplan4.c:211
:  > #4  0x10b4ca in GdBlit (dstpsd=0x14bac0, dstx=63, dsty=76, width=314,
:  >     height=301, srcpsd=0x1ffcd3c, srcx=0, srcy=0, rop=0) at devdraw.c:1458
:  > #5  0x10216b in BitBlt (hdcDest=0x1ffcdb0, nXDest=0, nYDest=0, nWidth=314,
:  >     nHeight=301, hdcSrc=0x1ffccfc, nXSrc=0, nYSrc=0, dwRop=13369376)
:  >     at wingdi.c:898
:  > #6  0x108db8 in paint3 (hDC=0x1ffcdb0) at graph3d.c:66
:  > #7  0x106338 in WndProc (hwnd=0x1ffda54, msg=15, wp=0, lp=0)
:  >     at demos/microwin/demo.c:237
:  > #8  0x101073 in DispatchMessage (lpMsg=0x2b8d58) at winuser.c:27
:  > #9  0x1064c6 in WinMain (hInstance=0x0, hPrevInstance=0x0, lpCmdLine=0x0,
:  >     nShowCmd=5) at demos/microwin/demo.c:299
:  > #10 0x1004e1 in rtems_main (ac=5, av=0x14c7d8) at winmain.c:49
:  > #11 0x10e277 in POSIX_Init (argument=0x0) at rtems/rtems_init.c:80
:  > ---Type <return> to continue, or q <return> to quit---
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  >
:  > ______________________________________________________
:  > Get your free web-based email at http://www.xoom.com
:  > Birthday? Anniversary? Send FREE animated greeting
:  > cards for any occasion at http://greetings.xoom.com
:  >
:  >
:  >
:  > ---------------------------------------------------------------------
:  > To unsubscribe, e-mail: ####@####.####
:  > For additional commands, e-mail: ####@####.####
:  >
:  >
:
:
: Thanks,
: Rosimildo
:
: ______________________________________________________
: Get your free web-based email at http://www.xoom.com
: Birthday? Anniversary? Send FREE animated greeting
: cards for any occasion at http://greetings.xoom.com
:
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
:

"Greg Haerr" wrote:
 > 
 > : I have set HAVEBLIT = 0 in vgaplan4.h and got a little further.
 > 
 > Fine for now, but I think you should add the negative blit fix and
 > see what happens.

Applying your new routine seems to have fixed the problem.


I still have two problems with the RTEMS porting, though:

  + I am running the MicroWindows Demo, and when the cursor
is  over one active window, if I click on the "left button"
of the mouse, the position of the mouse jumps to another
location. It does this everytime. I am not moving the mouse.
I am wondering if anybody has a tip on how to debug this or
it is a known problem.

  + the moviment of the mouse is not easy when the top most
windows od the Microwindows demo is active( has focus ).

I am using the mou_ser.c driver. Mouse type = "ms".

Rosimildo.







______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: Applying your new routine seems to have fixed the problem.
: 
Good.  So the fixes you have applied are:  HAVEBLIT=1,
new GdBlit, two assert fixes in vgaplan4.c.  right?


: 
: I still have two problems with the RTEMS porting, though:
: 
:   + I am running the MicroWindows Demo, and when the cursor
: is  over one active window, if I click on the "left button"
: of the mouse, the position of the mouse jumps to another
: location. It does this everytime. I am not moving the mouse.
: I am wondering if anybody has a tip on how to debug this or
: it is a known problem.

It's definitely a mouse driver issue.  That's what the test
program is for, it prints the mouse status.  It sounds
like the return value is bad when the button is pressed.
Perhaps you're decoding the wrong mouse stream.
Make sure that you always return 1 (relative), not
2 (abs) coordinates.  

The test program prints mouse status values to stderr,
while using the std mouse driver.  You can visually inspect
that it's all working ok.


: 
:   + the moviment of the mouse is not easy when the top most
: windows od the Microwindows demo is active( has focus ).

Remember
that the 3d demo recalcs on mouse movement.  So if you're
floating point or cpu is slow, then the serial mouse
interrupt will track and record all the mouse movement
while the 3d demo is drawing.  
If you close the 3d demo window, this problem should
go away.  Otherwise I suspect a mouse driver issue as well.

: 
: I am using the mou_ser.c driver. Mouse type = "ms".

Strange.  Did your other mouse driver work better?


Greg

Greg Haerr wrote:
 > : Applying your new routine seems to have fixed the problem.
 > : 
 > Good.  So the fixes you have applied are:  HAVEBLIT=1,
 > new GdBlit, two assert fixes in vgaplan4.c.  right?


Yes. The video looks good.


 > 
 > It's definitely a mouse driver issue.  That's what the test
 > program is for, it prints the mouse status.  It sounds
 > like the return value is bad when the button is pressed.
 > Perhaps you're decoding the wrong mouse stream.
 > Make sure that you always return 1 (relative), not
 > 2 (abs) coordinates.  
 > 
 > The test program prints mouse status values to stderr,
 > while using the std mouse driver.  You can visually inspect
 > that it's all working ok.
 > 

With the test driver it looks good.

   | 
  -+--------> X
   |
   |
   | 
   V Y

It returns 1 all the time.


Left button == 0x04
Right button == 0x01
Both buttons == 0x05

So, it looks good when running the test driver.

This CPU is Cyrix 586. Yes, floating point sucks on it.


 > 
 > : 
 > :   + the moviment of the mouse is not easy when the top most
 > : windows od the Microwindows demo is active( has focus ).
 > 
 > Remember
 > that the 3d demo recalcs on mouse movement.  So if you're
 > floating point or cpu is slow, then the serial mouse
 > interrupt will track and record all the mouse movement
 > while the 3d demo is drawing.  
 > If you close the 3d demo window, this problem should
 > go away.  Otherwise I suspect a mouse driver issue as well.
 > 
 > : 
 > : I am using the mou_ser.c driver. Mouse type = "ms".
 > 
 > Strange.  Did your other mouse driver work better?
 > 


I do not remember. It was crashing so often that I did
not noticed. The mouse driver looks fine with the 
test driver.

Rosimildo.





______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: Left button == 0x04
: Right button == 0x01
: Both buttons == 0x05
: 
: So, it looks good when running the test driver.
: 

Perhaps it's your GsSelect code that calls GsCheckMouse
and GsCheckKbd even when timeout returned.  And
then the mouse driver is called twice, and returns
data twice?

If that's not it, go into the GsCheckMouse code and 
trace through the code leading up to the WM_LBUTTONDOWN
that is being created.  It's values should be the same as
any previous or post WM_MOUSEMOVE messages,
since they are generated in addition to the GdMoveCursor,
which actually moves the cursor on the screen.

Finally, you might want to make sure that the same code you're
running runs OK on a normal Linux box, just in case.

Regards,

Greg

"Greg Haerr" wrote:
 > : Left button == 0x04
 > : Right button == 0x01
 > : Both buttons == 0x05
 > : 
 > : So, it looks good when running the test driver.
 > : 
 > 
 > Perhaps it's your GsSelect code that calls GsCheckMouse
 > and GsCheckKbd even when timeout returned.  And
 > then the mouse driver is called twice, and returns
 > data twice?
 > 
 > If that's not it, go into the GsCheckMouse code and 
 > trace through the code leading up to the WM_LBUTTONDOWN
 > that is being created.  It's values should be the same as
 > any previous or post WM_MOUSEMOVE messages,
 > since they are generated in addition to the GdMoveCursor,
 > which actually moves the cursor on the screen.

I have finally understood this a bit. The termios buffer
for the mouse driver, mou_ser.c is getting full, and some
bytes of the mouse stream are lost. It takes a little a while
to recover. During this period waird things happen.
This happens more often with the 3d demo because my test machine 
does NOT perform well with floating point ( cyrix 586 ).

One solution that worked for me was to change the signatures
of GsCheckMouseEvent & GsCheckKeyboardEvent to return a
boolean indicating whether or not an event was posted. I use
this information to keep "pumping" mouse events as long as
there is one.


/* RTEMS select became ... */
void GsSelect(void)
{
   static int mouse_had_data = FALSE;
   static int kbd_had_data   = FALSE;
   rtems_event_set o;
   rtems_status_code rc;
   rtems_interval timeout;
   rtems_option options;

  /* perform pre-select duties, if any*/
  if( scrdev.PreSelect )
  {
     scrdev.PreSelect( &scrdev );
  }
  /* As long as we have data in the Mouse or KBD buffers
   * let's handle it.
   */
  if( mouse_had_data )
  {
     mouse_had_data = GsCheckMouseEvent();
  }
  if( kbd_had_data )
  {
    kbd_had_data = GsCheckKeyboardEvent();   
  }
  if( mouse_had_data || kbd_had_data )
     return;

  /* Let's wait until next eveen becomes available */
  options = RTEMS_WAIT | RTEMS_EVENT_ANY;
  timeout = 100;  /* in ticks  ~ 1 sec */
  o = 0;
  rc = rtems_event_receive( RTEMS_KBD_EVENT | RTEMS_MOUSE_EVENT, 
                            options, timeout, &o );
  if( ( rc == RTEMS_TIMEOUT ) || ( rc == RTEMS_UNSATISFIED ) )
  {
     return;
  }
  /* If mouse data present, service it*/
  if( o & RTEMS_MOUSE_EVENT )
  {    
     mouse_had_data = GsCheckMouseEvent();
  }

  /* If keyboard data present, service it*/
  if( o & RTEMS_KBD_EVENT )

______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

: One solution that worked for me was to change the signatures
: of GsCheckMouseEvent & GsCheckKeyboardEvent to return a
: boolean indicating whether or not an event was posted. I use
: this information to keep "pumping" mouse events as long as
: there is one.

Well, it's probably OK to have the signatures tell us something
we can't know now, but a better solution would be to increase
the size of the serial interrupt or clist buffers.

Also, there are subtle issues involved with pumping events
without returning from GsSelect.  But also you might just
loop while rtems_event_receive says there's events.

I still prefer the increased serial input buffer size, to be safe.

Greg

"Greg Haerr" wrote:
 > : One solution that worked for me was to change the signatures
 > : of GsCheckMouseEvent & GsCheckKeyboardEvent to return a
 > : boolean indicating whether or not an event was posted. I use
 > : this information to keep "pumping" mouse events as long as
 > : there is one.
 > 
 > Well, it's probably OK to have the signatures tell us something
 > we can't know now, but a better solution would be to increase
 > the size of the serial interrupt or clist buffers.

Increasing the buffer is a solution. But, how big ?
It would depend on the speed that the user move the
mouse, how busy the system is, etc.

Also, on RTEMS, and how it stands today, we need to recompile
the system to increase the buffer of the termios routines.

 > 
 > Also, there are subtle issues involved with pumping events
 > without returning from GsSelect.  But also you might just
 > loop while rtems_event_receive says there's events.

We do not pump events without leaving GsSelect(). For each
event, a return of this routine is executed.

Let me explain the semantic of rtems_event_receive works.
It does not "count" events. It is a binary thing.
If you have 30 bytes in the queue of the mouse
driver, and if you are notified of a "mouse event",
you must read everyting in there, or the system
would block next time until at least one more byte 
be inserted in the queue and a new event be posted.

As discussed previously, RTEMS does not have a select()
function at this point, and I am trying to avoid to
create a thread that waits for events on kbd and another 
one for the mouse events, once
Microwindows is not thread safe at this point.

I still strugling for a solution that is reliable,
and at the same time, easy to implement from the
RTEMS and Microwindows stand point.

Sorry, if I am causing problems for the MicroWindows
community. I am trying to balance the needs of the
RTEMS port, and the current Microwindows base code.

Rosimildo.



______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com

"Greg Haerr" wrote:
 > Rosimildo - some other ideas:
 > 

This solution works for me. Thanks for your
support. I'll stick with this solution.

--------------------------------------------
void GsSelect(void)
{
   rtems_event_set o;
   rtems_status_code rc;
   rtems_interval timeout;
   rtems_option options;

   /* perform pre-select duties, if any*/
   if( scrdev.PreSelect )
   {
  scrdev.PreSelect( &scrdev );
   }

   options = RTEMS_WAIT | RTEMS_EVENT_ANY;
   // Hack: This is a second in ticks. We should get the proper
   // method to make this more generic.
   timeout = 100; /* in ticks ~ 1 sc */

   o = 0;
   rc = rtems_event_receive( RTEMS_KBD_EVENT | RTEMS_MOUSE_EVENT, 
                             options, timeout, &o );
   if( ( rc == RTEMS_TIMEOUT ) || ( rc == RTEMS_UNSATISFIED ) )
   {
      return;
   }

   /* If mouse data present, service it*/
   if( o & RTEMS_MOUSE_EVENT )
   {
     int mouse_had_data;
      do 
      {
         mouse_had_data = GsCheckMouseEvent();
      } while( mouse_had_data );
   }
   /* If keyboard data present, service it*/
   if( o & RTEMS_KBD_EVENT )
   {
      int kbd_had_data;
      do 
      {
         kbd_had_data = GsCheckKeyboardEvent();
      } while( kbd_had_data );
   }
}

 > 
 > : /* RTEMS select became ... */
 > : void GsSelect(void)
 > : {
 > :    static int mouse_had_data = FALSE;
 > :    static int kbd_had_data   = FALSE;
 > :    rtems_event_set o;
 > :    rtems_status_code rc;
 > :    rtems_interval timeout;
 > :    rtems_option options;
 > : 
 > :   /* perform pre-select duties, if any*/
 > :   if( scrdev.PreSelect )
 > :   {
 > :      scrdev.PreSelect( &scrdev );
 > :   }
 > : 
 > #if 0
 >   /* As long as we have data in the Mouse or KBD buffers
 > :    * let's handle it.
 > :    */
 > :   if( mouse_had_data )
 > :   {
 > :      mouse_had_data = GsCheckMouseEvent();
 > :   }
 > :   if( kbd_had_data )
 > :   {
 > :     kbd_had_data = GsCheckKeyboardEvent();   
 > :   }
 > :   if( mouse_had_data || kbd_had_data )
 > :      return;
 > #endif
 >  
 > :   /* Let's wait until next eveen becomes available */
 > :   options = RTEMS_WAIT | RTEMS_EVENT_ANY;
 > :   timeout = 100;  /* in ticks  ~ 1 sec */
 > :   o = 0;
 > :   rc = rtems_event_receive( RTEMS_KBD_EVENT | RTEMS_MOUSE_EVENT, 
 > :                             options, timeout, &o );
 > :   if( ( rc == RTEMS_TIMEOUT ) || ( rc == RTEMS_UNSATISFIED ) )
 > :   {
 > :      return;
 > :   }
 > :   /* If mouse data present, service it*/
 > :   if( o & RTEMS_MOUSE_EVENT )
 > :   {    
 > :      mouse_had_data = GsCheckMouseEvent();
 > 
 > how about here:
 >     do {
 >         mouse_had_data = GsCheckMouseEvent();
 >    while(mouse_had_data);
 > 
 > 
 > :   }
 > : 
 > :   /* If keyboard data present, service it*/
 > :   if( o & RTEMS_KBD_EVENT )
 > : 
 > : ______________________________________________________
 > : Get your free web-based email at http://www.xoom.com
 > : Birthday? Anniversary? Send FREE animated greeting
 > : cards for any occasion at http://greetings.xoom.com
 > : 
 > : 
 > : 
 > : ---------------------------------------------------------------------
 > : To unsubscribe, e-mail: ####@####.####
 > : For additional commands, e-mail: ####@####.####
 > : 
 > : 
 > 
 > 


______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com