2014-04-25 20:55 に Pekka Paalanen さんは書きました:
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.
;-)
I agree. I apply your comments in v5. it is now process.
Before, I implemented it as a thread to reduce overhead of process
dispatch.
I experienced such a overhead before. However at first, I shall follow
wayland current sample like desktop-shell, invoke it as process.
If ivi vendor want to it as a thread with the same concerning, it can
easily do it by itself.
BR,
Nobohiko
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
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
