On Thu, 20 Mar 2014 16:00:57 +0900 Nobuhiko Tanibata <[email protected]> wrote:
> This is launched from hmi-controller by using hmi_client_start and create a > pthread. > > The basic flow is as followed, > 1/ create pthread > 2/ read configuration from weston.ini. > 3/ draw png file to surface according to configuration of weston.ini > 4/ set up UI by using ivi-hmi-controller protocol > 5/ Enter event loop > 6/ If a surface receives touch/pointer event, followings are invoked according > to type of event and surface > 6-1/ If a surface to launch ivi_application receive touch up, it execs > ivi-application configured in weston.ini. > 6-2/ If a surface to switch layout mode receive touch up, it sends a request, > ivi_hmi_controller_switch_mode, to hmi-controller. > 6-3/ If a surface to show workspace having launchers, it sends a request, > ivi_hmi_controller_home, to hmi-controller. > 6-4/ If touch down events happens in workspace, > ivi_hmi_controller_workspace_control is sent to slide workspace. > When control finished, event: ivi_hmi_controller_workspace_end_control > is received. > > Signed-off-by: Nobuhiko Tanibata <[email protected]> > --- > > Changes for v2: > - squash Makefile to this patch > > Changes for v3 and v4: > - nothing. Version number aligned to the first patch > > Changes for v5: > - usleep with roundtrip uses CPU. replace them with wl_display_dispatch > > ivi-shell/Makefile.am | 2 + > ivi-shell/hmi-controller-homescreen.c | 1369 > +++++++++++++++++++++++++++++++++ > ivi-shell/hmi-controller-homescreen.h | 36 + > ivi-shell/hmi-controller.c | 3 +- > 4 files changed, 1409 insertions(+), 1 deletion(-) > create mode 100644 ivi-shell/hmi-controller-homescreen.c > create mode 100644 ivi-shell/hmi-controller-homescreen.h Would it not be simpler and more robust to make this an independent program like e.g. clients/desktop-shell.c is, rather than running it in a thread in the compositor? I would certainly prefer it to be. We would avoid threads in the compositor, and pulling in client side stuff. Now there is a huge risk you might be calling compositor functions from client code, and a crash in the client code would bring the whole compositor down. If we look at weston-desktop-shell, if it crashes, Weston will respawn it so fast that a user often does not even notice anything happened. ;-) And when you attach gdb, it won't stop also the compositor. Thanks, pq _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
