Search by Tags

Display Output, Resolution and Timings (Linux)

 

Compare with Revision




Subscribe for this article updates

A monitor or embedded display requires a certain display mode to operate correctly. Monitors often support various modes whereas embedded displays are usually a bit more picky. Display modes specify a combination of parameters, not only the display resolution but also refresh rate, colour depth and signal timings. On personal computers, the monitor passes the supported modes to the connected host system (Extended display identification data, EDID, transmitted through the Display Data Channel, DDC). The operating system presents the available modes to the user, typically as a list of available resolutions since the resolution is the parameter of primary interest. Embedded displays often do not have a dedicated DDC (e.g. parallel RGB, LVDS or similar display links), and therefore the system needs to be told what exact display resolution and timings have to be supplied.

Embedded displays without DDC channel (parallel RGB/LVDS) use a fixed mode provided by the driver, this can be either: - Display modes provided through machine specific code (arch/arm/mach..., e.g. Tegra) - Display modes as part of the device tree (display-timings node, e.g. i.MX 6/Vybrid fbdev driver) - Display modes provided through modedb entry or calculated video modes (e.g. Tegra/i.MX 6/Vybrid fbdev driver) - Display modes from a display driver (used for kernel mode settings (KMS) e.g. from panel-simple.c, e.g. Vybrid DRM driver)

If there are multiple display modes available (either through EDID/DDC or multiple display modes specified for an embedded display), the system allows to choose between them. In Linux, various subsystems deal with display modes. Depending on the display controller and driver used, different ways of configuring the mode are available. Available interfaces are for instance:

  • fbdev interface (fbset utility or kernel argument, internal modedb)
  • KMS interface (Kernel Mode Setting, part of the Direct Rendering Manager (DRM) interface, kernel argument, through X.org/RandR using modesetting driver)
  • Classic X modes (using xorg.conf modelines, X driver specific backend)
  • X modes through RandR extensions (RandR: Resize and Rotate Extension, implemented by libXrandr/xrandr utility, X driver specific backend)
  • Wayland Compositors (the wayland protocol does not deal with modes, the compositor handles modes directly. E.g. the reference compositor weston uses the KMS interface)

Which mode setting interfaces are available and how to configure the timings for embedded display depends on the display controller driver. Toradex modules use different display controllers and therefore a different driver. Additionally, newer BSP versions might provide different drivers for the same controller. Refer to the module sections below on what implementations are available and how to use them.

i.MX 6 based modules

The iMX6 based modules use the fbdev interface for mode setting and output configuration. The Apalis iMX6 can have up to four video outputs with corresponding frambuffers while the Colibri iMX6 can have two.

The Vivante X driver can only make use of the first framebuffer /dev/fb0 while the others can be used through the fbdev framebuffer interface.

The assignment of the possible display outputs to the framebuffers (scan-out engines) and their timing configuration can be done either on the Kernel command line or from within the device tree. The command line settings take precedence over the device tree.

The first and third video output have an additional overlay framebuffer configured.

Video Output IPU Core Framebuffer boot name Framebuffer Device Overlay Framebuffer Device
First IPU1 mxcfb0 /dev/fb0 /dev/fb1
Second IPU1 mxcfb1 /dev/fb2
Third (Apalis only) IPU2 mxcfb2 /dev/fb3 /dev/fb4
Fourth (Apalis only) IPU2 mxcfb3 /dev/fb5

i.MX 6 Framebuffer Boot Configuration

The command line parameter takes the following form, use "off" for unused framebuffers:

"video=mxcfb<number>:dev=<Output>,<Mode Specifier>,if=<Output Format>,[bpp=<Framebuffer Depth>]"

e.g.:

video=mxcfb0:dev=lcd,EDT-WVGA,if=RGB24
video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24
video=mxcfb1:off

<Output> can be one of the following options

Output Device Output Output Format
Parallel RGB lcd Apalis: RGB24, Colibri: RGB666
HDMI hdmi RGB24
VGA (Apalis only) vdac RGB565
LVDS (Apalis only) ldb depends on attached display

Note: The LVDS and VGA connectors available on the Colibri Evaluation Board, as well as the LVDS and the analog part of the DVI-I connector of the Colibri Iris are converted outputs from the Parallel RGB signals of the Colibri module. Therefore use the Output specifier "lcd" to specify their settings.

<Mode Specifier> can be a named mode from the kernel sources (e.g. EDT-WVGA) or a calculated modes using the VESA CVT formula (e.g. 1920x1080M@60). For the calculated modes refer to: http://git.toradex.com/cgit/linux-toradex.git/tree/Documentation/fb/modedb.txt?h=toradex_imx_3.14.28_1.0.0_ga.

<Framebuffer Depth> if omitted is set to 16 bits per pixel in our device trees. Use bpp=32 if you want a higher colour depth. Note that while bpp=24 is legal some accelerated drivers stop working correctly (e.g. the OpenGL ES driver with framebuffer backend).

The following sets up the U-Boot environment variable "vidargs" which becomes part of the Kernel command line:

setenv vidargs 'mxc_hdmi.only_cea=1 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24
video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M'
saveenv

Some tested mode specifiers are:

Mode Specifier Description
EDT-VGA EDT 5.7" TFT VGA
640x480M@60 VGA, default mode, also for EDT 5.7" TFT VGA
EDT-WVGA EDT 7.0" TFT WVGA
800x480M@60 EDT 7.0" TFT WVGA
FusionF07A Fusion Multi-Touch Display 7”
800x600M@60 SVGA
FusionF10A Fusion Multi-Touch Display 10”
1024x600M@60 Fusion Multi-Touch Display 10”
1024x768M@60 XGA
1280x720M@60 720p (HD)
1920x1080M@60 1080p (full HD)

Note: Some named mode specifiers are only available in the latest Kernel.

i.MX 6 HDMI Output

For the HDMI Output the i.MX 6 reads EDID information from an attached monitor which provides the monitor's capabilities. The i.MX 6 then chooses a video mode which the monitor is capable of displaying and is closest to the one requested on the command line.

The additional command line parameter "mxc_hdmi.only_cea=1" limits the modes considered valid to CEA defined ones, e.g. 480p, 720p, 1080p. Some monitors do only work with this parameter set while others do only work without the parameter, however most monitors do work either way.

i.MX 6 LVDS Output (Apalis only)

The i.MX6 has a single/dual channel LVDS display interface which is accessible on the Apalis iMX6 and can be used in different configurations.

Kernel 3.10.17
Resolution and configuration can be done with the video command line parameter. Channel assignment must be done with an additional command line parameter ldb (e.g. ldb=sin0). For available values and their meaning refer to: http://git.toradex.com/cgit/linux-toradex.git/tree/Documentation/devicetree/bindings/fb/fsl_ipuv3_fb.txt?h=toradex_imx_3.10.17_1.0.0_ga

Kernel 3.14.28
The ldb driver which controls the LVDS output got heavily overhauled and the configuration from the command line is currently not possible. Instead the device tree is used for most of the settings.

Check the relevant framebuffer node's property 'interface_pix_fmt' and the ldb node: http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/boot/dts/imx6qdl-apalis.dtsi?h=toradex_imx_3.14.28_1.0.0_ga

Activate the driver from the command line by providing vidargs with:

video=mxcfb0:dev=ldb

or with a 32 bit framebuffer:

video=mxcfb0:dev=ldb,bpp=32

Kernel 3.14.52, 4.1.x

We added the possibility to set the display resolution from the kernel command line. If no resolution is given on the command line the setting from the device tree is taken.

Channel and color mapping configuration needs to be done in the device-tree.

i.MX6 Multiple Outputs

If multiple framebuffers get configured there might be issues in setting up the pixelclocks of the individual framebuffers. Clock settings of already configured framebuffers might get changed by subsequently configured framebuffers. Usually this is only an issue when using different timings on the different outputs. In such a case one might have to tweak the framebuffer timings or adapt the kernel sources to use different clock parents for the different framebuffers. The clock tree in /sys/kernel/debug/clk/clk_summary can be used to debug the issue.

The following sets up four outputs, each with a resolution of 640x480.

setenv vidargs video=mxcfb0:dev=lcd,640x480M@60,if=RGB24 video=mxcfb1:dev=vdac,640x480M@60,if=RGB565 
video=mxcfb2:dev=hdmi,640x480M@60,if=RGB24 video=mxcfb3:dev=ldb,640x480M@60,if=RGB666 ldb=sin0 fbmem=32M

i.MX 7 based modules

The Colibri iMX7 makes use of the eLCDIF display controller. Our current BSP provides the fbdev based driver mxsfb (drivers/video/fbdev/mxsfb.c).

fbdev driver mxsfb

Description Output 1
Framebuffer boot name mxsfb
Framebuffer device /dev/fb0
X-Server driver fbdev
X-Server output name default
Connector on EvalBoard LVDS/RGB/VGA
Connector on Iris DVI-A
Supports EDID (Software) No

The driver currently does not support specifying display resolutions via kernel parameter (modedb or calculated via timing formulas).

To support a specific display we recommend to use the device tree to specify the exact display resolution and timings while also specifying the native-mode property. See the carrier board device tree file arch/arm/boot/dts/imx7-colibri-eval-v3.dtsi:

&lcdif {
    display = <&display0>;
    status = "okay";

    display0: lcd-display {
        bits-per-pixel = <16>;
        bus-width = <18>;

        display-timings {
            native-mode = <&timing_vga>;

            /* Standard VGA timing */
            timing_vga: 640x480 {
                clock-frequency = <25175000>;
                hactive = <640>;
                vactive = <480>;
                hback-porch = <40>;
                hfront-porch = <24>;
                vback-porch = <32>;
                vfront-porch = <11>;
                hsync-len = <96>;
                vsync-len = <2>;

                de-active = <1>;
                hsync-active = <0>;
                vsync-active = <0>;
                pixelclk-active = <0>;
            };
...

Tegra 2 & 3 based module

The Tegra 2 (Colibri T20) and Tegra 3 (Colibri T30/Apalis T30) based modules provide two display outputs.

The X-Server driver labels the outputs differently than the framebuffer:

Description Output 1 Output 2
Framebuffer boot name tegrafb0 tegrafb1
Framebuffer device /dev/fb0 /dev/fb1
X-Server name LVDS-1 HDMI-1
Connector on EvalBoard LVDS/RGB/VGA DVI-D
Connector on Iris DVI-A DVI-D
Supports EDID (Software) No Yes

The Tegra X driver provides (partial) support for the X RandR extension. On the DVI/HDMI output, the Tegra driver supports reading display modes from EDID via the Display Data Channel (DDC). Toradex also enhanced the driver to use the fbdev modedb and kernel argument support for the parallel RGP/LVDS output.

Tegra Framebuffer Boot Configuration

Note: Up to BSP V2.1Beta1 (released before 2014), the boot resolution of the framebuffer device is fixed in the kernel board initialization. See Tegra Framebuffer Boot Configuration (up to BSP V2.1Beta1).

Beginning with BSP V2.1 Beta 2 release in February 2014 our BSP supports configuration of framebuffer resolution from kernel command line using the kernel internal modedb.

The framebuffer driver registers two boot driver names (tegrafb0/tegrafb1) to allow different resolutions to be configured from the kernel command line. Using this two names, one can set the resolution of the framebuffer (and chose the initial display resolution) from the U-Boot command line.

setenv vidargs 'video=tegrafb0:1280x1024-16@60 video=tegrafb1:1680x1050-16@60'
saveenv

Note: Should the use of vidargs be prohibited to you by whatever reason the kernel will fall back to using the default_mode string as hard coded in resp. board panel file e.g for Colibri T20:

http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/board-colibri_t20-panel.c?h=tegra#n252

Depending on your display, the kernel provided modes might not work as expected. Also, some pixelclocks cannot be set very exact due to hardware restrictions (especially on Tegra 2 based devices). Thus, different timings might lead to different results.

The additional letter M allows to calculate margins using the common timing formula, the letter R calculates reduced margins. If you experience problems with your display, those options might be worth a try. We tested several displays and can recommend the follow settings:

Mode Specifier Description
640x480-16@60 VGA, default mode, also for EDT 5.7" TFT VGA
800x480-16@60 EDT 7.0" TFT WVGA
pixclockpol:0,800x480-16@60 Fusion Multi-Touch Display 7”
800x600M-16@60 SVGA
1024x600-16@60 Fusion Multi-Touch Display 10”
1024x768R-16@60 XGA
1280x720M-16@60 720p (HD)
1280x1024-16@60 SXGA
1366x768-16@60
1600x1200-16@60 UXGA
1680x1050-16@60
1920x1080-16@60 1080p (full HD)
1920x1200M-16@60

Note however, on the DVI-D (aka HDMI) our BSP supports EDID. If a monitor provides EDID information, the framebuffer driver queries the monitor and selects an appropriate resolution. Also the X-Server driver tegra later on queries EDID for the resolution list provided by XrandR, see X-Server).

For embedded LCD/TFT displays, additional parameters allow to alter signal polarities. This configurations are only supported on Output 1:

Description Parameter Name Value 0 Value 1
Pixelclock Polarity pixclockpol Display samples data on falling edge Display samples data on rising edge (default)
VSync Polarity vsync Active low (default) Active high
HSync Polarity hsync Active low (default) Active high
Data/Output Enable outputen Active low (default) Active high

For example, the Fusion Multi-Touch Display 7” requires inverted clock polarity:

setenv vidargs 'video=tegrafb0:pixclockpol:1,800x480@60'
saveenv

Framebuffer Bit/Colour Depth aka Bit Per Pixel (BPP)

By default our BSPs are configured for 16 bpp being rather economic in terms of memory bandwidth and space occupation. However one can easily configure the framebuffer and X driver for 24/32 bpp as well.

Note: The framebuffer and X driver configuration are two separate things.

Default 16 bpp
root@colibri-t30:~# cat /proc/cmdline 
core_edp_mv=1300 usb_high_speed=1 ip=off root=/dev/mmcblk0p2 rw,noatime rootfstype=ext3 rootwait asix_mac=00:14:2d:28:39:fe consoleblank=0 no_console_suspend=1 console=tty1 console=ttyS0,115200n8 debug_uartport=lsport,0 vmalloc=128M mem=1012M@2048M fbmem=12M@3060M video=tegrafb0:640x480-16@60

root@colibri-t30:~# fbset

mode "640x480-61"
    # D: 25.176 MHz, H: 31.469 kHz, V: 60.987 Hz
    geometry 640 480 640 960 16
    timings 39721 48 16 33 1 96 2
    rgba 5/11,6/5,5/0,0/0
endmode

root@colibri-t30:~# cat /var/log/Xorg.0.log | grep Depth
[4215611.541] (**) TEGRA(0): Depth 16, (--) framebuffer bpp 16
24 bpp

This actually sets up a 32 bit per pixel framebuffer.

root@colibri-t30:~# fw_setenv vidargs 'video=tegrafb0:640x480-24@60'

root@colibri-t30:~# mv /etc/X11/xorg.conf /etc/X11/xorg.conf.orig
root@colibri-t30:~# cat /etc/X11/xorg.conf.orig | sed 's/16/24/' > /etc/X11/xorg.conf

root@colibri-t30:~# cat /proc/cmdline 
core_edp_mv=1300 usb_high_speed=1 ip=off root=/dev/mmcblk0p2 rw,noatime rootfstype=ext3 rootwait asix_mac=00:14:2d:28:39:fe consoleblank=0 no_console_suspend=1 console=tty1 console=ttyS0,115200n8 debug_uartport=lsport,0 vmalloc=128M mem=1012M@2048M fbmem=12M@3060M video=tegrafb0:640x480-24@60

root@colibri-t30:~# fbset

mode "640x480-61"
    # D: 25.176 MHz, H: 31.469 kHz, V: 60.987 Hz
    geometry 640 480 640 960 32
    timings 39721 48 16 33 1 96 2
    rgba 8/0,8/8,8/16,8/24
endmode

root@colibri-t30:~# cat /var/log/Xorg.0.log | grep Depth
[4220070.472] (**) TEGRA(0): Depth 24, (--) framebuffer bpp 32
[4220070.487] (--) Depth 24 pixmap format is 32 bpp
32 bpp

From a framebuffer perspective 24 and 32 bpp are actually the same:

root@colibri-t30:~# fw_setenv vidargs 'video=tegrafb0:640x480-32@60'

root@colibri-t30:~# cat /proc/cmdline
core_edp_mv=1300 usb_high_speed=1 ip=off root=/dev/mmcblk0p2 rw,noatime rootfstype=ext3 rootwait asix_mac=00:14:2d:28:39:fe consoleblank=0 no_console_suspend=1 console=tty1 console=ttyS0,115200n8 debug_uartport=lsport,0 vmalloc=128M mem=1012M@2048M fbmem=12M@3060M video=tegrafb0:640x480-32@60

root@colibri-t30:~# fbset

mode "640x480-61"
    # D: 25.176 MHz, H: 31.469 kHz, V: 60.987 Hz
    geometry 640 480 640 960 32
    timings 39721 48 16 33 1 96 2
    rgba 8/0,8/8,8/16,8/24
endmode

However on the X driver side of things this is not the case and the X driver refuses to load with the following error message:

root@colibri-t30:~# mv /etc/X11/xorg.conf /etc/X11/xorg.conf.orig
root@colibri-t30:~# cat /etc/X11/xorg.conf.orig | sed 's/16/32/' > /etc/X11/xorg.conf

root@colibri-t30:~# systemctl restart lxdm

root@colibri-t30:~# cat /var/log/Xorg.0.log | grep -i depth
        "Common Screen" for depth/fbbpp 32/32
[4220292.352] (EE) TEGRA(0): Given depth (32) is not supported by this driver

Note: Above settings are purely about the internal colour representation of the framebuffer and have nothing to do with how any of this ends up on the actual external display interface signals which is rather a pin muxing thematic. The Tegras are hard coded in their resp. board pinmux files for 24 bit parallel RGB interfaces e.g for Colibri T20:

http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm/mach-tegra/board-colibri_t20-pinmux.c?h=tegra#n99

Tegra Framebuffer Configuration at Runtime

The fbset is able to change display timings at runtime, however running X-Server on top of the framebuffer will not be able to cope with such changes.

Currently we do advise to not use fbset.

Apalis T30 LVDS Transceiver Configuration

The Apalis T30 module comes with a flexible THine THC63LVD827 LVDS transceiver which can be configured via GPIOs:

root@apalis-t30:~# cat /sys/kernel/debug/gpio | grep LVDS
 gpio-216 (LVDS: Single/Dual Ch) out lo
 gpio-219 (LVDS: 18/24 Bit Mode) out hi
 gpio-220 (LVDS: Output Enable ) out hi
 gpio-221 (LVDS: Power Down    ) out hi
 gpio-222 (LVDS: Clock Polarity) out hi
 gpio-223 (LVDS: Colour Mapping) out hi
 gpio-225 (LVDS: Swing Mode    ) out hi
 gpio-226 (LVDS: DDRclk Disable) out hi

Our BSP comes with two scripts that can be used for that configuration:

/usr/bin/lvds-single-channel.sh
/usr/bin/lvds-dual-channel.sh

To have this automatically configured upon boot one of them scripts can be put into the LXDE autostart as explained here:

http://developer.toradex.com/knowledge-base/how-to-autorun-application-at-the-start-up-in-linux#lxsession-autostart-file

Tegra Framebuffer Boot Configuration (up to BSP V2.1Beta1)

Should you need to change the resolution/timing of the parallel RGB display controller/interface you have to:

a) Modify the Kernel Sources:

In the arch/arm/mach-tegra/board-colibri_t20-panel.c file:

  • colibri_t20_panel_modes[]

    • The first entry in that array defines the used timings.
    • Note: arch/arm/mach-tegra/board-colibri_t20.h does define TEGRA_FB_VGA by default.
    • A number of standard resolutions to choose from are already provided.
  • colibri_t20_fb_data

    • Adjust the resolution.
    • Adjust the colour depth (bits_per_pixel).
  • colibri_t20_dc_out_pins[]

    • You might require different H_SYNC, V_SYNC polarities.

b) Re-compile the Kernel:

Kernel compilation is explained in the following article:

Build U-Boot and Linux Kernel from Source Code

Note: The display mode has to be defined within the kernel, "xrandr --newmode" does not work.

Vybrid based modules

Vybrids display controller (DCU, Display Control Unit) supports only one output. Depending on the BSP version, the Linux kernel uses a different driver for the display controller.

  • fbdev driver: BSP Version 2.5 and earlier (BSP with Linux kernel 4.1 and older)
  • DRM driver: BSP Version 2.6 and later (BSP with Linux kernel 4.4 and newer)

fbdev driver

Description Output 1
Framebuffer boot name dcufb
Framebuffer device /dev/fb0
X-Server driver fbdev
X-Server output name default
Connector on EvalBoard LVDS/RGB/VGA
Connector on Iris DVI-A
Supports EDID (Software) No

Display Mode Boot Configuration

Beginning with BSP V2.1 Beta 3 release in March 2014 our BSP supports configuration of framebuffer resolution from kernel command line using the kernel internal modedb.

The framebuffer driver registers one boot driver named dcufb to set resolutions using kernel parameters.

setenv vidargs 'video=dcufb:1024x600-16@60'
saveenv

For embedded LCD/TFT displays, additional parameters allow to alter signal polarities.

Description Parameter Name Value 0 Value 1
Pixelclock Polarity pixclockpol Display samples data on falling edge Display samples data on rising edge (default)
VSync Polarity vsync Active low (default) Active high
HSync Polarity hsync Active low (default) Active high

The Vybrid DCU driver not only allows to select the kernel internal modes from the table of modedb.c but also the modes specified in the device tree. This is helpful if multiple modes are specified in the device tree. For instance the standard device tree carrier board file arch/arm/boot/dts/vf-colibri-eval-v3.dtsi has a set of display specification for the displays available through the Toradex web shop. One can use the kernel parameters to select one of them:

Mode Specifier Description
640x480-16@60 VGA, default mode, also for EDT 5.7" TFT VGA
800x480-16@60 EDT 7.0" TFT WVGA
pixclockpol:0,800x480-16@60 Fusion Multi-Touch Display 7”
800x600-16@60 SVGA
1024x600-16@60 Fusion Multi-Touch Display 10”
1024x768-16@60 XGA

To support a specific display we recommend to use the device tree to specify the exact display resolution and timings while also specifying the native-mode property. See the carrier board device tree file arch/arm/boot/dts/vf-colibri-eval-v3.dtsi:

...
    display: display@0 {
        bits-per-pixel = <16>;

        display-timings {
            native-mode = <timing_vga>;
            /* Standard VGA timing */
            timing_vga: 640x480 {
                clock-frequency = <25175000>;
                hactive = <640>;
                vactive = <480>;
                hback-porch = <40>;
                hfront-porch = <24>;
                vback-porch = <32>;
                vfront-porch = <11>;
                hsync-len = <96>;
                vsync-len = <2>;
                hsync-active = <0>;
                vsync-active = <0>;
                pixelclk-active = <0>;
            };
        };
    };
...

Make sure to clear the U-Boot's vidargs display specification, since settings supplied through the kernels command line parameters take precedence over the device tree specifications. For more information how-to alter the device tree refer to the Device Tree Customization article.

Note: At XGA resolution (1024x768), only 16-bit colour depth is supported. Higher colour depth lead to flicker issues likely due to memory bandwidth limitations.

Multiple Layers and Alpha Blending

How to Use multiple layers and alpha blending on Vybrid's display controller is explained in the following article.

Synchronise Page Flip on Vertical Blanking Period

Screen tearing is an effect which appears when the frame is updated while it is scanned out to the display. This results in a horizontal break where the upper half shows the old frame and the lower half the new frame. A method to avoid screen tearing is using two buffers aka double buffering and synchronise the swapping (page flip) of them to the vertical blanking period (V-sync).

When using the Linux kernels fbdev subsystem this is usually realised by doubling the vertical screen size and panning the scanned out screen between the left half and the right half of the framebuffer. The user space application needs to make sure not to alter the framebuffer which is currently scanned out. The framebuffer subsystem provides two ioctls to achieve this, FBIOPAN_DISPLAY to pan (page flip) and FBIO_WAITFORVSYNC to wait until the next vertical blanking period starts.

Note that the panning operation is not executed immediately. The Vybrid's display controller DCU implements a mechanism which makes sure that all configuration changes are synchronised to vertical blanking periods, including the new framebuffer pointer offset (panning). Hence after issuing the ioctl FBIOPAN_DISPLAY requesting to pan to the second framebuffer the first framebuffer could still be scanning out at that time. To make sure the first framebuffer is not scanned out any more use FBIO_WAITFORVSYNC to wait for next vertical blanking period. At that point it is safe to update the first framebuffer. The small test utility fb-test.c illustrates this approach and can be used to test vertical synchronization.

Note: The ioctl FBIO_WAITFORVSYNC is available in images after V2.4 Beta 1.

DRM driver

Description Output 1
KMS output name LVDS-1
Framebuffer device /dev/fb0
X-Server driver modesetting
X-Server output name LVDS-0*
Connector on EvalBoard LVDS/RGB/VGA
Connector on Iris DVI-A
Supports EDID (Software) No
  • The inconsistency with the KMS output name will be addressed with the next X-Server release (see this mailing list post).

Display Mode Boot Configuration

The DRM driver uses the display mode/timings provided by the associated panel driver in the device tree. Most panels are part of the panel-simple driver, displays supported by the panel-simple can be selected by using the respective compatible string. Toradex displays are supported by the following compatible strings:

Compatible String Description
edt,et057090dhu Default mode, EDT 5.7" TFT VGA
edt,et070080dh6 EDT 7.0" TFT WVGA
tpk,f07a-0102 Fusion Multi-Touch Display 7”
tpk,f10a-0102 Fusion Multi-Touch Display 10”

Note: The compatible strings for Fusion displays are available in BSP after V2.6 Beta 1.

To change the display mode/timings permanently, use the compatible string of your display in the carrier board level device tree to specify the connected display (see Device Tree Customization). To select a certain compatible string temporarily, the U-Boot environment fdt_fixup can be used:

Colibri VFxx # setenv fdt_fixup 'fdt addr ${fdt_addr_r} && fdt set /panel compatible "tpk,f07a-0102"'
Colibri VFxx # saveenv

If your display is missing in the list, you can add a new entry in the drivers source file (drivers/gpu/drm/panel/panel-simple.c). Make sure to use an appropriate compatible string.

To set a specific display timings, the video kernel parameter can be used. The syntax is similar to the fbdev kernel parameter syntax, however timings always get calculated using timing formulas (CVT or GTF).

setenv vidargs 'video=LVDS-1:1024x600M-16@60'
saveenv

The kernel will always select the "best" display timings, which is the higher resolution. Therefore, if a resolution below the currently selected panel (by default VGA) is specified, the output will still be VGA. One can use xrandr to select the lower resolution. To permanently configure a certain display timing, using the panel-simple driver is the recommended approach.

VSync and HSync are selected based on the rules of the formulas (CVT/GTF). There is no option to chose the pixel clock polarity using a kernel parameter. Use the panel-simple driver to specify those options explicitly.

Background about the reasons why display timings should not be part of the device tree can be found in Thierry Reding's blog post Display panels are not special.

Color depth of framebuffer device

The DRM driver supports emulation for the fbdev display interface (CONFIG_DRM_FBDEV_EMULATION). The mode is "inherited" from the DRM/KMS driver and cannot be changed using the fbdev device (e.g. fbset does not work). The default depth is 24 bit with a standard RGB 8:8:8 pixel format (24 bits per pixel). Releases after V2.6.1 Beta 1 have a new kernel parameter to change the fbdev depth: E.g. fsl_dcu_drm.legacyfb_depth=16 can be used to configure the fbdev framebuffer to use RGB 5:6:5 (16 bits per pixel).

Add Modes at Runtime using xrandr

The package xserver-xorg comes with the cvt utility which allows to calculate display timings according to the VESA CVT formula (Coordinated Video Timing).

cvt 800 480 60
# 800x480 59.48 Hz (CVT) hsync: 29.74 kHz; pclk: 29.50 MHz
Modeline "800x480_60.00"   29.50  800 824 896 992  480 483 493 500 -hsync +vsync

Copy the string after "Modeline" and use xrandr to create a new mode

xrandr --newmode "800x480_60.00"   29.50  800 824 896 992  480 483 493 500 -hsync +vsync
xrandr --addmode LVDS-0 800x480_60.00
xrandr --output LVDS-0 --mode 800x480_60.00

Alternative Pixel Clock Source

By default, the pixel clock is generated from PLL1_PFD2, which has a base clock of 452 MHz. A single divider breaks down the clock to the actual pixel clock. Depending on the requested pixel clock, the divided clock might not be accurate enough. As an alternative clock source PLL3 can be chosen, which provides a base clock of 480 MHz. To select PLL3 as base clock, use the following device tree properties in the nfc node:

assigned-clocks = <clks VF610_CLK_DCU0_SEL>;
assigned-clock-parents = <clks VF610_CLK_PLL3_USB_OTG>;