Changes between Version 4 and Version 5 of linux/display


Ignore:
Timestamp:
10/31/2019 05:27:20 PM (5 years ago)
Author:
Tim Harvey
Comment:

updated information; added directfb; removed outdated limitations section

Legend:

Unmodified
Added
Removed
Modified

  • linux/display

    v4 v5  
    44The purpose of this page is to help educate about display output on upstream Linux (not to be confused with the 'downstream' vendor kernel provided in Yocto).
    55
     6
     7= Linux Display Drivers
     8Video Graphics Processing Units (GPU) are extremely complicated and have evolved over time. There are a set of frameworks within the Linux kernel to support various GPU's and video cards as well as GPU-less hardware.
     9
     10There is a variety of terminology used here.
     11
     12
     13[=#linuxfb]
     14= Frame Buffer Device (fbdev)
     15An early kernel API called 'fbdev' is used to manage the framebuffer of a graphics adapter. Essentially the framebuffer provides direct access to an array of pixels mapped to the display. Because of this simplistic design, it supports software rendering only (no support 2D or 3D hardware acceleration), does not support double-buffering or page flipping.
     16
     17While you can still use {{{fbdev}}} today it's extremely inefficient.
     18
     19References:
     20 * ​https://www.kernel.org/doc/Documentation/fb/modedb.txt
     21
     22[=#drm]
    623= Direct Rendering Manager (DRM)
    724DRM is the driver subsystem in the kernel that is able to communicate with video drivers, such as the Freescale I.MX6 processors. Through {{{ioctl()}}} calls, multiple userspace programs can draw to a display at any given time as DRM will manage these requests. DRM is also able to interface with the graphics processor (GPU) in order to hardware accelerate these requests. This is separate from {{{framebuffer}}} in that it only allowed raw writes to a display. DRM exposes some information via sysfs in the {{{/sys/class/drm}}} directory.
     25
     26DRM drivers deal with DMA, AGP memory management, resource locking, and secure hardware access. In order to support multiple, simultaneous 3D applications the 3D graphics hardware must be treated as a shared resource. Locking is required to provide mutual exclusion. DMA transfers and the AGP interface are used to send buffers of graphics commands to the hardware. Finally, there must be security to prevent clients from escalating privilege using the graphics hardware.
    827
    928For example, to retrieve info about the DRM devices found on your system (Gateworks GW540x Linux 4.18):
    … …  
    1635 * card1 is from the IPU display driver
    1736
     37References:
     38 - https://en.wikipedia.org/wiki/Direct_Rendering_Manager
     39 - https://dri.freedesktop.org/wiki/DRM/
    1840
    19 == Kernel Mode Settings (KMS)
    20 KMS is part of DRM, but solely focuses on configuring display modes (i.e. screen resolution, refresh rate etc).
     41
     42[=#kms]
     43= Kernel Mode Settings (KMS)
     44Kernel Mode Setting (KMS) is a method for setting display resolution, pixel depth, and screen refresh in the kernel space rather than user space. In the past this was done in user-space by the X-Server. Modern video drivers like the {{{etnaviv}}} driver for the IMX6 GPU support KMS.
     45
     46The Linux kernel's implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies such as DRI2 which help reduce artifacts and increase 3D performance.
    2147
    2248When booting your kernel, mode settings are read by what appears in the kernel command line, else defaults are chosen. DRM exports the available modes for a given display in the DRM 'modes' file:
    … …  
    4066 - the above shows that the HDMI is connected to a 1080p capable monitor with several resolutions available and that the board also has an LVDS connector but it is disabled
    4167
    42 
    43 Mode settings can be passed to the kernel via the {{{video=}}} parameter from within U-Boot. The format of this is as follows: {{{video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]}}}
     68Default mode settings can be passed to the kernel via the {{{video=}}} parameter from within U-Boot. The format of this is as follows: {{{video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]}}}
    4469
    4570Note the following variables (see also [https://www.kernel.org/doc/Documentation/fb/modedb.txt modedb.txt]):
    … …  
    7398}}}
    7499
     100References:
     101- https://wiki.archlinux.org/index.php/Kernel_mode_setting
    75102
    76 == Limitations ==
    77 Using the upstream kernel currently has some limitations on the imx platform. For example, the driver is limited to the number of display outputs it can do. That means if both LVDS and HDMI were connected, both resolutions would be scaled to the display with the lower resolution. Both outputs are also mirror's of each other and cannot be run independently. However, using the 'downstream' vendor kernel that we provide on our Yocto BSPs do have features that allow for independently controlled displays, even allowing for an 'overlay' buffer for the first two displays.
    78 
    79 To see more on the downstream vendor kernel provided in Yocto, please see [wiki:Yocto/Video_Out here].
    80 
    81 == References ==
    82  * ​https://en.wikipedia.org/wiki/Direct_Rendering_Manager
    83  * ​https://en.wikipedia.org/wiki/Mode_setting
    84  * ​https://www.kernel.org/doc/Documentation/fb/modedb.txt