Versions Compared

Old Version 6

changes.mady.by.user Tadao Tanikawa

Saved on

compared with

New Version Current

changes.mady.by.user Tadao Tanikawa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The use of AGL UCB integration can be divided into two main categories.

  • development platform for innovation, which means individual features and components, as well as prototyping and demo/PoC development
    • It is preferable to reuse the existing AGL UCB (including the demo implementation), because the other will be developed from scratch and will not be available for some time.
  • integrate reference system which is baseline of product embedded
    • This will be a minimally configured system, which makes it very difficult to use for development purposes, such as new features and components.

Development platform

Maximum reuse of existing AGL UCB

GOAL: provision of development platform

  • for Innovation
  • for development new features/component as SDK

Use case of development

 inside container
  • develop applications/services
    • integrate packages inside containeragl-demo-platform,

    Separate development platform and reference of product embedded

    • Development platform
      • Reusing agl-image-weston (because we need to use nested compositor architecture until DRM release manager will come)
    • Introduce new layer to add-on container features on it
      •  add LXC support
      • add  container configuration for  agl-ivi  (for agl-demo-platform) and agl-ic (for agl-cluster-demo-platform
  • between containers
    1. link apps/services of multiple containers together
      • tbtnavi of CES demo
  • inside host
    1. service only in host
      • container runtime, container manager, display manager (DRM release manager / host compositor)
  • between host and container 
    1. server/client 
    2. security framework/integration
      • unprivileged container (LSM and capability)
    3. management of devices
      • hotpluging
      • pass through
      • sharing

    • Reference Integration of Product development's baseline

    New integration from scratch? (T.B.D)

    GOAL: Reference QM implementation to embedded product system

    It is preferable to start with a minimum configuration, core-image(QM) and add-on (either QM or Non-QM)

    • core image for QM
      • all packages should be certificated by AGL development process
      • existing minimal image are large
        • agl-image-* are still too large to certificate all packages
          • If we use agl-image-*, dependency on appfw/SMACK is problem/challenging.  There are several possible options,
            • Remove appfw and/or SMACK dependency
            • Accept them as third party (existing) OSS and certificate them by ICE development process
            • Re-implement them following the ICEG development process.
        • poky/core-image-minimal is still large but If we can categorize packages that require certificated and those that don't, might be able to use
        • poky-tiny and other small distributions are under investigation
      • refer to the VERY long term maintained source code like Redhat/CentOS/Debian)
        • recipes and patches are common, identified by name, 'agl-ivi' and 'agl-ic' (default name, can be changed by variable in recipes/local.conf)
        • network configuration
          • use lxc-net by default  (sharing host network adapter by containers to access internet)
          • TBD: introduce guest pass-through (e.g. internet access permitted only to agl-ivi) and make these selectable
        • very basic container manager
          • To support nested compositor easily, add easy-launcher, lxc-launcher(runlxc)
          • easy to select one from predefined configurations
            • running 1 container, agl-ic or agl-ivi
            • running 2 container, agl-ic and agl-ivi 
          • Because multiple monitors cannot be usable on QEMU with AGL image
            • QEMU + SPICE can support multiple monitors but it requires spice-vdagent and xwayland(xserver + xrandr/Xinerama)
            • not yet investigation: whether weston + xwayland can do the same above
    • Reference of product embedded
      • TBD

    NOTE: QEMU's multi-monitor (1 seat with multiple heads) support appears to be limited

    #
    # QEMU + VirGL(GPU acceleration) + Multiple monitors
    #
    # using GTK UI frontend
    PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"
    # enable GPU acceleration
    PACKAGECONFIG_append_pn-qemu-system-native = " glx virglrenderer"
    # 
    # Results
    #
    # GTK UI Frontend
    # OK: 1 monitor + GPU accelerated
    # -device virtio-vga,virgl=on -display gtk,gl=on
    # OK: 2 monitors
    # -device virtio-vga,max_outputs=2 -display gtk
    # NG: 2 monitors + GPU accelerated (QEMU not launched)
    # -device virtio-vga,virgl=on,max_outputs=2 -display gtk,gl=on
    #
    # SDL2 UI Frontend
    # OK: 1 monitor + GPU accelerated
    # -device virtio-vga,virgl=on -display sdl,gl=on 
    # NG: 2 monitors (only 1 monitor is on)
    # -device virtio-vga,max_outputs=2 -display sdl
    # NG: 2 monitors + GPU accelerated (QEMU not launched)
    # -device virtio-vga,virgl=on,max_outputs=2 -display sdl,gl=on
    #