2014-07-07 17:04 に Pekka Paalanen さんは書きました:
On Tue, 20 May 2014 19:02:56 +0900
Nobuhiko Tanibata <[email protected]> wrote:
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.
Hmm, would be interesting to hear a bit more about that overhead
thing.
In your code:
- it is a thread, so it will be subject to scheduling anyway
- it still uses a normal Wayland connections (wl_display_connect),
so it will not skip any of the communication overheads
I'm just curious about what overheads you intended to avoid here.
Was it library loading at start-up? I can't think of anything else
right now.
Thanks for comment, pq!
My concerning was that process dispatch vs thread dispatch. Threads
share their memory space and the dispatch cost might be smaller than
process ones. If I can implement IVI clinet in the same process, it can
reduce dispatch code compare to process dispatching.
BR,
ntanibata
Thanks,
pq
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
