Documentation/fb/udlfb.rst

Source file repositories/reference/linux-study-clean/Documentation/fb/udlfb.rst

File Facts

System
Linux kernel
Corpus path
Documentation/fb/udlfb.rst
Extension
.rst
Size
7728 bytes
Lines
170
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

==================================
udlfb - DisplayLink USB 2.0 driver
==================================

This is a driver for DisplayLink USB 2.0 era graphics chips.

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.

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.

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.

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.

Advantages of USB graphics in general:

 * 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.

Advantages of supporting DisplayLink chips with kernel framebuffer interface:

 * 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.
 * 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.

Disadvantages:

 * 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.
 * Fbdev does not arbitrate client ownership of the framebuffer well.
 * Fbcon assumes the first framebuffer it finds should be consumed for console.
 * It's not clear what the future of fbdev is, given the rise of KMS/DRM.

How to use it?
==============

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.

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.

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

Annotation

Implementation Notes