Skip to content
  • Neil Roberts's avatar
    evdev: Only track one pending event · daf7d477
    Neil Roberts authored
    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
    daf7d477