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