170 lines · plain
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 the9USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI10monitor with no CPU involvement until a pixel has to change.11 12The CPU or other local resource does all the rendering; optionally compares the13result with a local shadow of the remote hardware framebuffer to identify14the minimal set of pixels that have changed; and compresses and sends those15pixels line-by-line via USB bulk transfers.16 17Because of the efficiency of bulk transfers and a protocol on top that18does not require any acks - the effect is very low latency that19can support surprisingly high resolutions with good performance for20non-gaming and non-video applications.21 22Mode setting, EDID read, etc are other bulk or control transfers. Mode23setting 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.028 capable system. On Linux, number of displays is limited by fbdev interface29 (FB_MAX is currently 32). Of course, all USB devices on the same30 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 nearly35 one-to-one with the fbdev interface, making the driver quite small and36 tight relative to the functionality it provides.37 * X servers and other applications can use the standard fbdev interface38 from user mode to talk to the device, without needing to know anything39 about USB or DisplayLink's protocol at all. A "displaylink" X driver40 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 standard49 interface to allow mmap clients to report damage, for the benefit50 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 generation59DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID60of the monitor, and set the best common mode between the DisplayLink device61and the monitor's capabilities.62 63If the DisplayLink device is successful, it will paint a "green screen" which64means 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 applications67to open and begin writing to the framebuffer of the DisplayLink device using68standard fbdev calls. Note that if mmap() is used, by default the user mode69application must send down damage notifications to trigger repaints of the70changed regions. Alternatively, udlfb can be recompiled with experimental71defio support enabled, to support a page-fault based detection mechanism72that can work without explicit notification.73 74The most common client of udlfb is xf86-video-displaylink or a modified75xf86-video-fbdev X server. These servers have no real DisplayLink specific76code. They write to the standard framebuffer interface and rely on udlfb77to do its thing. The one extra feature they have is the ability to report78rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's79damage interface (which will hopefully be standardized for all virtual80framebuffers that need damage info). These damage notifications allow81udlfb to efficiently process the changed pixels.82 83Module Options84==============85 86Special configuration for udlfb is usually unnecessary. There are a few87options, however.88 89From the command line, pass options to modprobe::90 91 modprobe udlfb fb_defio=0 console=1 shadow=192 93Or change options on the fly by editing94/sys/module/udlfb/parameters/PARAMETER_NAME ::95 96 cd /sys/module/udlfb/parameters97 ls # to see a list of parameter names98 sudo nano PARAMETER_NAME99 # change the parameter in place, and save the file.100 101Unplug/replug USB device to apply with new settings.102 103Or to apply options permanently, create a modprobe configuration file104like /etc/modprobe.d/udlfb.conf with text::105 106 options udlfb fb_defio=0 console=1 shadow=1107 108Accepted boolean options:109 110=============== ================================================================111fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel112 module to track changed areas of the framebuffer by page faults.113 Standard fbdev applications that use mmap but that do not114 report damage, should be able to work with this enabled.115 Disable when running with X server that supports reporting116 changed regions via ioctl, as this method is simpler,117 more stable, and higher performance.118 default: fb_defio=1119 120console Allow fbcon to attach to udlfb provided framebuffers.121 Can be disabled if fbcon and other clients122 (e.g. X with --shared-vt) are in conflict.123 default: console=1124 125shadow Allocate a 2nd framebuffer to shadow what's currently across126 the USB bus in device memory. If any pixels are unchanged,127 do not transmit. Spends host memory to save USB transfers.128 Enabled by default. Only disable on very low memory systems.129 default: shadow=1130=============== ================================================================131 132Sysfs Attributes133================134 135Udlfb creates several files in /sys/class/graphics/fb?136Where ? is the sequential framebuffer id of the particular DisplayLink device137 138======================== ========================================================139edid If a valid EDID blob is written to this file (typically140 by a udev rule), then udlfb will use this EDID as a141 backup in case reading the actual EDID of the monitor142 attached to the DisplayLink device fails. This is143 especially useful for fixed panels, etc. that cannot144 communicate their capabilities via EDID. Reading145 this file returns the current EDID of the attached146 monitor (or last backup value written). This is147 useful to get the EDID of the attached monitor,148 which can be passed to utilities like parse-edid.149 150metrics_bytes_rendered 32-bit count of pixel bytes rendered151 152metrics_bytes_identical 32-bit count of how many of those bytes were found to be153 unchanged, based on a shadow framebuffer check154 155metrics_bytes_sent 32-bit count of how many bytes were transferred over156 USB to communicate the resulting changed pixels to the157 hardware. Includes compression and protocol overhead158 159metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the160 above pixels (in thousands of cycles).161 162metrics_reset Write-only. Any write to this file resets all metrics163 above to zero. Note that the 32-bit counters above164 roll over very quickly. To get reliable results, design165 performance tests to start and finish in a very short166 period of time (one minute or less is safe).167======================== ========================================================168 169Bernie Thompson <bernie@plugable.com>170