[RFC] New ivi-manager protocol and ilmControl APIs

Ucan, Emre (ADITG/SW1) eucan at de.adit-jv.com
Tue Mar 28 05:12:24 EDT 2017


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





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