What is ilixi?

ilixi is a GPL-licensed lightweight user interface toolkit which aims fast and easy development of interactive graphical applications on embedded Linux systems. ilixi only runs on Linux systems with kernel framebuffer support. Through DirectFB library ilixi can take advantage of any hardware acceleration available. DirectFB X11 driver also allows ilixi applications to be run on top of the X Window desktop, thus allowing applications to be built and tested on the desktop without having to deploy to target platform.

What are the licensing terms?

ilixi is released under the GPLv3 License. This license allows you to modify, copy and redistribute ilixi. You could also charge any price for your services. You must adhere to terms and conditions of this license and make your derived work available to others also under same terms.

What is ilixi's architecture?

ilixi depends on DirectFB, a small-footprint graphics library which provides accelerated graphics operations, input device handling and an integrated windowing system. Besides DirectFB, ilixi also depends on Cairo for 2D vector drawing and Pango for laying out and rendering fonts. The graphics stack of ilixi is shown in the following figure.

Architecture for the ilixi graphics stack

How it works?

ilixi uses a daemon (ilixi_maestro) for controlling visibility modes for applications, and it is usually executed during boot by an init script on target. Maestro creates and manages a fixed size shared memory segment using linux-fusion kernel module. This segment is essentially used for communication with other ilixi applications by maestro. For example, an application sends a foreground mode request to Maestro and waits until it receives back a switch mode command when it is executed. If there is another application already running on foreground, Maestro sends a switch mode command to it first so that it becomes hidden. This means only one user application could become visible at any moment.

ilixi utilises DirectFB surfaces as pixel buffers. When an application becomes visible, ilixi creates a window and acquires a handle to its surface where actual pixel data is stored. Widgets usually create sub-surfaces for drawing their content. These sub-surfaces are just handles to areas inside the window surface with translated origins and clipping areas. Therefore, memory usage is minimised.

An application gets input events from its window inside its main loop. There is a parent-child hierarchy between widgets. Events parsed by user application are forwarded to a widget using this hierarchy. If an event is consumed by a widget, the widget executes its relevant event methods. Users can overload these methods in derived classes. Furthermore, standard widgets provide signals which can be used for connecting user defined methods.

How can I contribute?

There is always room for one more. If you want to contribute to the development in any way you should contact This e-mail address is being protected from spambots. You need JavaScript enabled to view it and let me know your skills and area of interest. I am also interested in seeing ilixi running on different targets so sending photos and videos is much appreciated.