I.MX-6

NXP/Freescale i.MX 6 Information

When working with i.MX processors, you'll most likely encounter a mixture of references to either Freescale (FSL) or to NXP. The reason for this is that Freescale Semiconductor (who created the i.MX series of processors,) was acquired by NXP in 2015. The i.MX 6 was released in 2011.

Much of the information below also applies to the newer i.MX 7 and i.MX 8 processor series.

i.MX Applications Processors

Useful NXP Documents and Discussion Threads about i.MX Processors

Creating i.MX Linux Kernel and Application Builds

Using Yocto (NXP/Freescale supported)

The FSL Community BSP

Yocto Project Quick Build Guide

Using the Linaro Toochains (If not using Yocto)

If you do not want to use Yocto to build your kernel and applications, you can obtain prebuilt toolchains directly from Linaro:

Downloads of the Linaro Toolchain Binaries

Be advised that you will also need to obtain the i.MX BSP files separately, and integrate them into your Linux kernel source tree:

i.MX Board Support Packages

Code Aurora Git Repository

The Code Aurora git repo has an i.MX area that contains a wealth of publicly released i.MX-specific source code (including BSP-integrated Linux kernels).

Code Aurora Git Repo

This is where NXP/Freescale deposits their public releases.

i.MX Support for gStreamer

i.MX forks of the GStreamer project:

GStreamer

GStreamer Base Plugins

GStreamer gst-plugins-good

GStreamer Bad Plugins

i.MX Plugin for GStreamer 1.0

i.MX Support for Qt

Building QT for i.MX 6

How to use qtmultimedia(QML) with Gstreamer 1.0

Qt 5.2 Related Information

Make sure to configure with -device imx6 (which is the same as -device linux-imx6-g+). Without this the build may still succeed but eglfs will not be functional due to not having the Vivante-specific hooks compiled in from qtbase/mkspecs/devices/linux-imx6-g+.

Both linuxfb and eglfs should work. Note however that in 5.2.0 linuxfb is broken. This is corrected in 5.2.1.

Multiple screens

When having multiple displays connected (e.g. the touch LCD panel and HDMI), there are two framebuffer devices: /dev/fb0 and /dev/fb2. Note that fb1 and fb3 are overlays for fb0 and fb2 and are not useful for our purposes here.

Both eglfs and linuxfb uses /dev/fb0 by default. To change this, linuxfb can be configued with the 'fb' parameter: just launch the application with "-platform linuxfb:fb=/dev/fb2".

eglfs has no way to configure this before 5.3.0 so apps using eglfs will always show up on the display belonging to fb0. In 5.3.0 a new environment variable is introduced: QT_QPA_EGLFS_FB. Setting this to /dev/fb2 before launching the app will make the EGL/GLES content show up on the second display. Update: It might be possible to launch eglfs apps on the other display with 5.2 too, by setting FB_FRAMEBUFFER_0 to /dev/fb2.

There is currently no way to display content on multiple displays from the same application. The workaround is to launch two separate applications and use some sort of IPC mechanism to communicate between them.

Screen configuration

Both linuxfb and eglfs will try to query the display dimensions (both physical and pixels) from the framebuffer device. This may not always lead to good looking results. For eglfs the screen size can be set explicitly by setting QT_QPA_EGLFS_WIDTH and QT_QPA_EGLFS_HEIGHT to the desired width/height (in pixels) before launching the application. linuxfb has a size=…x… plugin parameter (for example -platform linuxfb:fb=/dev/fb2:size=1920x1080).

Multiple top-level widgets (QWidget)

linuxfb, which supports sw-rendered widget apps only, has full support for multiple top-level widgets. It is nonetheless advisable to have one widget that covers the entire screen (e.g. showFullScreen()) since the unpainted areas of the screen are not cleared.

Starting with Qt 5.2.0 eglfs also has a certain level of support for multiple top-level widgets. Opening new top-levels, e.g. a menu or a combobox dropdown, will not lead to creating a new native window and EGL surface. Instead, all widget windows are uploaded into textures and composited into a single fullscreen window that is backed by a native window and EGL surface. Before 5.2 having multiple top-levels displayed correctly was not possible at all.

eglfs forces the first top-level to become fullscreen. This is because something has to cover the entire surface, we cannot have "empty" areas. This window is also chosen to be the "root" widget window, into which all other top-level widgets are composited. This works well for applications that have a single main window that exists for the entire lifetime of the application, and all other widgets are either non-top-levels or are created later on. It presents a potential issue for other type of applications, though, and can lead to unexpected results.

OpenGL windows and Quick2 views

As of Qt 5.2.1 eglfs supports a single, fullscreen OpenGL-based QWIndow or QQuickWindow or QGLWidget. Mixing these with QWidget content is not supported and will typically terminate the application with the message "EGLFS: OpenGL windows cannot be mixed with others.".

Input

linuxfb and eglfs follow different paths here: eglfs has the evdev input handling code built-in, while linuxfb relies on the traditional -plugin command-line parameters.

To enable keyboard, mouse, touch or (Wacom) tablet support with linuxfb, pass -plugin evdevkeyboard, -plugin evdevmouse, -plugin evdevtouch or -plugin evdevtablet on the command-line. Each of these can take a device node parameter, e.g. -plugin evdevmouse:/dev/event1, in case the automatic device discovery (based either on libudev or a walkthrough of /dev/input/event*) is not functional.

For eglfs, these parameters, like the device node name, can be set in the environment variables QT_QPA_EVDEV_MOUSE_PARAMETERS, QT_QPA_EVDEV_KEYBOARD_PARAMETERS and QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS. Additionally, starting from 5.3.0 the built-in input handlers can be disabled by setting QT_QPA_EGLFS_DISABLE_INPUT to 1. This allows for example to use the tslib input plugin, in case the evdev one is not suitable.

Touch

Unlike earlier versions, starting from 5.2.0 the evdev touch handler is able to recognize and use the touchscreen out of the box, hence there is usually no need to fall back to tslib. Just launching the application with -platform eglfs should be enough.

On some touch screens the coordinates will need to be rotated. This can be enabled by setting QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS to rotate=180.

Mouse cursor and hotplugging

The mouse cursor will show up whenever QT_QPA_(EGLFS|FB)_HIDECURSOR is not set and Qt's libudev-based device discovery reports that at least one mouse is available. When the libudev support is not present, the mouse cursor will always show up unless explicitly disabled via the environment variable.

Hotplugging is supported, but only if Qt was configured with libudev support (it is picked up automatically during configure if the development headers are present). This allows connecting or disconnecting an input device while the application is running, however the mouse cursor does not yet support this so, for instance, disconnecting the mouse while the application is running will leave the mouse cursor visible. This is planned to be addressed in the near future.

Terminal input

Starting from Qt 5.3.0 the Embedded Linux platforms (eglfs, linuxfb, kms) are disabling the terminal keyboard on application startup. This prevents the fairly annoying behavior of letting keystrokes go to the terminal underneath the application. If the old behavior needs to be restored for some reason, set the environment variable QT_QPA_ENABLE_TERMINAL_KEYBOARD to 1.