diff options
author | Emre Ucan <eucan@de.adit-jv.com> | 2017-05-17 13:56:31 +0200 |
---|---|---|
committer | Emre Ucan <eucan@de.adit-jv.com> | 2017-05-18 11:36:13 +0200 |
commit | debca0cf621cac85696326f10ecdb844ff5fe6f2 (patch) | |
tree | d355591e52378e21d3dee7d12750761d1a14f782 /protocol/CMakeLists.txt | |
parent | fe28c5266795a477b1bd24d3a91a31d06c839a1e (diff) | |
download | wayland-ivi-extension-debca0cf621cac85696326f10ecdb844ff5fe6f2.tar.gz |
protocol: introduce ivi-wm protocol
This new protocol is thought as a replacement
for ivi-controller protocol. I will explain
differences and new features of this new protocol
below.
Object Creation/Deletion:
Ivi-controller clients had to create a client side
object for every existing layer/surface in compositor side.
This made initialization and denitialization of clients
complicated, because many objects had to be created.
Furthermore, we had to round-trip signals between clients
and the compositor many times during deinitialization.
Ivi-wm clients are not creating controller surfaces
and layers. The ivi-wm object is used for all requests.
Therefore, initilization and deinitialization are more
simple.
Sending properties of layers/surfaces/screens:
Compositor sent properties of ivi-objects continuously
to ivi-controller clients. Compositor updated them after
every property change. But most of the time clients are
not interested on properties. Because in most systems,
they are one ivi-controller client which manages everything.
Therefore, it knows already changed properties.
Compositor sends properties of ivi-objects to ivi-wm clients
only they request it with ivi_manager_screen/layer_surface_get
request.
Removing unused/unnecessary bits of ivi-controller:
- *surface_set_configuration
- *surface_set_orientation
- surface orientation event
- surface pixelformat event
- surface content event
- surface layer event
- *layer_set_configuration
- *layer_set_orientation
- *layer_screenshot
- *layer_set_render_order
- layer configuration event
- layer orientation event
- layer screen event
- *screen_set_render_order
Setting and Getting Render order
In ivi-controller protocol, an ivi_controller_surface
got an ivi_controller_layer object, if the surface was
added to the layer. This made it impossible to support
one surface on many layers future.
In ivi-wm protocol, clients get surface/layer added
event. The event sends only a surface/layer id. Therefore,
it can be on different render order list in the same time.
In ivi-controller protocol, render order was sent in a wl_array.
Therefore, we have to dynamically allocate memory in client and
compositor side.
Now render order is changed with sending add/remove_surface/layer
requests. In every request, one surface/layer id is sent.
Therefore, no dynamic memory allocation is required.
Types of Surfaces:
If a surface is restricted type, visible contents of the surface is
strictly controlled by the compositor. Its content is not allowed
to be go out of its destination region. If the application resizes
its buffers or uses wp_viewporter protocol to scale its contents,
the old destination region would causes visible glitches.
To avoid these issues, the controller process mark a surface as desktop
compatible. Source and destination regions of a desktop compatible
surface will be modified accordingly,when application sends a request
for resizing or scaling its contents. Therefore, applications contents
will be drawn according to application's wishes.
On the other hand, source and destination regions will be strictly
enforced, when the surface's type is restricted. The default type for
a surface is ivi.
Error Handling.
ivi-wm protocol has different error codes for layers, surfaces
and screens. If a request fails, an error event is always
sent.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Diffstat (limited to 'protocol/CMakeLists.txt')
-rw-r--r-- | protocol/CMakeLists.txt | 50 |
1 files changed, 25 insertions, 25 deletions
diff --git a/protocol/CMakeLists.txt b/protocol/CMakeLists.txt index 6d2c9dd..693d76d 100644 --- a/protocol/CMakeLists.txt +++ b/protocol/CMakeLists.txt @@ -52,27 +52,27 @@ add_custom_command( ) add_custom_command( - OUTPUT ivi-controller-client-protocol.h + OUTPUT ivi-wm-client-protocol.h COMMAND ${WAYLAND_SCANNER_EXECUTABLE} client-header - < ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml - > ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-client-protocol.h - DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml + < ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml + > ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-client-protocol.h + DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml ) add_custom_command( - OUTPUT ivi-controller-server-protocol.h + OUTPUT ivi-wm-server-protocol.h COMMAND ${WAYLAND_SCANNER_EXECUTABLE} server-header - < ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml - > ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-server-protocol.h - DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml + < ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml + > ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-server-protocol.h + DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml ) add_custom_command( - OUTPUT ivi-controller-protocol.c + OUTPUT ivi-wm-protocol.c COMMAND ${WAYLAND_SCANNER_EXECUTABLE} code - < ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml - > ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-protocol.c - DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-controller.xml + < ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml + > ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-protocol.c + DEPENDS ${CMAKE_SOURCE_DIR}/protocol/ivi-wm.xml ) add_custom_command( @@ -138,9 +138,9 @@ add_library(${PROJECT_NAME} STATIC ${CMAKE_CURRENT_BINARY_DIR}/ivi-application-client-protocol.h ${CMAKE_CURRENT_BINARY_DIR}/ivi-application-server-protocol.h ${CMAKE_CURRENT_BINARY_DIR}/ivi-application-protocol.c - ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-client-protocol.h - ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-server-protocol.h - ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-protocol.c + ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-client-protocol.h + ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-server-protocol.h + ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-protocol.c ${CMAKE_CURRENT_BINARY_DIR}/ivi-input-client-protocol.h ${CMAKE_CURRENT_BINARY_DIR}/ivi-input-server-protocol.h ${CMAKE_CURRENT_BINARY_DIR}/ivi-input-protocol.c @@ -201,13 +201,13 @@ add_custom_target(ivi-application-doc ) #============================================================================================= -# generate documentation ivi-controller API +# generate documentation ivi-wm API #============================================================================================= -SET(IVI_CTL_XML ${CMAKE_CURRENT_SOURCE_DIR}/ivi-controller.xml) -SET(IVI_CTL_CLIENT_H ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-client.h) -SET(IVI_CTL_SERVER_H ${CMAKE_CURRENT_BINARY_DIR}/ivi-controller-server.h) +SET(IVI_CTL_XML ${CMAKE_CURRENT_SOURCE_DIR}/ivi-wm.xml) +SET(IVI_CTL_CLIENT_H ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-client.h) +SET(IVI_CTL_SERVER_H ${CMAKE_CURRENT_BINARY_DIR}/ivi-wm-server.h) -add_custom_target(ivi-controller-doc +add_custom_target(ivi-wm-doc COMMAND wayland-scanner client-header < ${IVI_CTL_XML} > ${IVI_CTL_CLIENT_H} COMMAND wayland-scanner server-header < ${IVI_CTL_XML} > ${IVI_CTL_SERVER_H} @@ -215,17 +215,17 @@ add_custom_target(ivi-controller-doc | sed 's!___DOC_NAME___!IVI Controller API!' | sed 's!___DOC_VERSION___!${IVI_EXTENSION_VERSION}!' | sed 's!___INPUT_FILE___!${IVI_CTL_CLIENT_H} ${IVI_CTL_SERVER_H}!' - | sed 's!___OUTPUT_DIR___!ivi-controller-tmp!' + | sed 's!___OUTPUT_DIR___!ivi-wm-tmp!' | doxygen - - COMMAND make --silent -C ivi-controller-tmp/latex + COMMAND make --silent -C ivi-wm-tmp/latex - COMMAND cp ivi-controller-tmp/latex/refman.pdf - ${CMAKE_BINARY_DIR}/ivi-controller-api-${IVI_EXTENSION_VERSION}.pdf + COMMAND cp ivi-wm-tmp/latex/refman.pdf + ${CMAKE_BINARY_DIR}/ivi-wm-api-${IVI_EXTENSION_VERSION}.pdf DEPENDS ${IVI_CTL_XML} - COMMENT "Generating ivi-controller-api-${IVI_EXTENSION_VERSION}.pdf" + COMMENT "Generating ivi-wm-api-${IVI_EXTENSION_VERSION}.pdf" ) #============================================================================================= |