About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / fb / udlfb.txt

Custom Search

Based on kernel version 4.13.3. Page generated on 2017-09-23 13:55 EST.

2	What is udlfb?
3	===============
5	This is a driver for DisplayLink USB 2.0 era graphics chips.
7	DisplayLink chips provide simple hline/blit operations with some compression,
8	pairing that with a hardware framebuffer (16MB) on the other end of the
9	USB wire.  That hardware framebuffer is able to drive the VGA, DVI, or HDMI
10	monitor with no CPU involvement until a pixel has to change.
12	The CPU or other local resource does all the rendering; optionally compares the
13	result with a local shadow of the remote hardware framebuffer to identify
14	the minimal set of pixels that have changed; and compresses and sends those
15	pixels line-by-line via USB bulk transfers.
17	Because of the efficiency of bulk transfers and a protocol on top that
18	does not require any acks - the effect is very low latency that
19	can support surprisingly high resolutions with good performance for
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.
25	Advantages of USB graphics in general:
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.
32	Advantages of supporting DisplayLink chips with kernel framebuffer interface:
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.
42	Disadvantages:
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.
55	How to use it?
56	==============
58	Udlfb, when loaded as a module, will match against all USB 2.0 generation
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 between the DisplayLink device
61	and the monitor's capabilities.
63	If the DisplayLink device is successful, it will paint a "green screen" which
64	means that from a hardware and fbdev software perspective, everything is good.
66	At that point, a /dev/fb? interface will be present for user-mode applications
67	to open and begin writing to the framebuffer of the DisplayLink device using
68	standard fbdev calls.  Note that if mmap() is used, by default the user mode
69	application must send down damage notifications to trigger repaints of the
70	changed regions.  Alternatively, udlfb can be recompiled with experimental
71	defio support enabled, to support a page-fault based detection mechanism
72	that can work without explicit notification.
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
76	code. They write to the standard framebuffer interface and rely on udlfb
77	to do its thing.  The one extra feature they have is the ability to report
78	rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's
79	damage interface (which will hopefully be standardized for all virtual
80	framebuffers that need damage info). These damage notifications allow
81	udlfb to efficiently process the changed pixels.
83	Module Options
84	==============
86	Special configuration for udlfb is usually unnecessary. There are a few
87	options, however.
89	From the command line, pass options to modprobe
90	modprobe udlfb fb_defio=0 console=1 shadow=1
92	Or modify options on the fly at /sys/module/udlfb/parameters directory via
93	sudo nano fb_defio
94	change the parameter in place, and save the file.
96	Unplug/replug USB device to apply with new settings
98	Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text
99	options udlfb fb_defio=0 console=1 shadow=1
101	Accepted boolean options:
103	fb_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
112	console	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
117	shadow		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
123	Sysfs Attributes
124	================
126	Udlfb creates several files in /sys/class/graphics/fb?
127	Where ? is the sequential framebuffer id of the particular DisplayLink device
129	edid	       		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.
140	metrics_bytes_rendered	32-bit count of pixel bytes rendered
142	metrics_bytes_identical 32-bit count of how many of those bytes were found to be
143				unchanged, based on a shadow framebuffer check
145	metrics_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
149	metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the
150				above pixels (in thousands of cycles).
152	metrics_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).
158	--
159	Bernie Thompson <bernie@plugable.com>
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.