[PATCH weston-ivi-shell v5 6/9] A reference implementation of UI client how to use ivi-hmi-controller.

[Pekka Paalanen]

On Thu, 20 Mar 2014 16:00:57 +0900
Nobuhiko Tanibata <NOBUHIKO_TANIBATA at xddp.denso.co.jp> 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 <NOBUHIKO_TANIBATA at xddp.denso.co.jp>
> ---
> 
> 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