<!DOCTYPE html>
<html lang="en" data-content_root="../">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>udlfb - DisplayLink USB 2.0 driver — The Linux Kernel documentation</title>
<link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
<link rel="stylesheet" type="text/css" href="../_static/alabaster.css?v=3918102e" />
<script src="../_static/documentation_options.js?v=5929fcd5"></script>
<script src="../_static/doctools.js?v=9bcbadda"></script>
<script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
<link rel="index" title="Index" href="../genindex.html" />
<link rel="search" title="Search" href="../search.html" />
<link rel="next" title="uvesafb - A Generic Driver for VBE2+ compliant video cards" href="uvesafb.html" />
<link rel="prev" title="Tridentfb" href="tridentfb.html" />
<link rel="stylesheet" href="../_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="../index.html">
<img class="logo" src="../_static/logo.svg" alt="Logo of The Linux Kernel"/>
</a></p>
<h1 class="logo"><a href="../index.html">The Linux Kernel</a></h1>
<p class="blurb">6.18.50</p>
<search id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script>
<p>
<h3 class="kernel-toc-contents">Contents</h3>
<input type="checkbox" class="kernel-toc-toggle" id = "kernel-toc-toggle" checked>
<label class="kernel-toc-title" for="kernel-toc-toggle"></label>
<div class="kerneltoc" id="kerneltoc">
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/development-process.html">Development process</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/submitting-patches.html">Submitting patches</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/code-of-conduct.html">Code of conduct</a></li>
<li class="toctree-l1"><a class="reference internal" href="../maintainer/index.html">Maintainer handbook</a></li>
<li class="toctree-l1"><a class="reference internal" href="../process/index.html">All development-process docs</a></li>
</ul>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="../core-api/index.html">Core API</a></li>
<li class="toctree-l1"><a class="reference internal" href="../driver-api/index.html">Driver APIs</a></li>
<li class="toctree-l1 current"><a class="reference internal" href="../subsystem-apis.html">Subsystems</a><ul class="current">
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#core-subsystems">Core subsystems</a></li>
<li class="toctree-l2 current"><a class="reference internal" href="../subsystem-apis.html#human-interfaces">Human interfaces</a><ul class="current">
<li class="toctree-l3"><a class="reference internal" href="../input/index.html">Input Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../hid/index.html">Human Interface Devices (HID)</a></li>
<li class="toctree-l3"><a class="reference internal" href="../sound/index.html">Sound Subsystem Documentation</a></li>
<li class="toctree-l3"><a class="reference internal" href="../gpu/index.html">GPU Driver Developer’s Guide</a></li>
<li class="toctree-l3 current"><a class="reference internal" href="index.html">Frame Buffer</a></li>
<li class="toctree-l3"><a class="reference internal" href="../leds/index.html">LEDs</a></li>
</ul>
</li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#networking-interfaces">Networking interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#storage-interfaces">Storage interfaces</a></li>
<li class="toctree-l2"><a class="reference internal" href="../subsystem-apis.html#other-subsystems">Other subsystems</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="../locking/index.html">Locking</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../process/license-rules.html">Licensing rules</a></li>
<li class="toctree-l1"><a class="reference internal" href="../doc-guide/index.html">Writing documentation</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/index.html">Development tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../dev-tools/testing-overview.html">Testing guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kernel-hacking/index.html">Hacking guide</a></li>
<li class="toctree-l1"><a class="reference internal" href="../trace/index.html">Tracing</a></li>
<li class="toctree-l1"><a class="reference internal" href="../fault-injection/index.html">Fault injection</a></li>
<li class="toctree-l1"><a class="reference internal" href="../livepatch/index.html">Livepatching</a></li>
<li class="toctree-l1"><a class="reference internal" href="../rust/index.html">Rust</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/index.html">Administration</a></li>
<li class="toctree-l1"><a class="reference internal" href="../kbuild/index.html">Build system</a></li>
<li class="toctree-l1"><a class="reference internal" href="../admin-guide/reporting-issues.html">Reporting issues</a></li>
<li class="toctree-l1"><a class="reference internal" href="../tools/index.html">Userspace tools</a></li>
<li class="toctree-l1"><a class="reference internal" href="../userspace-api/index.html">Userspace API</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../firmware-guide/index.html">Firmware</a></li>
<li class="toctree-l1"><a class="reference internal" href="../devicetree/index.html">Firmware and Devicetree</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../arch/index.html">CPU architectures</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../staging/index.html">Unsorted documentation</a></li>
</ul>
<ul>
<li class="toctree-l1"><a class="reference internal" href="../translations/index.html">Translations</a></li>
</ul>
</div>
<script type="text/javascript"> <!--
var sbar = document.getElementsByClassName("sphinxsidebar")[0];
let currents = document.getElementsByClassName("current")
if (currents.length) {
sbar.scrollTop = currents[currents.length - 1].offsetTop;
}
--> </script>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="../_sources/fb/udlfb.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="udlfb-displaylink-usb-2-0-driver">
<h1>udlfb - DisplayLink USB 2.0 driver<a class="headerlink" href="#udlfb-displaylink-usb-2-0-driver" title="Link to this heading">¶</a></h1>
<p>This is a driver for DisplayLink USB 2.0 era graphics chips.</p>
<p>DisplayLink chips provide simple hline/blit operations with some compression,
pairing that with a hardware framebuffer (16MB) on the other end of the
USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI
monitor with no CPU involvement until a pixel has to change.</p>
<p>The CPU or other local resource does all the rendering; optionally compares the
result with a local shadow of the remote hardware framebuffer to identify
the minimal set of pixels that have changed; and compresses and sends those
pixels line-by-line via USB bulk transfers.</p>
<p>Because of the efficiency of bulk transfers and a protocol on top that
does not require any acks - the effect is very low latency that
can support surprisingly high resolutions with good performance for
non-gaming and non-video applications.</p>
<p>Mode setting, EDID read, etc are other bulk or control transfers. Mode
setting is very flexible - able to set nearly arbitrary modes from any timing.</p>
<p>Advantages of USB graphics in general:</p>
<blockquote>
<div><ul class="simple">
<li><p>Ability to add a nearly arbitrary number of displays to any USB 2.0
capable system. On Linux, number of displays is limited by fbdev interface
(FB_MAX is currently 32). Of course, all USB devices on the same
host controller share the same 480Mbs USB 2.0 interface.</p></li>
</ul>
</div></blockquote>
<p>Advantages of supporting DisplayLink chips with kernel framebuffer interface:</p>
<blockquote>
<div><ul class="simple">
<li><p>The actual hardware functionality of DisplayLink chips matches nearly
one-to-one with the fbdev interface, making the driver quite small and
tight relative to the functionality it provides.</p></li>
<li><p>X servers and other applications can use the standard fbdev interface
from user mode to talk to the device, without needing to know anything
about USB or DisplayLink’s protocol at all. A “displaylink” X driver
and a slightly modified “fbdev” X driver are among those that already do.</p></li>
</ul>
</div></blockquote>
<p>Disadvantages:</p>
<blockquote>
<div><ul class="simple">
<li><p>Fbdev’s mmap interface assumes a real hardware framebuffer is mapped.
In the case of USB graphics, it is just an allocated (virtual) buffer.
Writes need to be detected and encoded into USB bulk transfers by the CPU.
Accurate damage/changed area notifications work around this problem.
In the future, hopefully fbdev will be enhanced with an small standard
interface to allow mmap clients to report damage, for the benefit
of virtual or remote framebuffers.</p></li>
<li><p>Fbdev does not arbitrate client ownership of the framebuffer well.</p></li>
<li><p>Fbcon assumes the first framebuffer it finds should be consumed for console.</p></li>
<li><p>It’s not clear what the future of fbdev is, given the rise of KMS/DRM.</p></li>
</ul>
</div></blockquote>
<section id="how-to-use-it">
<h2>How to use it?<a class="headerlink" href="#how-to-use-it" title="Link to this heading">¶</a></h2>
<p>Udlfb, when loaded as a module, will match against all USB 2.0 generation
DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
of the monitor, and set the best common mode between the DisplayLink device
and the monitor’s capabilities.</p>
<p>If the DisplayLink device is successful, it will paint a “green screen” which
means that from a hardware and fbdev software perspective, everything is good.</p>
<p>At that point, a /dev/fb? interface will be present for user-mode applications
to open and begin writing to the framebuffer of the DisplayLink device using
standard fbdev calls. Note that if mmap() is used, by default the user mode
application must send down damage notifications to trigger repaints of the
changed regions. Alternatively, udlfb can be recompiled with experimental
defio support enabled, to support a page-fault based detection mechanism
that can work without explicit notification.</p>
<p>The most common client of udlfb is xf86-video-displaylink or a modified
xf86-video-fbdev X server. These servers have no real DisplayLink specific
code. They write to the standard framebuffer interface and rely on udlfb
to do its thing. The one extra feature they have is the ability to report
rectangles from the X DAMAGE protocol extension down to udlfb via udlfb’s
damage interface (which will hopefully be standardized for all virtual
framebuffers that need damage info). These damage notifications allow
udlfb to efficiently process the changed pixels.</p>
</section>
<section id="module-options">
<h2>Module Options<a class="headerlink" href="#module-options" title="Link to this heading">¶</a></h2>
<p>Special configuration for udlfb is usually unnecessary. There are a few
options, however.</p>
<p>From the command line, pass options to modprobe:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>modprobe udlfb fb_defio=0 console=1 shadow=1
</pre></div>
</div>
<p>Or change options on the fly by editing
/sys/module/udlfb/parameters/PARAMETER_NAME</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>cd /sys/module/udlfb/parameters
ls # to see a list of parameter names
sudo nano PARAMETER_NAME
# change the parameter in place, and save the file.
</pre></div>
</div>
<p>Unplug/replug USB device to apply with new settings.</p>
<p>Or to apply options permanently, create a modprobe configuration file
like /etc/modprobe.d/udlfb.conf with text:</p>
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>options udlfb fb_defio=0 console=1 shadow=1
</pre></div>
</div>
<p>Accepted boolean options:</p>
<table class="docutils align-default">
<tbody>
<tr class="row-odd"><td><p>fb_defio</p></td>
<td><p>Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
module to track changed areas of the framebuffer by page faults.
Standard fbdev applications that use mmap but that do not
report damage, should be able to work with this enabled.
Disable when running with X server that supports reporting
changed regions via ioctl, as this method is simpler,
more stable, and higher performance.
default: fb_defio=1</p></td>
</tr>
<tr class="row-even"><td><p>console</p></td>
<td><p>Allow fbcon to attach to udlfb provided framebuffers.
Can be disabled if fbcon and other clients
(e.g. X with --shared-vt) are in conflict.
default: console=1</p></td>
</tr>
<tr class="row-odd"><td><p>shadow</p></td>
<td><p>Allocate a 2nd framebuffer to shadow what’s currently across
the USB bus in device memory. If any pixels are unchanged,
do not transmit. Spends host memory to save USB transfers.
Enabled by default. Only disable on very low memory systems.
default: shadow=1</p></td>
</tr>
</tbody>
</table>
</section>
<section id="sysfs-attributes">
<h2>Sysfs Attributes<a class="headerlink" href="#sysfs-attributes" title="Link to this heading">¶</a></h2>
<p>Udlfb creates several files in /sys/class/graphics/fb?
Where ? is the sequential framebuffer id of the particular DisplayLink device</p>
<table class="docutils align-default">
<tbody>
<tr class="row-odd"><td><p>edid</p></td>
<td><p>If a valid EDID blob is written to this file (typically
by a udev rule), then udlfb will use this EDID as a
backup in case reading the actual EDID of the monitor
attached to the DisplayLink device fails. This is
especially useful for fixed panels, etc. that cannot
communicate their capabilities via EDID. Reading
this file returns the current EDID of the attached
monitor (or last backup value written). This is
useful to get the EDID of the attached monitor,
which can be passed to utilities like parse-edid.</p></td>
</tr>
<tr class="row-even"><td><p>metrics_bytes_rendered</p></td>
<td><p>32-bit count of pixel bytes rendered</p></td>
</tr>
<tr class="row-odd"><td><p>metrics_bytes_identical</p></td>
<td><p>32-bit count of how many of those bytes were found to be
unchanged, based on a shadow framebuffer check</p></td>
</tr>
<tr class="row-even"><td><p>metrics_bytes_sent</p></td>
<td><p>32-bit count of how many bytes were transferred over
USB to communicate the resulting changed pixels to the
hardware. Includes compression and protocol overhead</p></td>
</tr>
<tr class="row-odd"><td><p>metrics_cpu_kcycles_used</p></td>
<td><p>32-bit count of CPU cycles used in processing the
above pixels (in thousands of cycles).</p></td>
</tr>
<tr class="row-even"><td><p>metrics_reset</p></td>
<td><p>Write-only. Any write to this file resets all metrics
above to zero. Note that the 32-bit counters above
roll over very quickly. To get reliable results, design
performance tests to start and finish in a very short
period of time (one minute or less is safe).</p></td>
</tr>
</tbody>
</table>
<p>Bernie Thompson <<a class="reference external" href="mailto:bernie%40plugable.com">bernie<span>@</span>plugable<span>.</span>com</a>></p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="footer">
©The kernel development community.
|
Powered by <a href="https://www.sphinx-doc.org/">Sphinx 8.1.3</a>
& <a href="https://alabaster.readthedocs.io">Alabaster 0.7.16</a>
|
<a href="../_sources/fb/udlfb.rst.txt"
rel="nofollow">Page source</a>
</div>
</body>
</html>