This fixes the breakage caused by "ivi-shell: make ivi-layout.c as a
part of ivi-shell.so"
hmi-controller.c:
A reference implementation of controller module does not use the layout
functions directly. This get function pointers at controller_module_init
which called by ivi-shell.
ivi-layout-export.h:
Definition of interfaces in a struction: ivi_controller_interface.
function pointers are set at ivi-layout.c.
ivi-layout-private.h:
Definition of some interfaces are remove bucause it is implemented in
ivi-layout.c and set it as function pointer. Several interfaces are kept
here because they are implemented in ivi-layout.c/transition.c but used
in other files.
ivi-layout-transition.c:
remove WL_EXPORT because export is not needed anymore.
remove unnesesary unsed method.
ivi-shell.c:
call controller_module_init of hmi-controller to init it and set
function pointers. If the interface_version is equal or
greater than what hmi_controller was built with, things are pass.
If the interface_version is smaller than what the controller expects,
it has to fail because it cannot work. This is followed the manner,
- never remove a function pointer
- never modify an existing function signature
- additions are allowed at the end of struct ivi_controller_interface
- all function pointers must always be populated and working in
ivi-shell.so (ivi-layout.c etc.)
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi-layout.so is separately built and loaded by using dlopen with
RTLD_GLOBAL. This was because these apis defined in ivi-layout.so shall
be used by ivi-modules; e.g. hmi-controller. This shall be improved that
a struct ivi_layout_api contains the whole exported API as function
pointers to be exposed as module_init.
This patch alone builds, but loading controller modules at runtime
failes. This failure will be fixed by following patches.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Interfaces for properties setting shall be implemented in ivi-layout.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In the future, re-alignmenet of WL_EXPORT per method should be done.
For that work, re-ordering is required to be used by another method.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
ivi_layout_transition_layer_render_order is not necesary called. Remove
the method and methods called by it.
Signed-off-by: Nobuhiko Tanibata <NOBUHIKO_TANIBATA@xddp.denso.co.jp>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When ivi-module is not set in weston.conf, we probably want to tell the
user about their error instead of just dying.
Signed-off-by: Ondřej Majerech <majerech.o@gmail.com>
[Pekka: include Tanibata's suggestion, fix file name, fix surrounding
coding style]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
load_modules currently ignores errors signalled by both
weston_load_module and module_init, and instead always returns 0. Its
return value appears to be checked in callers, so we most likely want to
propagate any errors.
Signed-off-by: Ondřej Majerech <majerech.o@gmail.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The fd member of clipboard_source structure was not set
but was used in close().
v2. don't do unnecessary changes
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
There were unchecked malloc and no free for this memory.
Also simplify error handling in one function.
v2. remove check if memory is NULL, according to man pages,
free(NULL) is a no-op
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
wl_display_dispatch() just dispatches events that are in
default and display queues and if there are no events,
then it will wait for them. But only dispatching
the events doesn't guarantee that we got all the global announcements,
we need to do sync too. Therefore use wl_display_roundtrip() instead
of wl_display_dispatch().
Signed-off-by: Marek Chalupa <mchqwerty@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
To produce the bug, build and run: (you don't need the game data to test)
https://github.com/clintbellanger/flare-engine/
$ mv ~/.config/flare ~/.config/flare.bak
$ ./flare # click 'configure', set full screen mode then click 'ok'
# weston will crash and dump core.
[Pekka: edited the commit message]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Logging is activated and deactivated with the debug key binding 't'.
When activated, it creates a new log file, where it records the events.
The log file contains events and detailed object information entries in
JSON format, and is meant to be parsed in sequence from beginning to the
end.
The emitted events are mostly related to the output repaint cycle, like
when repaint begins, is submitted to GPU, and when it completes on a
vblank. This is recorded per-output. Also some per-surface events are
recorded, including when surface damage is flushed.
To reduce the log size, events refer to objects like outputs and
surfaces by id numbers. Detailed object information is emitted only as
needed: on the first object occurrence, and afterwards only if
weston_timeline_object::force_refresh asks for it.
The detailed information for surfaces includes the string returned by
weston_surface::get_label. Therefore it is important to set
weston_timeline_object::force_refresh = 1 whenever the string would
change, so that the new details get recorded.
A rudimentary parser and SVG generator can be found at:
https://github.com/ppaalanen/wesgr
The timeline logs can answer questions including:
- How does the compositor repaint cycle work timing-wise?
- When was the vblank deadline missed?
- What is the latency from surface commit to showing the new content on
screen?
- How long does it take to process the scenegraph?
v2: weston_surface::get_description renamed to get_label.
v3: reafctor a bit into fprint_quoted_string().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When printing out logs from Weston's actions, mainly for debugging, it
can be very difficult to identify the different surfaces. Inspecting
the configure function pointer is not useful, as the configure functions
may live in modules.
Add vfunc get_label to weston_surface, which will produce a short,
human-readable description of the surface, which allows identifying it
better, rather than just looking at the surface size, for instance.
Set the label function from most parts of Weston, to identify cursors and
drag icons, and panels, backgrounds, screensavers and lock surfaces, and
the desktop shell's application surfaces.
v2: renamed 'description' to 'label', so we get
weston_surface_set_label_func().
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
- 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>
- 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>
- 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>
- 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>
- 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.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>
- 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>
- 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>
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>
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>
calloc (and zalloc) set the allocated memory to 0, so there's really no
need to do it manually.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
[Pekka: dropped the src/evdev.c hunk.]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Just changes some places where a malloc failure is unhandled
to our xmalloc function that exit()s a little more gracefully.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
Since this is an inlined function, move it to a common header file.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Mostly remove headers that aren't actually needed for anything.
Add stdint.h to permit dropping xf86drm.h, which is otherwise unneeded.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Acked-by: Marek Chalupa <mchqwerty@gmail.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When ending a drag in the window the cursor will be wrong until the mouse
is moved again. This is because the item being dragged isn't added
until after the enter event.
Also, when picking up an item while moving the mouse the cursor can switch
back to a non-drag cursor before the drag begins. This is because of a
slight delay between button click and drag start.
Finally picking up or dropping an item under a second pointer could cause
that pointer to have the wrong cursor.
Closes one of the issues in bug 56298
https://bugs.freedesktop.org/show_bug.cgi?id=56298
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
While the test is actually correct (for non-negative numbers), it's not
at all clear and seems to be an accidental order of operations mistake.
Also, add an assert() to make sure this number is never negative.
Closes bug 86346 - https://bugs.freedesktop.org/show_bug.cgi?id=86346
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
Explain carefully why we need two roundtrips, not just one, not just
dispatch and roundtrip, but two roundtrips after creating the
wl_registry object.
v2: Explain what initial events are, and that this is a general
technique.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Marek Chalupa <mchqwerty@gmail.com>
If a keyboard exists but it has no current focus, yet something asks the
input-panel to come up, we would crash here. Check that there is a focus
before attempting to use it.
Maybe there should not even exist a case where input-panel tries to come
up without a keyboard focus, but I am not sure there is no race where it
could happen.
In any case, this fix was brought up by the ivi-shell work, where I
suppose you can somehow hit it.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Cc: Tanibata, Nobuhiko <ntanibata@jp.adit-jv.com>
When getting the focus we get the list of pressed keys, but we are
not supposed to run the key binding on them.
Reviewed-by: Daniel Stone <daniel@fooishbar.org>