Stefan Schmidt

Matter is the new kid in town when it comes to IoT protocols. As an application layer protocol based on IPv6 it aims to be the language for IoT devices. With Thread it supports a low-power wireless protocol which allows sleepy devices to operate on a coin cell battery for years and still allow end-to-end connectivity. This talk will look at the technology in Thread and Matter and its open source implementations. Topics include mesh capabilities of Thread, the border router and service discovery.

Based on my OpenThread FOSDEM talk from last year this shows an extended blueprint we created for the Oniro project to provide a connectivity solution for embedded devices running Linux or Zephyr. The Matter specification, together with an open source SDK, got just released in October 2022. As Matter is based on IPv6 it can run over a different number of connectivity solutions. From the start it supports Ethernet, Wi-Fi and Thread. The later being a low-power wireless protocol for a few years already, but without to much traction. With Matter support this might change in 2023 and forward. With border router support in popular devices like Apple Homepod and TV, Google Nest and Wi-Fi or Eero access points the needed technology infrastructure will become available in normal households.

The Thread protocol specifies a low-power IoT mesh network. It offers self-healing, low latency and IPv6 connectivity without a single point of failure. In addition to the lower layer mesh functionality it also offers mesh network management, as well as secure onboarding of headless devices.

OpenThread is an open source project implementing the Thread protocol and its components. The focus of this talk is to demonstrate a Linux based OpenThread border router and Zephyr based mesh nodes. Tight together by a Yocto based build system this talk shows all components you need to have an IPv6 enabled micro-processor on a low-power wireless link. The used power is small enough to allow operating a small sensor for months or years on a coin cell battery in such a scenario. All served by a Linux based border router to allow for internet access and end-to-end IPv6 connectivity.

All of the above is bundled together in an Eclipse Oniro Project blueprint for a transparent IoT gateway.

After the initial years of wireless IoT devices basing their networking on
proprietary protocols, home-grown by one vendor and in-compatibly to anything else, there is a shift to consolidate on IPv6.

In this talk, we will go briefly over 6lowpan as a technology that enabled a lot of these use-cases by providing compression techniques for low-power radio links with limited frame sizes. While its initial development was for IEEE 802.15.4 based networks it was quickly adopted for Bluetooth, NFC, PLC, and others.

This shift allowed the re-use of existing knowledge and concepts of TCP/IPv6 to be adopted into the IoT world, most notably the end-to-end concept, or rather the device-to-cloud concept for IoT. It also resulted in a reduced need for proxies translating between various proprietary networks and your home IP network.

In the future, this hopefully will result in a reduction of product-specific IoT
hubs in a network. An open source blueprint for such a gateway based on All Scenarios OS will be described, together with OpenThread and Matter (former CHIP) as example IPv6 based IoT turnkey solutions.

Breaking hardware boundaries, transcending the classic dichotomy of an OS, this is what OpenHarmony is about. Catering the needs from tiny sensors up to powerful systems, from edge to cloud.

In this presentation Stefan will address questions every FOSS developer will have, when hearing about OpenHarmony for the first time. If you are curious about the architecture, used FOSS projects, or want to know more about contribution guidelines and start picking in the code this talk would be a good start.

Stefan will talk about the multiple-kernel approach, the distributed architecture and layers. He will also explain our public development infrastructure and contribution flows.

On the quest for a cheap and easy way to connect some simple SPI devices to my laptop it was surprising to not find anything suitable available. To connect the SPI device to a Linux laptop over USB in order to develop a SPI kernel driver for it and having a rapid development and test cycle. None of the solutions to access the SPI device over libusb in userspace would work for me. I needed a SPI master controller inside the kernel to work with the variety of devices and kernel subsystems.

On the quest for a cheap and easy way to connect some simple SPI devices to my laptop it was surprising to not find anything suitable available. The idea is neither new nor innovative and surely there must have been something already.

Maybe the use-case was to special. To connect the SPI device to a Linux laptop over USB in order to develop a SPI kernel driver for it and having a rapid development and test cycle. None of the solutions to access the SPI device over libusb in userspace would work for me. I needed a SPI master controller in kernelspace to work with the variety of devices and kernel subsystems.

After some research I settled on the MCP2210 chip. With its cheap and easy to get development boards and an out-of-tree driver as a good start. Maybe it is also something others are looking for and it is surely worth demonstrating and explaining.

Adding support for IEEE 802.15.4 and 6LoWPAN to an embedded Linux board opens up new possibilities to communicate with tiny devices. The mainline kernel supports the wireless protocols to connect such devices to the internet, acting as border router for such networks.

This talk will show how to add the needed transceiver to existing hardware, how to enable and configure the kernel subsystems to use it and how to communicate between Linux and IoT operating systems like RIOT or Contiki.

Adding support for IEEE 802.15.4 and 6LoWPAN to an embedded Linux board opens up new possibilities to communicate with tiny, IoT type of, devices.

Bringing IP connectivity to devices, like sensors, with just a few kilobytes of RAM and limited battery power is an interesting IoT challenge. With the Linux-wpan and 6LoWPAN subsystems we get Linux ready to support the needed wireless standards as well as protocols that connect these tiny devices into the wider internet. To make Linux a practical border router or smart home hub for such networks.

This talk will show how to add the needed transceiver hardware to an existing hardware and how to enable and configure the Linux-wpan and 6LoWPAN mainline subsystems to use it. The demonstration will include setting up the communication between Linux and other popular IoT operating systems like RIOT or Contiki as well.

The Enlightenment window manager and its libraries have for a long time been seen as one of the pieces of software that might never be released. With E17 taking 12 years for its first release there was some truth in this story. Since we have released E18 and E19 and adopted a time based release schedule for our library releases. Enlightenment still runs on its own schedule.

The Enlightenment window manager and its libraries have for a long time been seen as one of the pieces of software that might never be released. With E17 taking 12 years for its first release there was some truth in this story. Since we have released E18 and E19 and adopted a time based release schedule for our library releases. Enlightenment still runs on its own schedule.

The EFL gets a new release roughly every 3 month. Over a year into my role as release manager of EFL and 4 time based releases later it seems to be a good time to look back and let others know about the lessons I learned to get this working.

The talk will touch topics like setting a release schedule within the community, keep track of the status of git master while progressing, motivate people to invest time in stabilization and tools and automation to keep time effort small. It will touch technical as well social topics involved with release management.

Porting a X window manager to the wayland protocol is huge task. This talk describes the journey we took to make it possible to run Enlightenment as a standalone wayland compositor.

While the Enlightenment project has had support for wayland in the EFL toolkit for a long time, the window manager itself always relied on some pieces of X for things like input devices, VT switching, etc.

In this talk we will lay out what problems we faced and also show our solutions. We will talk about the handling of input devices, interaction with DRM, VT handling as well as missing pieces of the wayland protocol for a full desktop experience. For compatibility we are using XWayland with integration into the window manager to launch XWayland if needed.

The end result is Enlightenment running without any X dependencies