compositor: add weston_client_start()

weston_client_start() is a new wrapper around weston_client_launch(),
that does the process tracking on its own, and logs the process exit
status.

When users of weston_client_start() want to know when the process exits,
they should hook into the wl_client destroy signal. This works for cases
where the client is not expected to disconnect without exiting.

As wl_client destructor and the sigchld handler run in arbitary order,
it is usually difficult for users to maintain both struct weston_process
and a struct wl_client pointer. You would need to wait for both
destructor and handler to have run, before attempting to respawn the
client.

This new function relieves the caller from the burden of maintaining the
struct weston_process, assuming the caller is only interested in client
disconnects.

Cc: Boyan Ding <stu_dby@126.com>
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
shell: fix race on desktop-shell exit

The desktop shell plugin registers both a wl_client destroy signal
listener, and a sigchld handler, when launching weston-desktop-shell.
However, nothing guarantees in which order do the wl_client destructor
and the sigchld handler run.

Luckily, the sigchld handler cannot interrupt any code, because we
handle the signal via signalfd, which means it is handled like any event
in the compositor's main event loop.

Still, shell.c has a race, that when lost, can cause a crash, as
described in bug #82957.

If the sigchld handler happens to run first, it will try to launch a new
weston-desktop-shell without removing the destroy listener from the old
wl_client first. This leads to list corruption, that may cause a crash
when the old wl_client gets destroyed.

Simply removing the destroy listener in the sigchld handler is not
enough, because respawning sets shell->child.client pointer, and if
the wl_client destructor runs after, it will reset it to NULL.

OTOH, the wl_client destroy handler cannot reset shell->child.process,
because that would cause the sigchld handler in weston core to not find
the process tracker anymore, and report that an unknown process exited.

Turns out, that to make everything work, we would need to wait for both
the wl_client destructor and the sigchld handler to have run, before
respawn. This gets tricky.

Instead, solve the problem by removing shell->child.process. Use the new
weston_client_start() which automatically creates and manages the struct
weston_process. The shell does not need to know about the process exit,
it only needs to know about the client disconnect. Weston-desktop-shell
will never attempt to reconnect, and it would not work even if it did,
so disconnect is equivalent to weston-desktop-shell exiting.

This should permanently solve the race for weston-desktop-shell.

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=82957
Cc: Boyan Ding <stu_dby@126.com>
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
compositor: leave no zombie behind

When SIGCHLD fires, we may have more than one zombie to be collected.
Run waitpid() in a loop until no more zombies are found, and clean them
all up.

It looks like the SIGCHLD signalfd does not trigger again for remaining
zombies, so we need the loop.

This works around a crash in text_backend_notified_destroy, which ends
up using stale input_method.client if the sigchld handler is not called.
The crash could be triggered by removing both weston-desktop-shell and
weston-keyboard, so that both would try to respawn and give up, and then
quitting Weston.

Cc: rawoul@gmail.com
Cc: Boyan Ding <stu_dby@126.com>
Cc: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
simple-shm: remove an unnecessary call of wl_display_get_fd()

Reviewed-by: Nils Chr. Brause <nilschrbrause@gmail.com>
multi-resource: remove an unnecessary call of wl_display_get_fd()

Signed-off-by: Ryo Munakata <ryomnktml@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add font entry to shell section for title fonts

cairo-util has used sans font family for title fonts so far.
But sans doesn't support non-ascii characters.
So now let users choose a font family for titles.

The entry name is generic, 'font' so that other places
where draw texts can use this entry too.

Signed-off-by: Ryo Munakata <ryomnktml@gmail.com>