linux/Documentation/fb/udlfb.txt
<<
>>
Prefs
   1
   2What is udlfb?
   3===============
   4
   5This is a driver for DisplayLink USB 2.0 era graphics chips.
   6
   7DisplayLink chips provide simple hline/blit operations with some compression,
   8pairing that with a hardware framebuffer (16MB) on the other end of the
   9USB wire.  That hardware framebuffer is able to drive the VGA, DVI, or HDMI
  10monitor with no CPU involvement until a pixel has to change.
  11
  12The CPU or other local resource does all the rendering; optinally compares the
  13result with a local shadow of the remote hardware framebuffer to identify
  14the minimal set of pixels that have changed; and compresses and sends those
  15pixels line-by-line via USB bulk transfers.
  16
  17Because of the efficiency of bulk transfers and a protocol on top that
  18does not require any acks - the effect is very low latency that
  19can support surprisingly high resolutions with good performance for
  20non-gaming and non-video applications.
  21
  22Mode setting, EDID read, etc are other bulk or control transfers. Mode
  23setting is very flexible - able to set nearly arbitrary modes from any timing.
  24
  25Advantages of USB graphics in general:
  26
  27 * Ability to add a nearly arbitrary number of displays to any USB 2.0
  28   capable system. On Linux, number of displays is limited by fbdev interface
  29   (FB_MAX is currently 32). Of course, all USB devices on the same
  30   host controller share the same 480Mbs USB 2.0 interface.
  31
  32Advantages of supporting DisplayLink chips with kernel framebuffer interface:
  33
  34 * The actual hardware functionality of DisplayLink chips matches nearly
  35   one-to-one with the fbdev interface, making the driver quite small and
  36   tight relative to the functionality it provides.
  37 * X servers and other applications can use the standard fbdev interface
  38   from user mode to talk to the device, without needing to know anything
  39   about USB or DisplayLink's protocol at all. A "displaylink" X driver
  40   and a slightly modified "fbdev" X driver are among those that already do.
  41
  42Disadvantages:
  43
  44 * Fbdev's mmap interface assumes a real hardware framebuffer is mapped.
  45   In the case of USB graphics, it is just an allocated (virtual) buffer.
  46   Writes need to be detected and encoded into USB bulk transfers by the CPU.
  47   Accurate damage/changed area notifications work around this problem.
  48   In the future, hopefully fbdev will be enhanced with an small standard
  49   interface to allow mmap clients to report damage, for the benefit
  50   of virtual or remote framebuffers.
  51 * Fbdev does not arbitrate client ownership of the framebuffer well.
  52 * Fbcon assumes the first framebuffer it finds should be consumed for console.
  53 * It's not clear what the future of fbdev is, given the rise of KMS/DRM.
  54
  55How to use it?
  56==============
  57
  58Udlfb, when loaded as a module, will match against all USB 2.0 generation
  59DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID
  60of the monitor, and set the best common mode between the DisplayLink device
  61and the monitor's capabilities.
  62
  63If the DisplayLink device is successful, it will paint a "green screen" which
  64means that from a hardware and fbdev software perspective, everything is good.
  65
  66At that point, a /dev/fb? interface will be present for user-mode applications
  67to open and begin writing to the framebuffer of the DisplayLink device using
  68standard fbdev calls.  Note that if mmap() is used, by default the user mode
  69application must send down damage notifcations to trigger repaints of the
  70changed regions.  Alternatively, udlfb can be recompiled with experimental
  71defio support enabled, to support a page-fault based detection mechanism
  72that can work without explicit notifcation.
  73
  74The most common client of udlfb is xf86-video-displaylink or a modified
  75xf86-video-fbdev X server. These servers have no real DisplayLink specific
  76code. They write to the standard framebuffer interface and rely on udlfb
  77to do its thing.  The one extra feature they have is the ability to report
  78rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
  79damage interface (which will hopefully be standardized for all virtual
  80framebuffers that need damage info). These damage notifications allow
  81udlfb to efficiently process the changed pixels.
  82
  83Module Options
  84==============
  85
  86Special configuration for udlfb is usually unnecessary. There are a few
  87options, however.
  88
  89From the command line, pass options to modprobe
  90modprobe udlfb fb_defio=0 console=1 shadow=1
  91
  92Or modify options on the fly at /sys/module/udlfb/parameters directory via
  93sudo nano fb_defio
  94change the parameter in place, and save the file.
  95
  96Unplug/replug USB device to apply with new settings
  97
  98Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
  99options udlfb fb_defio=0 console=1 shadow=1
 100
 101Accepted boolean options:
 102
 103fb_defio        Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel
 104                module to track changed areas of the framebuffer by page faults.
 105                Standard fbdev applications that use mmap but that do not
 106                report damage, should be able to work with this enabled.
 107                Disable when running with X server that supports reporting
 108                changed regions via ioctl, as this method is simpler,
 109                more stable, and higher performance.
 110                default: fb_defio=1
 111
 112console Allow fbcon to attach to udlfb provided framebuffers.
 113                Can be disabled if fbcon and other clients
 114                (e.g. X with --shared-vt) are in conflict.
 115                default: console=1
 116
 117shadow          Allocate a 2nd framebuffer to shadow what's currently across
 118                the USB bus in device memory. If any pixels are unchanged,
 119                do not transmit. Spends host memory to save USB transfers.
 120                Enabled by default. Only disable on very low memory systems.
 121                default: shadow=1
 122
 123Sysfs Attributes
 124================
 125
 126Udlfb creates several files in /sys/class/graphics/fb?
 127Where ? is the sequential framebuffer id of the particular DisplayLink device
 128
 129edid                    If a valid EDID blob is written to this file (typically
 130                        by a udev rule), then udlfb will use this EDID as a
 131                        backup in case reading the actual EDID of the monitor
 132                        attached to the DisplayLink device fails. This is
 133                        especially useful for fixed panels, etc. that cannot
 134                        communicate their capabilities via EDID. Reading
 135                        this file returns the current EDID of the attached
 136                        monitor (or last backup value written). This is
 137                        useful to get the EDID of the attached monitor,
 138                        which can be passed to utilities like parse-edid.
 139
 140metrics_bytes_rendered  32-bit count of pixel bytes rendered
 141
 142metrics_bytes_identical 32-bit count of how many of those bytes were found to be
 143                        unchanged, based on a shadow framebuffer check
 144
 145metrics_bytes_sent      32-bit count of how many bytes were transferred over
 146                        USB to communicate the resulting changed pixels to the
 147                        hardware. Includes compression and protocol overhead
 148
 149metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
 150                        above pixels (in thousands of cycles).
 151
 152metrics_reset           Write-only. Any write to this file resets all metrics
 153                        above to zero.  Note that the 32-bit counters above
 154                        roll over very quickly. To get reliable results, design
 155                        performance tests to start and finish in a very short
 156                        period of time (one minute or less is safe).
 157
 158--
 159Bernie Thompson <bernie@plugable.com>
 160
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.