1. 10 Oct, 2013 2 commits
  2. 09 Oct, 2013 3 commits
  3. 08 Oct, 2013 1 commit
    • Tomeu Vizoso's avatar
      rpi: Add support for EGL buffers · b4659eb1
      Tomeu Vizoso authored
      The EGL implementation on the RPi allocates a front and a back
      DispmanX resources for each EGLSurface, which we composite along
      the others.
      b4659eb1
  4. 03 Oct, 2013 1 commit
  5. 02 Oct, 2013 3 commits
  6. 01 Oct, 2013 6 commits
  7. 30 Sep, 2013 1 commit
  8. 29 Sep, 2013 1 commit
  9. 26 Sep, 2013 4 commits
  10. 24 Sep, 2013 2 commits
    • Neil Roberts's avatar
      evdev: Process touch up events of single-touch devices · be336c89
      Neil Roberts authored
      Previously only the touch up key event was used for single-touch
      devices and the touch down event was generated on the first motion
      event. This was breaking if the touch up and down events were sent
      without a motion in-between because the evdev driver wouldn't generate
      a touch down event and Weston would lose track of the number of touch
      points that are down. This patch changes it to track the up and down
      key events as pending events similar to how it does for multi-touch
      devices.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=69759
      be336c89
    • 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
  11. 23 Sep, 2013 5 commits
  12. 22 Sep, 2013 11 commits