1. 16 Mar, 2016 1 commit
    • Pekka Paalanen's avatar
      ivi-shell: call shell_surface_send_configure() directly · 1f821933
      Pekka Paalanen authored
      
      
      For some reason, it seems that ivi-layout.c has tried hard to avoid
      calling directly into ivi-shell.c. This means there is a jump through
      hoops just to get the configure event sent to the clients. Ivi-shell
      registers a listener for a ivi-layout signal for sending the event.
      
      Instead, let ivi-layout.c call directly into ivi-shell.c, and expose a
      function to send out the configure events. This reduces some confusion
      on who calls what.
      
      The main idea though is that this makes ivi-shell.c not depend on struct
      ivi_layout_surface fields directly anymore. In following patches,
      ivi_layout_surface can be made opaque for ivi-shell.c.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: eucan's avatarEmre Ucan <eucan@de.adit-jv.com>
      1f821933
  2. 04 Mar, 2016 1 commit
  3. 14 Dec, 2015 1 commit
  4. 07 Aug, 2015 1 commit
  5. 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
  6. 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
  7. 23 Jun, 2015 2 commits
  8. 16 Jun, 2015 1 commit
  9. 15 Jun, 2015 1 commit
  10. 11 Jun, 2015 1 commit
  11. 28 Apr, 2015 1 commit
  12. 02 Apr, 2015 1 commit
  13. 02 Mar, 2015 2 commits
  14. 15 Dec, 2014 4 commits
  15. 04 Dec, 2014 2 commits