Plugable

Plugable’s USB 2.0 Graphics Adapter (DisplayLink DL-195)

Posted on 07. Mar, 2010 by Bernie Thompson in UGA-2K-A

Plugable’s new USB 2.0 Graphics Adapter is now available on Amazon.com.

The DisplayLink DL-195 chip inside this adapter is the best high-end chip out there for adding a display over USB. And because it pushes USB 2.0 and analog VGA to their limits, it isn’t likely to be beaten by any other chip in the USB 2.0 generation.

For this new adapter from Plugable, we wanted to offer that high-end choice, and also make sure that everything else about the adapter package itself meets or beats any alternative out there.

• The Plugable UGA-2K-A includes a DVI->HDMI adapter (in addition to the usual DVI->VGA adapter)
• The latest drivers are available on Windows Update and from displaylink.com
• Open source available, so there’ll be new software written for this device, even years from now
• Public problem reporting and support, so you can always get the full story about the product
• Amazon’s fast shipping and A-to-z guarantee on your purchase

In future posts, we’ll cover some of the cool things this device can do by enabling many displays on any PC (things like create the ultimate day-traders’ war-room, with many displays built around a single laptop).

Until then, you can read more about the product launch in the stuffily worded press release here. And more on the product page at http://plugable.com/products/uga-2k-a/.

Preparing more udlfb patches for linux-next

Posted on 12. Feb, 2010 by Bernie Thompson in UGA-2K-A

There are limits on how much a small device company can and should do in contributing to open source driver support. But with a historical connection to DisplayLink and more products coming with the technology included, contributing what we can to the generic DisplayLink driver on Linux makes some sense.

Also note this driver is just a foundation on which other stuff (like X) sits, so it doesn’t mean Linux is easy for real end users yet. But it’s getting closer.

Here’s the announce that went to the list today:

The next patch series for udlfb is “nearly ready” for submission, hopefully will be coming in the next few days.

* The defio rendering problems (e.g. with xf86-video-fbdev X server) are still unsolved
* Still 16bpp only. Pseudo-truecolor 32->16 is on the wishlist.
* No DL 1×5 SKU detection yet (you’ll get a blank screen if your monitor’s res exceeds the adapter)

Take your pick: standard or custom displaylink X drivers both work now

Posted on 21. Dec, 2009 by Bernie Thompson in Programming

[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.