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

[Peter Hutterer]

On Wed, Jan 13, 2010 at 03:54:32PM +1100, Daniel Stone wrote:
> 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?

Oh, now I get it. yes, you're right and I wonder if that ever worked for
extension devices. Server 1.3 had a guard for syncEvents.playingEvents to
avoid this situation - but only for core events. POE lacked this check, so
we must have recorded events twice.

Cheers,
  Peter