Hi, On Wed, Jan 13, 2010 at 11:35:42AM +1000, Peter Hutterer wrote: > On Wed, Jan 13, 2010 at 02:29:46AM +1100, Daniel Stone wrote: > > On Mon, Jan 11, 2010 at 04:13:25PM +1000, Peter Hutterer wrote: > > > > > > Not quite. RECORD differs between "device events" and "delivered events". > > > The former include all events regardless of whether they are delivered so > > > the process here is correct. The naming in the code is somewhat > > > unfortunate, > > > it's "device events" and "events" when they are really "all events" and > > > "delivered events". > > > > > > Record requires that _any_ event is delivered, hence the hook in > > > WriteEventsToClient which is called for all events including randr, XI, > > > etc. > > > > > > It looks like Chris' original patch was correct anyway once the > > > EventToCore > > > patch is applied. I'm still waiting for more test feedback. > > > > Yeah, just checked the spec and you're right. Aside from the two > > ErrorFs left in there, it seems like it behaves incorrectly for events > > queued while a device is grabbed. From my reading of the spec, it looks > > like a device event should be generated from EnqueueEvent, but not from > > ProcessOtherEvent when the device is thawed; delivered events should > > still be sent though. > > I don't think the recording should be stopped. Reading from section 2.1.4, > it says "the recording of selected device events is not affected by server > grabs" (where in this context "server grab" means pointer/keyboard grabs, > not GrabServer grabs)
I don't think the recording should be _stopped_, but right now there would appear to be two device events generated, and one delivered. > The ambiguous bit is "if a recording client selects both a device event and > delivered events that result from that device event, the delivered event are > recorded after the device events. In the absence of grabs, the delivered > events for a device event precede later device events." > > I read the second sentence as the order of events for ungrabbed devices will > be "device delivered device delivered device delivered ...". > For a grab, the order may be "device device device delivered" or something > similar. The "later" is the key here, the delivered event for an event > precedes a device event for an event occuring _after_ the first event. > > Checking with the server 1.3 sources that predate the input rework we > recorded device events from CoreProcessKeyboardEvent and > CoreProcessPointerEvent as well as ProcessOtherEvents. The first two are > gone now, so recording in POE seems correct - at least to maintain the same > behaviour. Sure, all of this seems correct, but aren't we going to send _two_ device events (one from EnqueueEvent, one from ProcessOtherEvents when it's subsequently thawed) as well as the one delivered event? Cheers, Daniel
pgpJAbJzDXzT5.pgp
Description: PGP signature
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
