Bill Studenmund wrote:

> On Tue, 25 Jun 2002, Gregory McGarry wrote:
> 
> > Julio Merino wrote:
> >
> > > > The only problem I can see is that you're reading the dynamic state
> > > > from the kernel.  Once you return to userland, there is no guarantee
> > > > that the returned value is correct any more.  You can tell if an
> > > > event occurred, but not infer any precise kernel state.
> > >
> > > Well, in fact this does not matter from the point of view of the mouse
> > > daemon. All I need to know is when events happen...
> > >
> > > Though I think that event's data is quite trustable. Can you explain
> > > why it may be wrong?
> >
> > Your example code said this:
> >
> >                 if (poll(pfd, 1, INFTIM) <= 0)
> >                         warn("failed");
> >                 read(fd, &evt, sizeof(evt));
> >                 /* XXX */
> >                 if (evt.type == WSCONS_EVENT_DISPLAY_SWITCH)
> >                         printf("New display: %d\n", evt.value);
> >
> > Which isn't necessarily true.  If the display is changed at /* XXX */
> > then evt will hold stale information and the printf() statement is
> > incorrect.
> 
> I've only been skimming this thread (and also haven't seen the rest of the
> kernel code), but it strikes me that you're splitting a hair. *No*
> userland daemon can have a 100% accurate view of the kernel state, as
> messages have to cross the kernel-userland barrier. I mean the same thing
> can be said of routing daemons & such.
> 
> I mean is it really stale? There was a display switch that moved the
> screen to screen evt.value. The fact that there was another change just
> after it doesn't invalidate that event notice. :-)

Sure.  I'm still not sure how the event is to be used with the mouse
daemon.

	-- Gregory McGarry <g.mcgarry@ieee.org>