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]

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


Rob,

It is on line 1411 of select.cc
I know what PeekMessage() does.
I am trying to figure out when/why select() calls
PeekMessage(), with the idea of possibly using
this feature in the XServer code.
In particular, is there a reason to use PeekMessage()
and not GetQueueStatus()?

Pierre

Pierre

At 02:03 PM 4/11/2001 +1000, Robert Collins wrote:
>> -----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]