This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Chris: message queues and new windows (was select() details)
- To: "Robert Collins" <robert dot collins at itdomain dot com dot au>, <cygwin-xfree at cygwin dot com>
- Subject: Re: Chris: message queues and new windows (was select() details)
- From: "Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>
- Date: Wed, 11 Apr 2001 00:32:08 -0400
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
>> >
>>
>