rpi-renderer: don't pass a box to pixman_region32_contains_point()

We don't care which box contained the point, so don't pass one in.

Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
input: send focus events to the focused client when running a key binding

When running a key binding we don't send the key press to the client
via the wl_keyboard.key event. Instead, send a wl_keyboard.leave/enter
pair so that the client knows the actual state of the keyboard.

Reviewed-by: Daniel Stone <daniel@fooishbar.org>
fbdev: Remove unnecessary semicolon

[daniels: removed extraneous changes]
ivi-shell: add README for ivi-shell

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
protocol: add interface ivi_application extension

- introduces ivi-application.xml

Many applications in an IVI-system are special single-purpose
applications that have a very specific role in the whole IVI UI, for
example a rear camera, speedometer, map, etc. The IVI system vendor
specifies what these are and how they integrate into the UI. They also
vary between particular IVI systems. This is why we use (system-)global,
unique, pre-determined ID numbers to tell what wl_surface is which
application, instead of writing specific shell requests for each one.
Using ID numbers allows vendors to easily invent new component
applications without extending or breaking the actual Wayland protocol.
In IVI-systems, the ID is a standard concept already used in several
APIs, with a vendor-specified global definition of ID assignments.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-shell: add IVI layout APIs

- ivi-layout.so
- introduces ivi-layout-export.h, ivi-layout.[ch]

API set of controlling properties of surface and layer which groups
surfaces. An unique ID whose type is integer is required to create
surface and layer. With the unique ID, surface and layer are identified
to control them. The API set consists of APIs to control properties of
surface and layers about followings,

- visibility.
- opacity.
- clipping (x,y,width,height).
- position and size of it to be displayed.
- orientation per 90 degree.
- add or remove surfaces to a layer.
- order of surfaces/layers in layer/screen to be displayed.
- commit to apply property changes.
- notifications of property change.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-shell: add the shell plugin for In-Vehicle Infotainment system

- ivi-shell.so
- introduces ivi-shell/ivi-shell.[ch]

In-Vehicle Infotainment system traditionally manages surfaces with
global identification. A protocol, ivi_application, supports such a
feature by implementing a request, ivi_application::surface_creation
defined in ivi_application.xml.

The ivi-shell explicitly loads ivi-layout.so and a module to add
business logic like how to layout surfaces by using ivi-layout APIs.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
protocol: ivi hmi controller protocol to set up IVI style UI

- introduces ivi-hmi-controller.xml

This protocol realizes following features,
- UI ready
- changing modes; tiling, side by side, full_screen, and random
- Give control a surface; workspace to be controlled by using ivi layout
  APIs
- Display/undisplay a surface; home contains sevaral workspaces to
  launch applications

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-shell: a reference implementation how to use ivi-layout internal APIs

- hmi-controller.so
- introduces hmi-controller.so

The library is used to manage layout of surfaces/layers. Layout change
is triggered by ivi-hmi-controller protocol, ivi-hmi-controller.xml. A
reference how to use the protocol, see ivi-shell-user-interface.c.

In-Vehicle Infotainment system usually manages properties of
surfaces/layers by only a central component which decide where
surfaces/layers shall be. This is differenct use case from desktop
style; each application can request property of its window via xdg-shell
protocol, like fullscreen and set its to top level. In-Vehicle
Infortainment system doesn't allow each application to chagen them from
its application because of safty reasons. The concept of layer is
simillar with a use case of cursor layer of Destop. For In-Vehicle
Infortainment system, it is extended to all applications. For example,
rearview camera application is assigned to a layer to group several
surfaces, e.g. captured image and drawing lines separately. Central
manaegr can control property of the layer of rearview camera.

This reference show examples to implement the central component as a
module of weston.

Default Scene graph of UI is defined in hmi_controller_create. It
consists of
- In the bottom, a base layer to group surfaces of background, panel,
  and buttons
- Next, a application layer to show application surfaces.
- Workspace background layer to show a surface of background image.
- Workspace layer to show launcher to launch application with icons.
  Paths to binary and icon are defined in weston.ini. The width of
  this layer is longer than the size of screen because a workspace
  has several pages and is controlled by motion of input.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
clients: a reference implementation of UI client how to use ivi-hmi-controller.

- introduces ivi-shell-user-interface.c

This is launched from hmi-controller by launch_hmi_client_process and
invoke a
client process.

The basic flow is as followed,
1/ process invoked
2/ read configuration from weston.ini.
3/ draw png file to surface according to configuration of weston.ini
4/ all parts of UI are ready. request "UI_ready" to draw UI.
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@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
data: add reference image files for weston-ivi-shell-user-interface

- introduces reference images used by weston-ivi-shell-user-interface.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-shell: a reference of weston.ini for ivi-shell and ivi-hmi-controller.

- introduces ivi-shell/weston.ini.in

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
clients: support ivi-application.xml for clients/simple-shm.c

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
clients: support ivi-application.xml for clients/simple-egl.c

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
clients: support ivi-application.xml for clients/window.c

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-shell: reference implementation of input panel for ivi-shell

- introduces ivi-shell/input-panel-ivi.c which is basically copied
  from desktop shell. It shall be improvaded to remove duplicate
  implementation.

Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
compositor: introduce struct weston_backend

This is a preliminary change for libweston, with no functional modifications.
Separate the backends and the core weston_compositor struct, by creating
the weston_compositor in the main(), and having the various backends extend
the weston_backend struct, an instance of which is returned by the backend
entry point.
don't use weston_config in the backends code

This is to make them usable by future libweston users, since they will
not use weston_config.
weston_config is still used in the backends entry points, which will
later on live in their own files.
compositor: remove the weston_config field from weston_compositor

Instead of the central weston_config pointer we now store it in some
module-specific pointers. This way we can remove them one by one.
compositor: add API to manage compositor instances