[RFC] New ivi-manager protocol and ilmControl APIs

Ucan, Emre (ADITG/SW1) eucan at de.adit-jv.com
Wed Apr 19 09:23:40 EDT 2017


Hello All,

I created now a PR to genivi wayland-ivi-extension with an updated version of ivi-manager protocol.

v2 changes:
- I added orientation requests and events again.
- I fixed some minor bugs in implementation. 

Try out:
 You can test it with these two branches:
https://github.com/eucan/wayland-ivi-extension.git :
ivi_manager_protocol_v2 branch
 https://github.com/eucan/weston.git: 2.0_with_patched_ivi-shell branch


Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

> -----Original Message-----
> From: genivi-ivi-layer-management [mailto:genivi-ivi-layer-management-
> bounces at lists.genivi.org] On Behalf Of Ucan, Emre (ADITG/SW1)
> Sent: Dienstag, 28. März 2017 11:13
> To: genivi-ivi-layer-management at lists.genivi.org
> Subject: [RFC] New ivi-manager protocol and ilmControl APIs
> 
> Hello All,
> 
> 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-manager clients are creating only one controller surface
>     and layer to manage all compositor side layers/surfaces.
>     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 property.
> 
>     Compositor sends properties of ivi-objects to ivi-manager 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-manager 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-manager protocol has different error codes for different
>     ivi-objects. If a request fails, an error event is always
>     sent.
> 
> ilm_getError:
>    Some requests to compositor can fail because
>    of reasons that we cannot control,
>    e.g.: application destroys the surface.
>    Therefore, compositor sends error events when
>    a request fails. If we try to get these errors
>    during Set APIs, we have to roundtrip wayland
>    connection to get current error message.
>    This will decrease the performance.
> 
>    Instead we can have the API ilm_getError to request
>    for error when we want.
> 
> ilm_surfaceSetType:
>   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 restricted.
> 
> Try out:
>  You can test it with these two branches:
> https://github.com/eucan/wayland-ivi-extension.git :
> ivi_manager_protocol_v1 branch
> https://github.com/eucan/weston.git: 2.0_with_patched_ivi-shell branch
> 
> Weston is plain 2.0 + only one patch which I sent to upstream:
> https://patchwork.freedesktop.org/patch/141658/
> 
> Best regards
> 
> Emre Ucan
> 
> Advanced Driver Information Technology GmbH
> Software Group I (ADITG/SW1)
> Robert-Bosch-Str. 200
> 31139 Hildesheim
> Germany
> 
> Tel. +49 5121 49 6937
> Fax +49 5121 49 6999
> eucan at de.adit-jv.com
> 
> ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car
> Multimedia GmbH and DENSO Corporation
> Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438
> Geschaeftsfuehrung: Wilhelm Grabow, Ken Yaguchi
> 
> 
> _______________________________________________
> genivi-ivi-layer-management mailing list
> genivi-ivi-layer-management at lists.genivi.org
> http://lists.genivi.org/mailman/listinfo/genivi-ivi-layer-management


More information about the genivi-ivi-layer-management mailing list