Archive

Most Kodi users are now running Kodi 17.x Krypton that was initially released in February 2017, with the latest point version being Kodi 17.6. At the time of Krypton release, the developers had also started working on Kodi 18 “Leia” which should now be in “alpha”, and the stable release may only be a few months away although Kodi developers do not provide an ETA.

What they did provide however – via Martijn Kaijser at FOSDEM 2018 – is a progress report for Kodi 18 “Leia”, as well as some insights into Kodi 19 whose development has just started.

Click to Enlarge

Kodi 18 has gone through a lot of cleanup with the code upgraded to C++11 standard, duplicate code and obsolete libraries removed, dropped unmaintained feature, and so on. They also moved non-core features such as audio encoders and decoders, PVR, picture decoding, etc… to external plugins. This work resulted into 299,476 deleted lines of codes, and 387,205 added lines of codes in Kodi v18 alpha.

Some of the key developments and new features you can expect in Kodi 18 include:

XBOX One support with Microsoft’s help

Improvements to the core VideoPlayer with easier to maintain, more portable and efficient code, support for DRM protected streams (e.g. Widevine), and potentially future support for PiP, headless mode, and transcoder mode.

As mentioned in the introduction, work on Kodi 19 “Mxxxxx” has also started, and one of the changes is the drop of support for Python 2 add-ons so every add-on will have to move to Python 3. Watch the video for the full picture.

We first covered the Alliance for Open Media’s AV1 video codec in summer 2016, as an open source, royalty-free video codec aiming to replace VP9, and compete or even surpass H.265 capabilities. At the time, everything was pretty new, and when I tried the open source implementation encoding was really slow.

Since then, AV1 has gained momentum with for example Apple, Facebook, and IBM recently joining AOMedia, and Mozilla adding HTML5 AV1 video support to Firefox Nightly builds at the end of last year. I was able to play a 720p video @ 800 Kbps almost smoothly in my computer based on AMD FX8350 processor. Many companies want AV1 to succeed since they may not be willing to pay MPEG LA license fee for H.265 and future MPEG codecs (e.g. H.266), and there indeed seems to be issues with the currently MPEG licensing business model.

However, AV1 is not quite ready yet, although it’s getting there as you’ll find out from Mozilla’s Timothy B. Terriberry presentation at FOSDEM 2018 which provides a very technical update to the progress of AV1 codec support in the video below. If you don’t have background in video encoding / decoding, I propose you skip the video altogether, as it’s filled with terminology and acronyms that most people won’t understand. To illustrate the point, some of the subjects covered include:

Adaptive Multisymbol Entropy Coding

Transforms (with 64-point transforms added)

Coefficient Coding

Intra Block Copy

Motion Vector Coding

“Extended” Skip Mode

etc..

Specific times to still work on with regards to the specifications:

Fix remaining problems with TXMG

Final details of high-level syntax

Last-minute changes to MV prediction

Fix all of the bugs

IPR analysis

You could also read AV1 specifications for the full details (after building the docs…). There were still a few tidbits easy to understand. First, independent tests – see chart on top – have shown AV1 to offer lower bitrate than H.265 and VP9 implementations in June 2017, and now the results are said to look even better, with a target of 30% better compression compared to H.265. It will also take a while before you get an AV1 camera, as AV1 encoding is currently 2500 to 3000 slower than VP9, but they are working on making it faster.

That’s fine if you are happy with MCU class boards, but RISC-V is getting into more powerful processors, and recently got initial support o Linux 4.15, so it should come as no surprise the company has now launched HiFive Unleashed, the first RISC-V-based, Linux-capable development board.

The board is mostly for developers and enthusiasts and currently the main use cases including building a RISC-V computer, adding features to Linux, or port packages to a Linux distribution. It’s unlikely to be a plug and play board suitable for anybody, at least at the beginning.

The company simultaneously unveiled & showcased the board at FOSDEM 2018 (See embedded video below), and launched it on CrowdSupply with a symbolic $1 funding goal. The downside is that as with most new technologies it’s pretty expensive at first, and you’d have to pledge $999 to get the board shipped at the end of June 2018, or $1,250 to get one of the first 75 boards in March/April 2018. Shipping is free to the US, but adds another $40 to the rest of the world. More details may eventually be available in the product page.

Earlier today I wrote about FOSDEM 2018 schedule, and among the various talks I selected for my virtual schedule was “How to build an autonomous robot for less than 2K€”. Some excerpt from the abstract including a short description of the project, and its “open-sourceness”:

PULUrobot solves the autonomous mobile robotics complexity issue without expensive parts, without compromise. By fearless integration and from-scratch design, our platform can do SLAM, avoid obstacles, feed itself, and carry payload over 100kg, for less than 2,000 EUR.

Application ecosystem can be born around it, as we offer a ready-made Open Source (GPLv2) solution in a tightly coupled HW-SW codesign.

So I decided to have a closer at this project, which can be used as a robot maid/helper of sort, and other applications.

The robot was made by a brand new (July 2017) startup called Pulu Robotics Oy and based in Finland. They have three models:

Pulurobot S – Small version capable of carrying up to 100 kg

Pulurobot M – Mid-sized version capable of carrying up to 130 kg

Pulurobot L – Larger model designed for factory floors and capable of carrying up to 300 kg

S & M model are similar in design, except the latter is larger, while the L model appears to be in a earlier stage of development. Pulurobot M comes with the most documentation, so that’s the model we’ll look at in details with the specs of the sixth revision of the prototype:

The company is however working on improvements to lower the cost / improve functionality, and will replace expensive off-the-shelf vision parts with their own 3D vision system supporting 360-degree x 40-degree true 3D vision with 100 000 distance measurement points, 5 to 10 fps. They’ll also add the ability for the robot to find any standard wall outlet to charge itself automatically, and redesign the chassis for lower cost, high-quality mass manufacturing.

Click to Enlarge

While the project is supposed to be open source, they have not released anything yet, but maybe we’ll find out more once FOSDEM is underway. We just know they decided not to use ROS. Applications for such robots include delivery boy, cleaner trolley, recycle bin, coffee trolley, night guard, telepresence, and more.

While development is still in progress, they’ve already sold 25 units they plan(ed) to deliver this month. It’s unclear whether the sub 2,000 Euros price is for the S or M model, as I don’t know the price for such robots. Pulurobot M availability is planned for Spring 2018. More details can be found on the company’s website. You can also watch a demo of Pulurobot M prototype version 4 carrying 58 kg of weights.

FOSDEM (Free and Open Source Software Developers’ European Meeting) occurs every year on the first week-end of February, where developers meet for two days discussing about open source software projects. FOSDEM 2018 will take place on February 3-4 this year with 652 speakers, 684 events, and 57 tracks, an increase over last year 608 speakers, 653 events, and 54 tracks. There will be 8 main tracks namely: Community, History, Miscellaneous, Performance, Python, Security and Encryption, Space, and Global Diversity CFP Day.

Saturday 3, 2018

09:50 – 10:15 – Turning On the Lights with Home Assistant and MQTT by Leon Anavi

In this presentation you will learn the exact steps for using MQTT JSON Light component of the open source home automation platform Home Assistant for controlling lights through the machine-to-machine protocol MQTT. Practical examples for low cost devices combining together open source hardware with free and open source software will be revealed. The presentation will provide general overview of Home Assistant, details about the software integration of new devices to it through the MQTT protocol and open source MQTT brokers such as Mosquitto. We will do a code review of an open source Linux daemon application for Raspberry Pi, written in the C programming language and based on the Paho library for MQTT client and the piGPIO library used for pulse-width modulation (PWM) control of a RGB LED strip. We will compare it to an implementation of the same features for the microcontroller with WiFi ESP8266 written as a sketch for the Arduino environment. Furthermore, the presentation will include details about reading data from various sensors and their setup in Home Assistant.

When looking at home automation solutions available in the market nowadays, one of the most important and expected features is to be able to control your home automation installation from anywhere in the world using a smartphone app. A vendor of a low-cost home automation solution requested us to add such a feature to their existing IP gateway product, which only allowed for users to control their home automation system with their smartphone while they are connected to their local network at home. We were asked to make it possible to let the smartphone app connect to the IP gateway from anywhere in the world. This vendor’s IP gateway hard- and software was based on the Mbed platform, so they needed a solution that could fit within Mbed.

Since our client wanted an open-source, secure, low-cost and easy to set up solution that he could host himself, we opted to go for Pagekite. However, since Mbed does not support OpenSSL, Linux sockets or libev, the existing libpagekite C library was not an option to start from. So we started to implement a Mbed flavour of the library ourselves, and decided to make it open-source

The STM8 is a popular 8-bit architecture by ST Microelectronics commonly used in household electronics, automotive application and industrial controls. For quite a while there were no free tools, and the irregular architecture makes it hard to support in GCC or LLVM. In recent years free tools for it started to appear and now form a free toolchain that surpassed preexisting non-free ones. The most important part is the Small Device C Compiler (SDCC). New tree-decomposition-based algorithms from recent compiler research have been implemented in SDCC, including a new register allocator particularly suited to irregular architectures with few registers. SDCC quickly surpassed the non-free compiler in standard compliance and OS support and generates substantially faster integer code. Programs can be flashed by stcgal (via a serial link on STM8 devices that have a bootloader) and stm8flash (via the SWIM interface of ST-LINK hardware). OpenOCD and GDB allow on-target debugging via the ST-LINK. IDEs complete the development environment. However, stcgal still needs non-free binary blobs for use with some devices and the ST-LINK has non-free firmware. SDCC still falls short in floating-point performance. While there are some ports of free RTOSes that use the free toolchain for the STM8, more would be desirable.

The conference will describe how to use PREEMPT_RT and Xenomai with Yocto build system – building image and SDK – developing simple application – testing performances.

Using RT extension with Yocto is not that easy because linux-yocto-rt kernel is not usable on main embedded target such as ARM (as it works on QEMU target only). Using Xenomai is much more complicated as it needs several steps (patching the kernel, installing user-space libraries, building an extended SDK).

During the conference we will describe how to build a Yocto Linux image using PREEMPT_RT for famous boards such as Pi 3 or BeagleBone Black.

Some Xenomai support is provided by meta-eldk from DENX but it supports only Xenomai 2.6. We will describe meta-xenomai as we maintain it for our customers (available on GitHub). That new meta-xenomai layer is based on Xenomai 3.x and very recent kernel.

Then we will explain how to build a simple Xenomai application based on a periodic task. Finally we will compare performances of both extension (PREEMPT_RT and Xenomai) on same hardware.

12:00 – 13:00 – How to keep your embedded Linux up and running? by Krzysztof Opasiak

Userspace software is imperfect and we all know about this. Running it for 5 minutes seems to be easy but what about days or weeks? This problem already gave server guys a lot of sleepless nights. Nowadays also IoT and embedded Linux world is facing very the same problem. Unfortunately solutions known from server world (Nagios and friends) usually cannot be directly applied.

During this talk, Krzysztof will discuss problems related to monitoring and “healing” embedded Linux distribution. First, most common server approaches will be described. After that, Krzysztof will try to identify key problems of applying this solution to embedded platform. Then Krzysztof will introduce faultd – small but extendable daemon for system monitoring and CPR;). How to use it? What can it do? What are the advantages and disadvantages? All those questions should be answered in this part. Last part is going to be a discussion on a presented idea and experience sharing.

Whether you’re looking at the constrained devices that make for the “things” of the IoT, gateways that connect them to the Internet, or backend servers, there’s a lot that one needs to build for creating end-to-end IoT solutions. In this session, we will look at the typical software features that are specific to IoT, and see what’s available in the open source ecosystem (and more specifically Eclipse IoT) to implement them. A live demo of the Eclipse IoT Open Testbed for Asset Tracking will allow the audience to see some of the projects (such as Eclipse Kura, or Eclipse Kapua) in action.

The Tizen software platform has been designed to target consumer electronics, since 2013 the OS is powering many products on the market (from smart watches to TVs, cameras or even white goods). Even if this Linux based platform is very flexible, the Linux kernel has minimum size requirements, so Tizen can’t be deployed on constrained devices (ubiquitous microcontrollers).

To also target low end devices part of Tizen’s technology was rebased on NuttX RTOS. Seamless connectivity is still provided by IoTivity, while a new IoT features are becoming available to application developers too, this whole stack is Tizen:RT!

This presentation will give an overview of Tizen ecosystem, and explain how to get started with Tizen:RT using QEmu, SDK, finally an IoT scenario will be demonstrated on trusted system on module ARTIK 055s.

It is expected that in the next years billions of devices will be connected to the Internet of things (IoT). Many of them will interact with cloud-based solutions to provide additional services on the devices or in the web. To bring IoT to the next level technologies for supporting cross-domain/cross-vendor solutions are needed. There is already a lot FOSS available to provide a technological base for building IoT solutions (e.g. Kubernetes). However, on top of it, software is needed for the connectivity challenges, support of domain-specific protocols, large scale messaging and device management and integration with existing infrastructure. Eclipse IoT aims to address these needs and provide an FOSS IoT framework that makes IoT development fast and simple. In the last year Eclipse IoT has made a lot of progress and the underlying environment in cloud technology has seen a lot of changes. In addition, upcoming challenges like automated driving and connected vehicles have resulted in new projects for better support for the automotive domain. This talk gives you an overview of major Eclipse IoT projects and illustrates its capabilities with a short demo.

15:05 15:30 – IoT.js – A JavaScript platform for the Internet of Things by Ziran Sun

IoT.js is a JavaScript platform that aims to provide inter-operable services for IoT world. Powered by JerryScript, an ultra-lightweight modular JavaScript engine, the platform is designed to bring the success of Node.js to constrained IoT devices. To address interoperability, IoT.js has provided a Node.js friendly architecture and comes with a subset of Node.js APIs. Since Samsung OSG first presented IoT.js in FOSDEM in 2016, the platform has been through a rapid growth in last couple of years. With a lot active high-quality contributions from the IoT.js and JerryScript open source community, IoT.js has released version 1.0 in July 2017 which presented a rich set of features, hardware and tool supports for developers. In this talk, we are looking at recent developments in IoT.js and share our vision for future plans. The talk is supported by a demo of iot.js running on constrained device seamlessly connects to node.js for third party cloud access.

15:45 – 16:10 – The dark side of Internet of things by Dipesh Monga

With the advent of the Internet of things, monitoring and controlling everything such as coffee maker, lights, TV, Fridge,etc. over the Internet has become a child’s play. But are we really making our lives simpler or diving ourselves in a vast ocean which is getting deeper and deeper? In today’s world where the security of our data of a major concern, the number of websites are always tracking what we search for, what we watch, our location and now when things are limited to only data, adding another dimension i.e. physical entities is really a big question.

From this talk audience will take away an understanding of the privacy concerns related to IoT, and how they may be putting their personal information at risk by connecting my physical entities to the Internet. Is it really safe to connect things to the Internet?

Over the past three years, the growing zoo of Open Source update frameworks made updating an embedded Linux system much easier. But, the availability of a robust update tool solves only one step in the complex chain from a software artifact to an updated and working system on your devices.

Starting with a modern system consisting of a recent bootloader, kernel, init system and update tool, this talk ventures beyond the basic and already solved topics of A/B redundancy, atomicity, or simple update verification.

Enrico will present strategies for creating a robust update chain from automated testing up to full rollout management and show how to solve these challenges with recent Open Source software such as barebox, RAUC, systemd, hawkBit, casync and labgrid. You will learn how to deal with more modular and complex system setups, restricted systems, error recovery, product variants, resigning for deployment, updating the bootloader itself and interaction with verified boot.

We’re gonna look at multi-tasking on small Cortex-M class MCUs like the ARM Cortex-M0. After a brief general overview of the Cortex-M0 programming model, exception handling and other basics required, we’ll start our deep-dive into one specific implementation in the Chromium-EC firmware. We’ll look at startup code, how tasks are implemented, how to deal with priorities and peripheral interrupts.

The Chromium-EC firmware is a little (RT)OS that runs (mostly) on ARM cores of the Cortex-M class (M0/M3/M4), and powers Google’s Chromebooks as well as other devices (Project Sulfur SDR). It’s permissive license makes it attractive for (ab)use in other projects, since Kernel and U-Boot integration are already existing.

18:00 – 18:30 – The Chromium project’s Way to Wayland by Maksim Sisov

Wayland is the most advanced X11-alternative display protocol, shipping today in a variety of desktop and embedded environments. Although the Chromium browser on Linux still defaults to use the X11 window system, there have been efforts to port it to different environments.

This effort happens in various fronts, including the development and stabilization of Ozone, an abstraction layer for graphics and input events, and the transitioning of some ChromeOS-oriented solutions to Linux, for example Chromium’s new “UI service”.

Igalia has been actively contributing to this multi organizational collaboration, aiming at getting a full fledged Chromium browser running natively on Wayland. The work happens on Chromium’s upstream repository so that the greater Chromium community can benefit from it.

18:30 19:00 – GStreamer for tiny devices by Olivier Crête

GStreamer is a complete Open Source multimedia framework, and it includes hundreds of plugins, including modern formats like DASH, HLS or the first ever RTSP 2.0 implementation. The whole framework is almost 150MB on my computer, but what if you only have 5 megs of flash available? Is it a viable choice? Yes it is, and I will show you how.

Starting with simple tricks like only including the necessary plugins, all the way to statically compiling only the functions that are actually used to produce the smaller possible footprint.

Sunday 4, 2018

09:30 10:00 – Programming UEFI for dummies, what I have learned while tweaking FreePascal to output UEFI binaries by Olivier Coursière

With the upcoming end of legacy mode in UEFI firmware on PCs, every alternative and hobbyist operating systems, bare metal programmers and wannabe OS developers will have to deal with UEFI on modern hardware. After presenting the binary format of UEFI applications, I will focus on the use of UEFI APIs through EFI system table and UEFI protocols so you can get started.

Rustyarm is a project in the Physical Computing group at the University of West of England looking at application of Rust on embedded micro controllers. UWE Sense is a new hardware and software platform for IoT, build with ARM micro controllers, Bluetooth LE and LoRaWAN, which runs a software stack written completely in Rust. While UWE Sense is a close to the metal implementation, UWE Audio, a new hardware platform for studying high performance audio using ARM micro controllers, uses Rust to implement a monadic reactive graph, supporting both an offline compiler and and Embedded DSL. UWE Audio uses safe Rust, for example, describing domain clock as generic associated types, providing both compile time guarantees that multiple streams will not be incorrectly sequenced at different sample rates, and the ability to dynamically compile for different parts of the system.

In this talk I will provide a high-level overview of the Rustyarm project, including how using Rust has made this project interesting, but also enabled providing guarantees with respect to the audio scheduler, for example. However, Rust has some short comings in the embedded domain and we provide details on some of these and what we and the wider community are doing to address them. As an example of Rust’s application in the embedded domain we present early work on UWE Audio and hardware and software platform for building digital music instruments, which as already noted is programmed with solely in Rust.

10:30 – 11:00 – How to build an autonomous robot for less than 2K€ by Miika Oja (PuluMan)

Telepresence, Delivery Boy, Security and Follow Me in one PULUrobot. PULUrobot solves the autonomous mobile robotics complexity issue without expensive parts, without compromise. By fearless integration and from-scratch design, our platform can do SLAM, avoid obstacles, feed itself, and carry payload over 100kg, for less than 2000EUR.

Application ecosystem can be born around it, as we offer a ready-made Open Source (GPLv2) solution in a tightly coupled HW-SW codesign. Pulu Robotics Oy was founded in July, 2017, in Finland, to solve our own needs, with an efficient team of three. No one had prior knowledge on robotics.

By studying the market and other startups, we realized the common mistake is to use “robotic modules” as building blocks. They are highly expensive, provide little bang for buck, often are inefficient, and require complex software middleware (such as ROS) as the glue inbetween. Due to our combined background in mechanical, electrical, software and manufacturing design, we took the approach of designing as much as possible by ourselves.

We are now selling the very first generation of robots for the early adopters, hoping to give a kick start to the open source community as soon as possible. Behind the curtains, we are focusing on the development of our next 3D sensor system, which will replace the current scanning 2D lidar with a 360×90 degree full 3D distance data, and do it for the same price we currently pay for the Scanse 2D lidar used in the first small-scale production batch.

11:00 – 11:30 – … like real computers! Making distributions work on single board computers by Andre Przywara

Installing an operating system on single board computers (SBCs or “Fruit-Pis”) is very board specific and requires a lot of hand holding. If at all, standard distributions support only a small number of them explicitly, which leads to a lot of board specific images and distributions. This talk will show how this situation can be improved, to the point where off-the-shelf Linux (or BSD) distributions can be installed on those boards, without those distros knowing about each and every one of them. Key ingredients are standardized firmware interfaces like UEFI, stable device trees and on-board memory like SPI flash. This should make using ARM based SBCs as easy as using (x86) PCs today: like “real computers”. On top of this, ways to simplify and speed up mainline Linux kernel support are explored. Enabling kernel support for new SoCs usually takes a while, especially if the effort is driven by the community. This delays distribution support, up to a point where a certain SoC or board might become slightly dated when it’s finally supported. Using more device tree features and less hardcoded kernel data would reduce the code required to support new SoCs, ideally reaching a point where new SoCs could be at least booted with existing (distribution!) kernels, just by providing the proper device tree blob. This talk describes the idea and gives an example by looking at what can be done on Allwinner SoCs.

11:30 – 12:00 – Booting it successfully for the first time with mainline by Enric Balletbo Serra

While things have gotten a lot better, new hardware bring-up sometimes still feels like pulling teeth. With the right methodology, tools and techniques, a significant amount of time, energy (and sanity) can be saved while enabling a new board to run Linux. In this talk, we’ll discuss the phased process involved in new board bring-up and the challenges it can pose, from reviewing initial schematic design to the successful upstreaming of any necessary bootloader and kernel patches. We’ll also provide some examples of the process based on a board that was recently made compatible with mainline.

This talk aims at an introduction to using the Industrial IO(IIO) framework to initialize sensors and acquire data to feed to a Software in the Loop (SITL) interface of drone software such as iNav/Cleanflight. Most flight controller boards are based on low power ARM microcontrollers and the flight controller software is not usually based on Linux. However, with the availability of increasingly powerful boards with onboard sensors and multicore processors, using a Linux based flight controller software can be used to our advantage. Experimenting with onboard devices and scheduling algorithms can lead to interesting applications with minimal porting overhead to new architectures.

The talk starts with a quick overview of the IIO framework and using it to initialize the drivers for the onboard sensors of the Intel Aero platform, a x86 based flight controller board. Although, not tied to the Aero board in any way, this talk will use this board as an example to describe the onboard sensors and acquire data from them to successfully run a minimal SITL instance. The talk aims to explore how the IIO framework exposes data from these sensors and how users can utilize these interfaces followed by a demo of the setup.

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.

This presentation is a practical guide to implementing U-Boot port to a new system from scratch. U-Boot is the de-facto standard bootloader for embedded systems, there is plenty of U-Boot ports, yet vast majority of those are implemented in sub-optimal way. This talk first explains the U-Boot internals, the driver model (DM) and it’s interaction with device tree (DT), as understanding these is vital to understanding the implementation of core subsystems. The core subsystems are explained in detail afterward to allow developers implement drivers the intended way without hacks and workarounds. Unfortunately, not all systems have plenty of resources, but U-Boot caters for those as well. The final part of the talk discusses the U-Boot SPL, the preloader which initializes the hardware, DRAM and starts U-Boot and finer parts of this procedure, which tends to have plenty of pitfalls.

Image capture is one of the most broad and complex fields of today’s computing applications. Capturing and displaying images with an embedded platform poses additional challenges, introduced by the rapidly increasing complexity of dedicated hardware blocks often found on modern Systems On Chip designed for mobile and industrial computing. Using real world examples of image sensors, connection buses and processing blocks this presentation provides an overview of current industry standard technologies with an introduction to Video4Linux2 kernel framework for driver development and its userspace APIs.

Since linux 4.8 the GPIO sysfs interface is deprecated. Due to its many drawbacks and bad design decisions a new user space interface has been implemented in the form of the GPIO character device which is now the preferred method of interaction with GPIOs which can’t otherwise be serviced by a kernel driver. The character device brings in many new interesting features such as: polling for line events, finding GPIO chips and lines by name, changing & reading the values of multiple lines with a single ioctl (one context switch) and many more. In this presentation, Bartosz will showcase the new features of the GPIO UAPI, discuss the current state of libgpiod (user space tools for using the character device) and tell you why it’s beneficial to switch to the new interface.

FOSDEM 2018 will take place at the ULB Solbosch Campus in Brussels, Belgium, attendance is free of charge, and no registration is required.