[PATCH] Re-enable the RECORD extension. (#20500)

[Daniel Stone]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20100113/0b0f1aac/attachment.pgp