[update May 3, 2012: Support for using fb_defio and the standard, generic X fbdev driver is enabled by default, working, and stable with kernel 3.3 (at least). You’ll get lower CPU consumption and latency with DAMAGE notifications, but on many systems (especially higher end), fbdev is great. And because not everything supports DAMAGE, generic fbdev is more reliable.]
[update April 6, 2010: support for fbdev had been merged into the main udlfb codeline, including for 2.6.34, but has since been removed because of kernel faults that stand unsolved. If/when these problems can be found and fixed, fbdev support can get back into the mainline. Until then, the branch mentioned below is an ok way to try and test]
You can now get a version of udlfb with improved performance and support for any fbdev client.
Of the three DisplayLink Linux framebuffer driver lines, udlfb and displaylink-mod (written by Roberto DeIoris) have had the best performance by a significant margin. They’ve relied on Roberto’s custom X server, with some custom IOCTLs, to make use of precise X damage information. All the directions on the http://displaylink.org/ wiki have pointed to these drivers so far.
Unfortunately, these drivers won’t work with standard frambuffer clients that use a mmap’d framebuffer, because they’ll simply never refresh any area of the screen without damage notification. So drivers like the existing xf86-video-fbdev won’t work.
By contrast, Jaya Kumar’s defio-based DisplayLink codeline does work with xf86-video-fbdev or any standard fbdev client, but hasn’t been competitive performance-wise.
So the goal has been to merge the best aspects of both codelines — and get them merged into the kernel. That work isn’t completely done, but it’s at a working milesone. We now have a single kernel framebuffer driver that can support either roberto’s custom X driver (“displaylink”), or the standard fbdev X driver (“fbdev”), just by switching the “driver” line in the “server” section of xorg.conf. This makes for easier performance testing and workaround testing for X server specific problems.
And where previously, the fbdev driver was much slower than the displaylink custom (90% slower on some tests), it’s now within a few percentage points of difference – often not enough to notice.
There’s lots of room to optimize further yet, but this opens the possibility of not needing a custom X server at all for displaylink hardware, which would simplify the linux distribution rollout strategy.
You can grab this code at:
git clone http://git.plugable.com/webdav/udlfb
git checkout origin/defio
Then “make; sudo make install; sudo depmod -a” as usual. If you’re switching from displaylink-mod, get rid of that from the kernel modules directory first, or both udlfb and it may try to load.
Please post experience reports here or on the libdlo list. As patches have been developed for udlfb, there’s not been enough validation from the user community that the patches work and are valuable — and that would help the Linux kernel maintainers make their decisions about whether to accept patches.
Perf data is imperfect, but here’s a benchmark run of this code running the custom displaylink X server (making use of damage information)
bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a
GtkPerf 0.40 - Starting testing: Mon Dec 21 14:24:13 2009
GtkEntry - time: 0.00
GtkComboBox - time: 3.00
GtkComboBoxEntry - time: 1.89
GtkSpinButton - time: 0.42
GtkProgressBar - time: 0.60
GtkToggleButton - time: 0.44
GtkCheckButton - time: 0.42
GtkRadioButton - time: 0.75
GtkTextView - Add text - time: 2.09
GtkTextView - Scroll - time: 0.83
GtkDrawingArea - Lines - time: 1.66
GtkDrawingArea - Circles - time: 3.09
GtkDrawingArea - Text - time: 2.89
GtkDrawingArea - Pixbufs - time: 0.27
---
Total time: 18.37
Quitting..
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
cpu MHz : 1600.000
cpu MHz : 1333.000
MemTotal: 2052144 kB
Framebuffer Mode: 1920,1080
Rendered bytes: 155896744 (total pixels * Bpp)
Identical bytes: 96231480 (skipped via shadow buffer check)
sent bytes: 29614624 (compressed usb data, including overhead)
K CPU cycles: 1251295 (transpired, may include context switches)
% pixels found to be unchanged: 61.00 %
Compression of changed pixels : 50.00 %
Total CPU cycles spent per input pixel: 8
Total CPU cycles spent per output pixel: 42
USB Mbps: 11.29 (theoretical USB 2.0 peak 480)
And here’s a benchmark run of the same, just switched to run the standard fbdev X server (making use of only page faults)
bernie@bernie-aspireone:~/git/misc-udlfb$ ./udlfb-perf.sh fb0 gtkperf -a
GtkPerf 0.40 - Starting testing: Mon Dec 21 12:45:20 2009
GtkEntry - time: 0.00
GtkComboBox - time: 3.16
GtkComboBoxEntry - time: 1.80
GtkSpinButton - time: 0.41
GtkProgressBar - time: 0.60
GtkToggleButton - time: 0.44
GtkCheckButton - time: 0.41
GtkRadioButton - time: 0.76
GtkTextView - Add text - time: 2.03
GtkTextView - Scroll - time: 0.82
GtkDrawingArea - Lines - time: 1.87
GtkDrawingArea - Circles - time: 3.36
GtkDrawingArea - Text - time: 2.84
GtkDrawingArea - Pixbufs - time: 0.22
---
Total time: 18.73
Quitting..
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
model name : Intel(R) Atom(TM) CPU N270 @ 1.60GHz
cpu MHz : 1333.000
cpu MHz : 1600.000
MemTotal: 2052144 kB
Framebuffer Mode: 1920,1080
Rendered bytes: 288165888 (total pixels * Bpp)
Identical bytes: 227263860 (skipped via shadow buffer check)
sent bytes: 39281496 (compressed usb data, including overhead)
K CPU cycles: 1685041 (transpired, may include context switches)
% pixels found to be unchanged: 78.00 %
Compression of changed pixels : 35.00 %
Total CPU cycles spent per input pixel: 5
Total CPU cycles spent per output pixel: 42
USB Mbps: 14.98 (theoretical USB 2.0 peak 480)
The “Compression of changed pixels” is lower on fbdev, because the unchanged pixel detection is less accurate for the page fault method (for now, but that will get fixed ..), and so there’s a lot of re-rendering of desktop pixels — and my desktop background is a complex, gradient heavy image that doesn’t compress well.
The main performance gains vs. the original defio implementation are:
- Added RLE compression on the defio path
- Added shadow/backbuffer to scan for unchanged pixels on the defio path
- Moved to asynchronous urb dispatch for defio and damage codepaths (4 pre-alloc’d 64K urbs). This also has a significant performance benefit for the custom/damage path
- Changed defio path to no longer send an urb per line, but rather fill every urb completely, across lines and dirty pages. Big gain for defio.