Skip to content
  1. Oct 23, 2015
    • Carlos Garnacho's avatar
      wayland: Implement wl_pointer.axis_source/axis_stop/axis_frame emission · 74be2e9f
      Carlos Garnacho authored
      As per the spec. wl_pointer.axis_source determines the current source of
      scroll events, wl_pointer.axis_stop determines when there's no further
      scroll events on any axis (Which Clutter sends as dx/dy=0 events).
      wl_pointer.axis_frame marks the end of a series of axis_* events.
      
      v2: Updated to v4 of the protocol spec by
          Peter Hutterer <peter.hutterer@who-t.net>
      v3: Update to use Clutter API
      74be2e9f
  2. Oct 17, 2015
  3. Oct 16, 2015
  4. Oct 15, 2015
  5. Oct 13, 2015
  6. Oct 12, 2015
  7. Oct 07, 2015
  8. Oct 06, 2015
    • Rui Matos's avatar
      xprops: Fix reading Window and XSyncCounter properties · 54557f06
      Rui Matos authored
      Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8
      bytes wide. But the values on the wire are 32 bit so, for these types,
      we always copy 4 bytes into results->prop. As such copying them out
      with a cast such as *(Window *) means that we are actually reading 8
      bytes which depending on whether the higher addressed 4 bytes are zero
      means that sometimes this works while others it gives us a bogus
      value.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=756074
      54557f06
  9. Oct 04, 2015
  10. Oct 02, 2015
    • Carlos Garnacho's avatar
      wayland: Avoid resending new data offers on intra-client focus changes · b18542f2
      Carlos Garnacho authored
      Each keyboard focus change ends up calling the MetaWaylandDataDevice
      counterpart, we don't need though to notify the current selection
      again. In order to fix this, keep track of the current client, and
      only emit the relevant signals when the focus switches to another
      client.
      
      The situations where wl_data_device.selection were emitted during
      focus changes between surfaces of the same client was inocuous most
      of the times, although it's prone to inducing confusing behavior
      on context menu clipboard actions, as the closing menu triggers a
      focus change, which triggers a whole new wl_data_offer being created
      and given on wl_data_device.selection, at a time where there's already
      ongoing requests on the previous data offer.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=754357
      b18542f2
    • Carlos Garnacho's avatar
      xwayland: Protect against crash on x11->wayland transfer cancellation · da0aac66
      Carlos Garnacho authored
      If the transfer is cancelled, the X11SelectionData will be cleared from
      the MetaSelectionBridge, although x11_data_write_cb() was invariably
      expecting it to be non-NULL.
      
      If the write was cancelled, all the actions done in x11_data_write_cb()
      are moot, so just return early. If there's other errors happening
      (eg. "connection closed" if the target client happens to crash), we
      should still attempt at clearing the data anyway.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=754357
      da0aac66
  11. Sep 29, 2015
  12. Sep 28, 2015
  13. Sep 27, 2015
  14. Sep 25, 2015
  15. Sep 24, 2015