This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Chris: message queues and new windows (was select() details)


> -----Original Message-----
> From: Pierre A. Humblet [mailto:Pierre.Humblet@ieee.org]
> Sent: Wednesday, April 11, 2001 1:29 PM
> To: cygwin-xfree@cygwin.com; cygwin-xfree@cygwin.com
> Subject: Re: Possibly incorrect explanation of how WaitForSomething
> works (and how to fix it) [RC and CGF please comment]
> 
> 
> Chris,
> 
> I am currently trying to understand select().
> I see the following in the code:
> ****************
> peek_windows (select_record *me, int)
> {
>   MSG m;
>   HANDLE h;
>   set_handle_or_return_if_not_open (h, me);
> 
>   if (me->read_selected && me->read_ready)
>     return 1;
> 
>   if (PeekMessage (&m, (HWND) h, 0, 0, PM_NOREMOVE))
>     {
>       me->read_ready = TRUE;
>       select_printf ("window %d(%p) ready", me->fd, 
> me->fh->get_handle ());
>       return 1;
>     }
> ***************
> What is this used for?

That appears to be part of poll(), not select(). Check out
msdn.microsoft.com for doco on PeekMessage. (ie   

<http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/winui/m
essques_8085.htm>

The select() call uses WaitForMultipleObjects, which is the correct
method for getting woken up when input arrives. Someone needs to debug
(perhaps with an event queue watcher) what is happening with the X
server. 

strace is a wonderful tool - I recommend using it as well :].

I haven't read the code for the X Server, but as the X server creates
it's own window, keyboard and mouse messages for it will arrive in a
different message queue than the cygwin select() call looks at.

What needs to happen (as Harold as already noted) is that these messages
need to be processed rather than waiting for the cygwin select() to
return, which is only prompted by network traffic.

There are two basic ways to do this:
async - spawn a new thread, that waits on the window queue and prepares
to handle and process the events
sync - inform cygwin of the new message queue in some fashion, and have
select() wait on it as well.

Harold has already thought out most of the issues with the async
fashion. I suspect that syncronisation will be harder than expected, but
then I'm a pessimist. 

For the sync way, I dont' know of any standard way to tell cygwin that a
new message queue exists and should be treated as a keyboard/moure input
queue. 

Chris: a question for you

Is there some unix similar way that we could do that? I.E. a
/dev/keyboard and /dev/mouse that take a window identifier of some sort
in the open call. Or let it get set via fcntrl? That would allow the X
server to stay 100% unix coded - sitting on a single event loop. It
would also allow the X server to recieve Cygwin style signals properly,
which I suspect it may not if they enter via the wrong message queue...



Rob

> 
> The current problem is not to get mouse and keyboard input,
> there is already code for that. The problem is to wake up
> when some input happen, and not every 10 ms.
> 
> Pierre
> 
> At 10:11 PM 4/10/2001 -0400, Christopher Faylor wrote:
> >On Wed, Apr 11, 2001 at 09:23:19AM +1000, Robert Collins wrote:
> >>> -----Original Message-----
> >>> From: Christopher Faylor [mailto:cgf@redhat.com]
> >>> Sent: Wednesday, April 11, 2001 6:09 AM
> >>> To: Cygx (E-mail)
> >>> Subject: Re: Possibly incorrect explanation of how 
> WaitForSomething
> >>> works (and how to fix it) [RC and CGF please comment]
> >>> 
> >>> 
> >>> On Tue, Apr 10, 2001 at 08:09:48AM +1000, Robert Collins wrote:
> >>> >I thought cygwin had fd support for keyboard and mouse? If 
> >>> it doesn't,
> >>> >then my suggestion would be: write it.
> >>> 
> >>> It only supports the keyboard and the mouse in the context of 
> >>> the console.
> >>> I don't think that is appropriate for the X server.
> >>> 
> >>> cgf
> >>> 
> >>
> >>I'm just curious here: In Unix as I understand it, the X 
> server physical
> >>screen gets a pty? for access to the keyboard, and opens 
> /dev/mouse |
> >>/dev/cua0 | ... 
> >>
> >>What makes those things inappropriate for cygwin support? I'd have
> >>thought that a win32 message queue handler in a cygwin 
> linked app would
> >>be more trouble than cygwin handling the messages...
> >
> >I was saying that the current Cygwin support is only for 
> console devices:
> >
> >      if (!ReadConsoleInput (h, &input_rec, 1, &nread))
> >        {
> >          __seterrno ();
> >          syscall_printf ("ReadConsoleInput failed, %E");
> >          return -1;            /* seems to be failure */
> >        }
> >
> >This would not be appropriate for a non-console application like the
> >X server.
> >
> >If someone wants to add generic keyboard and mouse support 
> for a Windows
> >app, then that would be appropriate.
> >
> >cgf
> >
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]