ARMADA(4)
π ARMADA(4) π β the kernel interfaces manual, but make it a group chat
okay bestie, welcome to the armada page, from your Kernel Interfaces Manual era. she's giving driver, she's giving SoC, she's giving Xorg. let's go π«Ά
β¨ NAME β¨
armada β the Marvell Armada 510 and Freescale iMX6 Xorg driver. that's the whole name, no notes, periodt.
β¨ SYNOPSIS β¨
so you just... drop her in your config like this:
Section "Device"
Identifier "devname"
Driver "armada"
...
EndSection
that's it. Identifier is your little nickname for the device, Driver is literally just "armada" (iconic, self-explanatory), and the ... is where your other stuff goes. slay π
β¨ DESCRIPTION β¨
okay so armada is an Xorg driver for Marvell Armada and Freescale iMX6 SoCs. she's a kernel mode setting front end driver β with modular acceleration backends, which is a fancy way of saying she can swap her little helpers in and out. very main character energy.
framebuffer depths she supports: 8, 15, 16, 24. and for visuals? all visual types are supported for depth 8, and TrueColor visual is supported for the other depths. no cap.
she also has preliminary support for the Direct Rendering Infrastructure (DRI) version 2 and version 3 β like, it works, but she's still figuring herself out. and multi-head configurations are supported, so yes, you CAN have two monitors, we love a polyamorous display setup π
ngl, acceleration support is dependent on a separate acceleration module. go look at the "GPU ACCELERATION MODULES" section below, i'll wait π
video overlay support? provided. she handles I420, YV12, I422, YUY2, UYVY, VYUY and YV16 formats β but only dependent on support from the kernel DRM driver, so like, it's giving conditional. the common I420 and YV12 formats get converted on the fly by this driver to I422 and YV16 for the hardware. the way she just does that mid-flight?? obsessed.
support is also provided for video overlay using an XVBO format, which can be used to pass a DRM buffer handle to the video overlay backend. iykyk.
β¨ SUPPORTED HARDWARE β¨
the armada driver currently supports:
- the Marvell Armada 510 LCD controller(s)
- the Freescale iMX6 IPU
armada communicates with the Linux Kernel Direct Rendering Manager (drm) layer to control and arbitrate access to the hardware. Kernel drm support is required. like, required required. no drm, no driver, bestie π
other hardware which provides a Linux Kernel drm driver should also work with this driver. "should" is doing a lot of heavy lifting in that sentence but we're manifesting β¨
β¨ SUPPORTED GPU HARDWARE β¨
several GPU acceleration methods are supported by the DDX driver. each method is contained within its own module β one module per vibe, we respect the boundaries. details are listed below π
β¨ GPU ACCELERATION MODULES β¨
two GPU acceleration modules are currently supported. just two. a duo. a dynamic duo, even.
π¦ etnaviv_gpu
the etnaviv_gpu module provides 2D acceleration with the Vivante 2D PE1.0 and PE2.0 hardware (eg, GC600, GC320), supporting framebuffers with depths of 15, 16, 24.
Xrender acceleration is provided for most formats with a depth of 15, 16, 24, 32, and on PE2.0 hardware, the A8 alpha-only format. full glyph compositing is also supported with PE2.0 hardware β however, glyph caching and accelerated assembling of glyphs for final blend is supported with all hardware. so like, everyone gets a little something, we love inclusivity π
XV textured overlay is also provided, with support for I420, YV12, UYVY and YUY2 formatted images. chef's kiss.
π¦ vivante_gpu
the vivante_gpu module provides 2D acceleration with the Vivante 2D PE1.0 and PE2.0 hardware, supporting framebuffers with depths of 15, 16, 24 β but she's only usable with the armada kernel DRM driver. exclusive. loyal. doesn't play the field π
β¨ CONFIGURATION DETAILS β¨
pls refer to xorg.conf(5) for general configuration details, because this section only covers configuration details specific to this driver. we're staying in our lane.
for this driver, it is not required to specify modes in the screen section of the config file β the armada driver will request video mode information from the Linux Kernel drm layer. she'll ask, don't worry about it π«Ά
the VideoRAM option is ignored by this driver; video memory is managed by the Linux Kernel drm layer using system memory. so don't bother setting it, she's not reading it, she's got her own system, she's independent π
the following driver Options are supported:
Option "AccelModule" "filename"β force the usage of an acceleration module. no vibes-based auto-detection today, we're picking.- Default: try the
etnadrm_gpudrivers in turn, selecting the first which initialises.
- Default: try the
Option "Hotplug" "boolean"β this option controls whether the driver automatically notifies when monitors are connected or disconnected. she's perceptive.- Default: enabled.
Option "HWcursor" "boolean"β enable or disable use of the hardware cursor.- Default: disabled.
Option "UseGPU" "boolean"β enable or disable use of a GPU module for acceleration and textured XV support.- Default: enabled.
Option "XvAccel" "boolean"β enable or disable the X Video backend.- Default: enabled.
Option "XvDisablePrimary" "boolean"β allow the X Video backend to disable the primary plane when X Video image is displayed at full screen.- Note: some kernel drivers may not fully support this (eg, the kernel driver does a full modeset when restoring the primary plane, causing the screen to momentarily blank.) this option should be disabled for such kernel drivers, or the kernel driver updated to avoid such behaviour. so like, either fix the kernel driver or turn this off, pick one bestie, don't just live with the blinking π
- Default: enabled.
Option "XvPreferOverlay" "boolean"β make the hardware overlay the first XV adapter. disabling this option makes any GPU provided textured overlay the first XV adapter.- Note: iMX hardware does not provide scaling for XV overlay, and this option should be disabled on such systems to prefer textured overlay instead.
- Default: Overlay is preferred.
Option "AccelModule" "filename"β wait no, already did that one, she's up top, keep scrolling queen π
π XV OVERLAY VIDEO ATTRIBUTES π
the following XV attributes are supported by the XV overlay video driver. these are the knobs. turn them with love.
XV_AUTOPAINT_COLORKEY
XV_AUTOPAINT_COLORKEY is used to control whether the driver automatically fills the overlay window with the overlay color key. it is a Boolean attribute, with values 0 (never paint color key) and 1 (always paint color key). Default: 1.
XV_COLORKEY
XV_COLORKEY sets the color used for the overlay color key, in R8G8B8 format. Default: 0x0101fe.
XV_PIPE
XV_PIPE is used to control the CRTC to be used for overlay. a value of -1 allows the driver to select the appropriate CRTC based upon the position of the overlay window. other values select an explicit CRTC. Default: -1.
XV_BRIGHTNESS, XV_CONTRAST, XV_SATURATION
these options can be used to adjust the overlaid picture brightness, contrast and saturation levels. these options are dependent on their presence in the Linux kernel drm driver β so if they're not there, they're just not there, no cap.
XV_ITURBT_709
XV_ITURBT_709 sets the colorimetry for YUV format video. a value of 0 selects ITU-R BT.601 colorspace. a value of 1 selects ITU-R BT.709 colorspace. this option is dependent on the Linux kernel drm driver. colorimetry discourse, love that for us π
πΈ XV TEXTURED VIDEO ATTRIBUTES πΈ
textured overlay attributes are dependent on the GPU acceleration module. so your mileage may vary depending on which module showed up to the party.
XV_PIPE
XV_PIPE is used to select which CRTC is used to synchronize the screen update with the screen scanout to minimise tearing. a value of -1 allows the driver to select the appropriate CRTC based upon the position of the overlay window. other vlaues select an explicit CRTC. Default: -1.
okay so yes, the original literally says "vlaues". we are not fixing it. she stays. she's part of the lore now π
XV_SYNC_TO_VBLANK
XV_SYNC_TO_VBLANK is used to control whether the textured adapter synchronises with the screen scanout to minimise tearing. it is a Boolean attribute with values 0 (never sync) and 1 (always sync.) Default: 1. no tearing, no crying β¨
β¨ REPORTING BUGS β¨
the xf86-video-armada driver is a separately maintained driver, and bugs should be reported to the author. not to me, not to the group chat, to the author. thank you for coming to my ted talk π«Ά
β¨ SEE ALSO β¨
Xorg(1), xorg.conf(5), xorgconfig(1), Xserver(1), X(7) β go read these, they're the supporting cast, they ate π
β¨ AUTHORS β¨
authors include: Gerd Knorr, Michel DΓ€nzer, Geert Uytterhoeven, Russell King. legends, all of them. absolute icons. we stan π
and that's the page bestie!! she's from X Version 11, xf86-video-armada 0.0.0, dated back in the ARMADA(4) days β so go forth, configure your device section, and remember: kernel drm support is required, no cap. mwah ππ¦π
π¦ where this page comes from
- fedora 43: xorg-x11-drv-armada 0.0.0-16.unstable.20180829git78e7116a5.fc43 Β· MIT
- fedora 44: xorg-x11-drv-armada 0.0.0-17.unstable.20180829git78e7116a5.fc44 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms