Documentation/fb/udlfb.rst

9 USB wire.  That hardware framebuffer is able to drive the VGA, DVI, or HDMI
15 pixels line-by-line via USB bulk transfers.
18 does not require any acks - the effect is very low latency that
20 non-gaming and non-video applications.
22 Mode setting, EDID read, etc are other bulk or control transfers. Mode
23 setting is very flexible - able to set nearly arbitrary modes from any timing.
35    one-to-one with the fbdev interface, making the driver quite small and
38    from user mode to talk to the device, without needing to know anything
45    In the case of USB graphics, it is just an allocated (virtual) buffer.
50    of virtual or remote framebuffers.
60 of the monitor, and set the best common mode between the DisplayLink device
66 At that point, a /dev/fb? interface will be present for user-mode applications
68 standard fbdev calls.  Note that if mmap() is used, by default the user mode
71 defio support enabled, to support a page-fault based detection mechanism
74 The most common client of udlfb is xf86-video-displaylink or a modified
75 xf86-video-fbdev X server. These servers have no real DisplayLink specific
79 damage interface (which will hopefully be standardized for all virtual
122 		(e.g. X with --shared-vt) are in conflict.
148 			 which can be passed to utilities like parse-edid.
150 metrics_bytes_rendered	 32-bit count of pixel bytes rendered
152 metrics_bytes_identical  32-bit count of how many of those bytes were found to be
155 metrics_bytes_sent	 32-bit count of how many bytes were transferred over
159 metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
162 metrics_reset		 Write-only. Any write to this file resets all metrics
163 			 above to zero.  Note that the 32-bit counters above