| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IVI-shell provides a shell interface for Weston, which maps the GENIVI
API (http://www.genivi.org) for In-Vehicle Infotainment as Wayland-Ivi-Extension
(http://wiki.projects.genivi.org/index.php/Wayland_IVI_Extension_Design).
This patch is included in two protocol. The first is ivi-application protocol
which provided by weston. Next is ivi-controller protocol which provided by
Genivi's wayland-ivi-extension.
In IVI use case, the client create and destroy surface with the unique ID
by using ivi-application protocol. On the other hand, the controller such as
HMI Controller control some properties, which are visibility, position, size,
etc, with created the unique ID by using ivi-controller protocol.
It means the unique ID is necessary to create and control the ivi-surface and
the the ivi-layer. However Qt has no API to set the some surface or layer ID.
In this ivi-shell plugin, the unique ID can be set via the environment
parameter so that we can control the ivi-surface and ivi-layer. The
name of environment parameter is QT_IVI_SURFACE_ID.
QT_IVI_SURFACE_ID will be used as ivi-surface and ivi-layer. If application
needs more than two surfaces, ivi-surface IDs will be incremented.
When QT_IVI_SURFACE_ID isn't set, ivi-surface and ivi-layer ID will be
generated internally. The ID consists of the process ID and the surface
ID which is incremented in ivi-shell plugin.
The process ID is used as lower 22 bit per 32bit. 23 to 32 bit is used as
the surface IDs in a process.
e.g. When the process ID is 0x765 and create two surfaces,
ivi-layer ID is 0x765 and ivi-surface IDs are 0x765 and 0x00400765.
+------------+---------------------------+
|31 23|22 0|
+------------+---------------------------+
|0000 0000 00|00 0000 0000 0000 0000 0000|
|<- ID ->|<- process ID ->|
+------------+---------------------------+
We can set QT_WAYLAND_SHELL_INTEGRATION of the environment
parameter to "ivi-shell" to use IVI-shell.
Change-Id: Iddcfb3de89dc022530c0285524cf6bbf640147b6
Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Convert to a D-pointer, split between abstract base class and an implementation.
Also move implementation of the current built-in decoration to the "bradient"
plugin, named in glorious memory of the programmer-designed blue gradient that
will forever sear our eyeballs.
The decoration plugin may be specified using the environment variable
QT_WAYLAND_DECORATION.
Change-Id: Idc99ab06ae138ad299bad2b62b9595379bd007ab
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
|
|
|
|
| |
Change-Id: I3ede73420af9cb95820a9bec4fe7305f1107e22d
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
|
|
|
|
| |
And make wayland common files into a library, exporting all classes. Now
there is no need to do bulild hacks to make your own version of the
wayland plugin.
Change-Id: Ib4872863dfb5ab3f2bc0f4a94ae16fc1e7b63b88
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than defining which hardware integration should be used at
compile time, we should build each hardware integration as a plugin, and
load the one we want at runtime.
The default hardware integration is wayland-egl, but you are able to
override this using the environment variable
QT_WAYLAND_HARDWARE_INTEGRATION
Backends tested:
wayland-egl
xcomposite-egl
Backends untested:
xcomposite-glx
brcm-egl
Change-Id: Idee66574d232a9236898f68ca64145f471b1bb80
Reviewed-by: Andy Nichols <andy.nichols@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@gmail.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
Also fix so that QtCompositor can be built as shared object.
+ fix so that the default QT_WAYLAND_GL_CONFIG is wayland_egl
Change-Id: I02b72e99286584426bd37ab2d00bbc84af11efdc
Reviewed-by: Laszlo Agocs <laszlo.p.agocs@nokia.com>
|