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 theUSB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMImonitor with no CPU involvement until a pixel has to change.
The CPU or other local resource does all the rendering; optionally compares theresult with a local shadow of the remote hardware framebuffer to identifythe minimal set of pixels that have changed; and compresses and sends thosepixels line-by-line via USB bulk transfers.
Because of the efficiency of bulk transfers and a protocol on top thatdoes not require any acks - the effect is very low latency thatcan support surprisingly high resolutions with good performance fornon-gaming and non-video applications.
Mode setting, EDID read, etc are other bulk or control transfers. Modesetting 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.0capable system. On Linux, number of displays is limited by fbdev interface(FB_MAX is currently 32). Of course, all USB devices on the samehost 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 nearlyone-to-one with the fbdev interface, making the driver quite small andtight relative to the functionality it provides.
X servers and other applications can use the standard fbdev interfacefrom user mode to talk to the device, without needing to know anythingabout USB or DisplayLink’s protocol at all. A “displaylink” X driverand 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 standardinterface to allow mmap clients to report damage, for the benefitof 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 generationDisplayLink chips (Alex and Ollie family). It will then attempt to read the EDIDof the monitor, and set the best common mode between the DisplayLink deviceand the monitor’s capabilities.
If the DisplayLink device is successful, it will paint a “green screen” whichmeans that from a hardware and fbdev software perspective, everything is good.
At that point, a /dev/fb? interface will be present for user-mode applicationsto open and begin writing to the framebuffer of the DisplayLink device usingstandard fbdev calls. Note that if mmap() is used, by default the user modeapplication must send down damage notifications to trigger repaints of thechanged regions. Alternatively, udlfb can be recompiled with experimentaldefio support enabled, to support a page-fault based detection mechanismthat can work without explicit notification.
The most common client of udlfb is xf86-video-displaylink or a modifiedxf86-video-fbdev X server. These servers have no real DisplayLink specificcode. They write to the standard framebuffer interface and rely on udlfbto do its thing. The one extra feature they have is the ability to reportrectangles from the X DAMAGE protocol extension down to udlfb via udlfb’sdamage interface (which will hopefully be standardized for all virtualframebuffers that need damage info). These damage notifications allowudlfb to efficiently process the changed pixels.
Module Options¶
Special configuration for udlfb is usually unnecessary. There are a fewoptions, however.
From the command line, pass options to modprobe:
modprobe udlfb fb_defio=0 console=1 shadow=1
Or change options on the fly by editing/sys/module/udlfb/parameters/PARAMETER_NAME
cd /sys/module/udlfb/parametersls # to see a list of parameter namessudo nano PARAMETER_NAME# change the parameter in place, and save the file.
Unplug/replug USB device to apply with new settings.
Or to apply options permanently, create a modprobe configuration filelike /etc/modprobe.d/udlfb.conf with text:
options udlfb fb_defio=0 console=1 shadow=1
Accepted boolean options:
fb_defio | Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernelmodule to track changed areas of the framebuffer by page faults.Standard fbdev applications that use mmap but that do notreport damage, should be able to work with this enabled.Disable when running with X server that supports reportingchanged regions via ioctl, as this method is simpler,more stable, and higher performance.default: fb_defio=1 |
console | 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 |
shadow | Allocate a 2nd framebuffer to shadow what’s currently acrossthe 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 |
Sysfs Attributes¶
Udlfb creates several files in /sys/class/graphics/fb?Where ? is the sequential framebuffer id of the particular DisplayLink device
edid | If a valid EDID blob is written to this file (typicallyby a udev rule), then udlfb will use this EDID as abackup in case reading the actual EDID of the monitorattached to the DisplayLink device fails. This isespecially useful for fixed panels, etc. that cannotcommunicate their capabilities via EDID. Readingthis file returns the current EDID of the attachedmonitor (or last backup value written). This isuseful to get the EDID of the attached monitor,which can be passed to utilities like parse-edid. |
metrics_bytes_rendered | 32-bit count of pixel bytes rendered |
metrics_bytes_identical | 32-bit count of how many of those bytes were found to beunchanged, based on a shadow framebuffer check |
metrics_bytes_sent | 32-bit count of how many bytes were transferred overUSB to communicate the resulting changed pixels to thehardware. Includes compression and protocol overhead |
metrics_cpu_kcycles_used | 32-bit count of CPU cycles used in processing theabove pixels (in thousands of cycles). |
metrics_reset | Write-only. Any write to this file resets all metricsabove to zero. Note that the 32-bit counters aboveroll over very quickly. To get reliable results, designperformance tests to start and finish in a very shortperiod of time (one minute or less is safe). |
Bernie Thompson <bernie@plugable.com>