1. 22 Jul, 2018 1 commit
  2. 07 Feb, 2018 3 commits
  3. 27 Nov, 2017 3 commits
  4. 17 Jan, 2017 3 commits
  5. 14 Aug, 2016 1 commit
  6. 26 Jul, 2016 1 commit
  7. 30 Jun, 2016 1 commit
  8. 23 Jun, 2016 1 commit
  9. 13 Jun, 2016 1 commit
  10. 03 Jun, 2016 1 commit
  11. 01 Jun, 2016 1 commit
    • Pekka Paalanen's avatar
      ivi-shell: add API for weston_surface -> ivi_layout_surface · eaa43fc3
      Pekka Paalanen authored
      
      
      Add ivi-layout API for getting an ivi_layout_surface from a
      weston_surface if it exists. This can be used by controllers that hook
      up to core Weston callbacks and get handed a weston_surface, but need to
      use ivi-layout API to manipulate it.
      
      The only ways ivi-layout itself would be able to go from weston_surface
      to ivi_layout_surface are either searching through the list of all
      ivi_layout_surfaces or adding a dummy destroy listener to the
      weston_surface. Therefore the implementation is delegated to
      ivi-shell.c.
      
      Ivi-shell.c can easily look up the ivi_shell_surface for a
      weston_surface, and that will map 1:1 to an ivi_layout_surface.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: eucan's avatarEmre Ucan <eucan@de.adit-jv.com>
      eaa43fc3
  12. 24 Mar, 2016 3 commits
  13. 16 Mar, 2016 2 commits
  14. 04 Mar, 2016 1 commit
  15. 14 Dec, 2015 1 commit
  16. 07 Aug, 2015 1 commit
  17. 17 Jul, 2015 1 commit
    • Derek Foreman's avatar
      input: Pass the appropriate pointer type to bindings instead of a seat · 8ae2db5b
      Derek Foreman authored
      
      
      Normally we need to check if a seat's [device_type]_count is > 0 before
      we can use the associated pointer.  However, in a binding you're
      guaranteed that the seat has a device of that type.  If we pass in
      that type instead of the seat, it's obvious we don't have to test it.
      
      The bindings can still get the seat pointer via whatever->seat if they
      need it.
      
      This is preparation for a follow up patch that prevents direct access
      to seat->device_type pointers, and this will save us a few tests at
      that point.
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      8ae2db5b
  18. 26 Jun, 2015 1 commit
    • Pekka Paalanen's avatar
      text_backend: make destructor call explicit · aa9536a9
      Pekka Paalanen authored
      
      
      We used to rely on the order in which the
      weston_compositor::destroy_signal callbacks happened, to not access
      freed memory. Don't know when, but this broke at least with ivi-shell,
      which caused crashes in random places on compositor shutdown.
      
      Valgrind found the following:
      
       Invalid write of size 8
          at 0xC2EDC69: unbind_input_panel (input-panel-ivi.c:340)
          by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
          by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
          by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
          by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
          by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
        Address 0x67ea360 is 208 bytes inside a block of size 232 free'd
          at 0x4C2A6BC: free (vg_replace_malloc.c:473)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
      
       Invalid write of size 8
          at 0x4E3E0D7: wl_list_remove (wayland-util.c:57)
          by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191)
          by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
          by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550)
          by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264)
          by 0x40DB8B: weston_surface_destroy (compositor.c:1883)
          by 0x40DB8B: weston_surface_destroy (compositor.c:1873)
          by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
          by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
          by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
          by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
          by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
        Address 0x67ea370 is 224 bytes inside a block of size 232 free'd
          at 0x4C2A6BC: free (vg_replace_malloc.c:473)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
      
       Invalid write of size 8
          at 0x4E3E0E7: wl_list_remove (wayland-util.c:58)
          by 0xC2EDEE9: destroy_input_panel_surface (input-panel-ivi.c:191)
          by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
          by 0x4E3BC7B: wl_resource_destroy (wayland-server.c:550)
          by 0x40DB8B: wl_signal_emit (wayland-server-core.h:264)
          by 0x40DB8B: weston_surface_destroy (compositor.c:1883)
          by 0x40DB8B: weston_surface_destroy (compositor.c:1873)
          by 0x4E3B6BB: destroy_resource (wayland-server.c:537)
          by 0x4E3E085: for_each_helper.isra.0 (wayland-util.c:359)
          by 0x4E3E60D: wl_map_for_each (wayland-util.c:365)
          by 0x4E3BEC7: wl_client_destroy (wayland-server.c:675)
          by 0x4182F2: text_backend_notifier_destroy (text-backend.c:1047)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
        Address 0x67ea368 is 216 bytes inside a block of size 232 free'd
          at 0x4C2A6BC: free (vg_replace_malloc.c:473)
          by 0x4084FB: wl_signal_emit (wayland-server-core.h:264)
          by 0x4084FB: main (compositor.c:5465)
      
      Looking at the first of these, unbind_input_panel() gets called when the
      text-backend destroys its helper client which has bound to input_panel
      interface. This happens after the shell's destroy_signal callback has
      been called, so the shell has already been freed.
      
      The other two errors come from
        wl_list_remove(&input_panel_surface->link);
      which has gone stale when the shell was destroyed
      (shell->input_panel.surfaces list).
      
      Rather than creating even more destroy listeners and hooking them up in
      spaghetti, modify text-backend to not hook up to the compositor destroy
      signal. Instead, make it the text_backend_init() callers' responsibility
      to also call text_backend_destroy() appropriately, before the shell goes
      away.
      
      This fixed all the above Valgrind errors, and avoid a crash with
      ivi-shell when exiting Weston.
      
      Also using desktop-shell exhibited similar Valgrind errors which are
      fixed by this patch, but those didn't happen to cause any crashes AFAIK.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-By: default avatarDerek Foreman <derekf@osg.samsung.com>
      aa9536a9
  19. 23 Jun, 2015 2 commits
  20. 16 Jun, 2015 1 commit
  21. 15 Jun, 2015 1 commit
  22. 11 Jun, 2015 1 commit
  23. 28 Apr, 2015 1 commit
  24. 02 Apr, 2015 1 commit
  25. 02 Mar, 2015 2 commits
  26. 15 Dec, 2014 4 commits