wlroots - iot.bzh...wlroots : a candidate for next agl hmi framework march-2019 6 why wlroots ? we...

WLROOTS a potential foundation for next

AGL Wayland/HMI Architecture

Tokyo AGL/AMM March/2019Fulup Ar Foll Lead Architect

[email protected]

March-2019 WLROOTS : a candidate for next AGL HMI framework

2

IoT.bzh team

● Mostly dedicated to AGL● https://iot.bzh/en/● http://github.com/iotbzh

Workshop in Lorient

LORIENT

vannes

https://iot.bzh/en/

http://github.com/iotbzh

March-2019WLROOTS : a candidate for next AGL HMI framework 3

HMI framework : not a New Concern within AGL community


Lots of Discussions & Meetings

Screenshot from discussion at Linux Foundation San Francisco (Dec-2018)


Well Accepted Requirements● Compositor / Window Manager

● Create, Destroy, Move, Resize, Hide, Show● Rotate, Decorate

● System UI applet● Notification, Consent● Tab bar● Background image● Voice agent interaction

● Home-screen / Launcher / Desktop-menu● Not always required (eg: cluster)● Configurable User Menu Icons

● Event Input Manager● Keyboard, Mice, …● AGL event (eg: CAN)● Voice event


Why WLROOTS ?

● We cannot wait any longer● We need an active community to foster innovation● We need someone to handle Wayland complex back magic● We do not need a compositor, but a foundation to write one/many● WLROOTS was designed after Weston+WLC. Leverage many lessons

learnt from the past.

● We need something flexible to support: Cluster, IVI, Boats, ...


IVI-shell Community Support


WLROOTS Community Support


What Wayland Complexity to Abstract ?

● The EGL (OpenGL) context● DRM (display) resources● LibInput resources● Rendering windows to the display(s)● Communicating with Wayland clients + Security model● Optionally Xwayland (X11) support


WLROOTS/SWAY “unique” features

● Rotated displays● Touchscreen bindings● Drawing tablet support● Mouse capture for games● Fractional display scaling● Display port daisy chaining● Multi-GPU support


WLROOTS Backends

● Abstract low level input/output implementations for you– Not a Wayland concept, but they provide API to simplify compositor code.

● Each backend generates● Input(s): Mice, Keyboard, …● Outputs(s): Screen (physical, virtual)● Signals (e.g: available output/input)

● Typical WLROOTS backends● Drm utilizes the Linux DRM subsystem to render directly to your physical displays.● Libinput leverages libinput to enumerate and control physical input devices.● Wayland/X11 creates “outputs” as windows on another running Wayland/X11 compositors

● Extendable model● Multiple screen, remote display, …● Virtual signals (eg: CAN, gesture)


WLROOTS protocols

● Provide API Interface for Wayland clients to communicate● Mostly imported from other projects

● XDG-shell● Orbital, Gtk,…

● Original ones● Layer-shell● Server window decoration● Virtual keyboard

● Securable depending on client (eg: orbital for screenshot)● API to add global (eg: screen size for screenshot)


WLROOTS main Shells● XDG-shell standard application desktop shell

● Main surface, Popup, ...● Size, Anchor, Min/Max size, …● Show, Hide, Move, Fullscreen, ...

● Layer-shell for system app like taskbar, notification, …● Static placement on screen, in display layer (background, foreground, ...)● Exclusion zone● Grab/Ignore keyboard

● Specialized shells● Screen capture● Virtual keyboard● ….


WLROOTS Inputs● Types

● WLR_INPUT_DEVICE_KEYBOARD● WLR_INPUT_DEVICE_POINTER● WLR_INPUT_DEVICE_TOUCH● WLR_INPUT_DEVICE_TABLET_TOOL● WLR_INPUT_DEVICE_TABLET_PAD

● Cursor/Pointer (hardware & software)● wlr_pointer, wlr_xcursor● wlr_output_cursor_set_image,

● Helpers● wlr_seat

Note: WLROOTS input manager leaves more work to client than some Wayland abstraction library like WLC, but on the other hand leave full freedom to implement your own user experience.


Demo


WLROOTS dependencies

WLROOTS & SWAYWM (master feb-2019)

● Wayland 1.16● WL-Protocols 1.16● Meson 0.49

AGL-GG

● Yocto/2.4 (rocko)● Wayland 1.13● WL-protocols 1.10● Meson (none)

AGL-HH

● Yocto/2.6 (thud)● Wayland 1.16● WL-protocols 1.16● Meson 0.47.2(*)

(*) Backport required, but little dependencies, not a real issue.


Conclusion (WLROOTS)● A valid foundation for AGL

● Very strong and active community● A strong common base for building custom/proprietary compositors● Written in C and easy to build under Yocto● APIs driven, easy to integrate with AGL Application Framework security

model● Extendable backend mechanism to support custom input/output devices● Native embedded device emulation for debug under Wayland/X11

● Constraints● Still under intensive development● Dependencies Impose a shift to latest Yocto version● Very flexible but not as integrated as other Wayland lib (eg: WLC)


Conclusion (SWAY)

● Should fit most of AGL developers needs● Works on both AGL and standard Linux● Support an X11+Wayland embedded mode ● Written in C, not too complex to build with Yocto● Configurable through a simple config file, very close to i3 (popular WM on X11)● Inherit multi-screen out of the box from WLROOTS

● Might not fit with OEM production constraints● For a unique by-brand user experience, a custom compositor based on

WLROOTS might be a better choice than customizing SWAY.


Conclusion (To Do List)

● Must Have– Map AGL app-framework and security model on WLROOT APIs

● Signalling (CAN, Monitoring, Notifications, ...)● Voice agent

– Few system UIs based on Layer-Shell● Taskbar● Notification (consent, voice, ...)● Contextual menu/launcher

– Build a menu launcher equivalent to current homescreen (probably on XDG-shell)● May Have

– Add Toyota current homescreen/compositor API through AGL app-framework

– Add IVI-shell protocol

strong


Questions ?

● Email: [email protected]● Slides: https://iot.bzh/en/publications

mailto:[email protected]

https://iot.bzh/download/public/2019/AMM_Tokyo_0319/AGL-Wayland-Next-Gen-Fulup-IoTbzh-Tokyo-2019.pdf

wlroots - iot.bzh...wlroots : a candidate for next agl hmi framework march-2019 6 why wlroots ? we...

Documents