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


Previous by date: 23 Dec 1999 18:22:27 -0000 Re: blitting with more than 8bpp, Greg Haerr
Next by date: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Rosimildo daSilva
Previous in thread: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Greg Haerr
Next in thread: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Rosimildo daSilva

Subject: Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up
From: Rosimildo daSilva ####@####.####
Date: 23 Dec 1999 18:22:27 -0000
Message-Id: <199912231816.KAA07948@www2.xoommail.com>

"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



Previous by date: 23 Dec 1999 18:22:27 -0000 Re: blitting with more than 8bpp, Greg Haerr
Next by date: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Rosimildo daSilva
Previous in thread: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Greg Haerr
Next in thread: 23 Dec 1999 18:22:27 -0000 Re: Help --- assert( drivers/mempl4.c, line=237 ) --- follow up, Rosimildo daSilva


Powered by ezmlm-browse 0.20.