Find a file
Neil Roberts 96ec0936ca evdev: Only track one pending event
Instead of having a mask of pending events there is now an enum with a
single value to represent the one pending event. The event gets
flushed explicitly as part of the handling code for each event type
rather than in the outer event reading loop. The pending event is used
so that we can combine multiple motion events into one and to make
sure that we have recieved the latest position before sending a touch
up or down event. This should fix the following problems with the old
approach:

• If you release a finger and press it down again quickly you could
  get the up and down events in the same batch. However the pending
  events were always processed in the order down then up so it would
  end up notifying two down events and then an up. The pending event
  is now always flushed when there is a new up or down event so they
  will always be in the right order.

• When it got a slot event it would immediately change the slot number
  and then set the pending event. Then when it flushed the events it
  would use the new slot number to flush the old pending event so the
  events could have the wrong finger. The pending event is now
  immediately flushed when a slot event is received so it will have
  the right finger.

• If you get more than 32 events in one read then it was resetting the
  pending events before processing the next batch in
  evdev_process_events. If four fingers were pressed down at once then
  it ended up with more than 32 events and the sync message would be
  in the second batch. The pending flag for the last finger was
  getting cleared so it never got emitted. In this patch the pending
  event is no longer reset after reading nor is it explicitly flushed.
  Instead it is flushed when we receive a EV_SYN event or a different
  pending event needs to replace it.

The touchpad handling code was trying to use the pending event
mechanism to notify the relative motion events. I'm not sure why it
was doing this because it looks the event would effectively get
emitted as soon as the touchpad_process function is finished anyway
and it wasn't accumulating the values. Instead I've just changed it to
emit the event directly.

https://bugs.freedesktop.org/show_bug.cgi?id=67563
2013-11-10 17:51:33 +01:00
src evdev: Only track one pending event 2013-11-10 17:51:33 +01:00