They asked: “What is the best Windows laptop and/or desktop to run six Plugable USB graphics adapters?” It’s a great question, because there are definitely ways to head off potential problems when you pick a PC. It really comes down to two main things to think about.

Intel Graphics Controller

First, for maximum compatibility with USB graphics products, pick a system with Intel-only graphics if possible. Here’s why:

1. ATI and nVidia, because they’re shooting for the higher end, do more out-of-the-box things to try to differentiate their technology and software drivers. Sometimes those things can conflict with other complex software, like DisplayLink’s USB graphics drivers.
2. In particular, look out for “switching” or “hybrid” graphics on laptops. These add a discrete nVidia or ATI GPU on top of the Intel GPU already in the chipset, for the purpose of providing switchable “high power” and “low power” graphics by enabling or disabling one or the other GPU. They attempt to do this switching without Windows noticing (just Like DisplayLink tries to add USB display outputs to the primary graphics controller without Windows noticing), but in combination this can cause conflicts. DisplayLink has made some progress with compatibility with these types of systems, but it’s still the #1 hardware compatibility issue we see for USB graphics.
3. Even though nVidia and ATI provide higher 3D performance, they don’t have higher performance everywhere: in particular with USB displays, the rendered pixels must be transferred from the GPU back to the CPU to be sent over USB. When the GPU has its own memory on the other side of the PCI bus (as is the usually case with ATI and nVidia), those transfers back can be slow. With Intel chipset graphics, the pixels remain in system memory the whole time – which ends up being faster overall.
4. Intel is in closer collaboration with DisplayLink than nVidia or ATI has been.
5. Intel’s is the lowest cost solution. For business applications (like stock trading) with many displays, it makes sense to favor simplicity and compatibility over 3D gaming performance.

nVidia and ATI/AMD are great companies that produce high-performance products, and DisplayLink’s software rarely have problems with them. But as it happens the simplest and lowest cost solution is also the best choice for this particular application.

Mid-range or better CPU and Memory

Second, for the system itself, more memory and a faster CPU make a difference. Take the money saved on a high-end 3D processor, and funnel it back into the main CPU and memory that’ll make everything on your PC faster. But no need to go overboard – there’s usually a sweet spot.

For memory with Windows 7 and something like 6 USB displays, 2GB is enough .. although going to 4 or more will produce noticeable overall system gains (mostly because of all the additional apps you’ll be running to display on all those monitors). Even though Windows 7 is much improved over Vista, multiple monitors and many open applications still consume a lot of memory.

But just as important as the amount of RAM is the amount of cache. In the USB graphics case, memory and the memory controller is getting a lot of use, as pixels change on the screen (at least 4 times – when an application renders new pixels, when those pixels are composited on the desktop, when they’re copied to a shadow framebuffer, and when those changed pixels are compressed into USB packets). Note that once the changed pixels are sent over USB, the CPU isn’t involved anymore to refresh the display .. that work is all done by the hardware framebuffer on the USB device, so in terms of CPU load, it’s just about the pixels that are changing at any given moment.

So what to look for in the CPU’s memory controller? Faster memory interface and larger caches. Products change quickly, but currently Intel’s “Nehalem” microarchitecture provides the best alternatives. The sweet spot currently is with DDR3-1066 memory interface or better and at least 3 MB L3 cache. In terms of particular CPUs, that maps out to Intel CPUs like the the Core i3 530 or higher for the desktop, and the Core i3 330M or higher for laptops.

Below are a desktop and a laptop system that meet the criteria well (if you’re in a RSS reader, click on the full post to see the links). And the good thing about “keeping things simple” and focusing on USB expandability, is the systems themselves are not expensive – they’re at the favorable end of the cost/power curve.

Linux is a big and constantly shifting platform. With our USB graphics products (and generally for DisplayLink based products, since we try to make them work for all devices), it’s easy to output a few pixels, but configuring a USB display as an X terminal, or certainly for an extended desktop, is still a process on Linux that requires manual xorg.conf editing and is for very advanced users only. But we try to contribute what we can at Plugable, and that has meant focusing on making the kernel driver that actually talks to the hardware and everything else builds on, as solid as possible.

The contributed patches start with this post to the linux driver project list.

————–
To: devel-request@linuxdriverproject.org
[PATCH 0/11] staging: udlfb: patches from udlfb development branch (Bernie Thompson)

This patch series contains all current fixes and features from
the udlfb development branch.

udlfb is a framebuffer driver for DisplayLink USB 2.0 era chips.

Diffstat of this 11 part patch series:

udlfb.c | 989 +++++++++++++++++++++++++++++++++++++++++———————–
udlfb.h | 41 +-
2 files changed, 664 insertions(+), 366 deletions(-)

Major changes:

* Added summary documentation for users of udlfb
* Added logic to query DisplayLink chip for max area mode,
so low-end chips on high-end monitors no longer get black screen
* Added support for DPMS. X servers now control monitor
power with existing standard interface
* Added back in support for char interface (e.g. cat file > /dev/fb0)
* Systems without EDID or with failing EDID can now supply fixed
EDID to sysfs interface, also avoiding black screen
* Fixed big-endian (PowerPC) rendering
* Fixed teardown race conditions that could result in shutdown hang
* Added fb_defio and fb console module options (default off)
* Fixed udlfb’s fb_defio client code so no longer incorrectly shares
state across udlfb device instances – fixes hangs and errant rendering
* Removed IFDEFs for building against older kernels – those will
be retained in the udlfb development branches at git.plugable.com

Todo:

There have been no additional reported bugs in the last few months,
although there are several wishlist features. Udlfb may be ready
to move out of staging at this point.

Patches are against Linus’ latest 2.6 tree.

This complete quilt patch series can be downloaded from http://plugable.com/udlfb-patches-2.6.35-v2.tgz

Thank you to all our customers who’ve purchased the UD-160-A: we hope to keep growing this way.

And for any customers who’ve ordered one in the last month, we’d like you to benefit too. Just email your Amazon order number (looks like e.g. 105-9082692-3326138) to sales@plugable.com, and we’ll refund the difference — thanks again for being a Plugable customer!

Plugable UD-160-A driving 1920x1080 display and more, all from a humble Nexus One phone

This setup uses the udlfb DisplayLink Linux driver work from here (git.plugable.com) and a bunch of other components Sven has developed or pulled together, to turn the phone into a full computer with display, keyboard, audio and more. His video of this has gone viral (over 85,000 views). You can see the video and full instructions at Sven’s site. Very cool.

The photo above is of the Plugable UD-160-A Universal Docking Station, in use at Sven’s desk (the dock is laying on its side to better fit in the photo – Sven has removed the weighted bottom stand).

The Plugable dock is perfect for this kind of application with the Nexus One phone — it includes all the USB devices in one place, all with open source drivers. The dock has its own 2.5A AC power (see the USB dual-power Y cable plugged into the front USB A and back USB B ports), along with driving the 1920×1080 monitor (the big DVI cable in the back), and providing ethernet (above the DVI) and audio (in the front – he doesn’t have them plugged in in the pic).

So this all is great for geeks, but when will this work out of the box? Several comments on Sven’s work are messages like “Google! Integrate this into Android now!”

With Google offices near here, and with related USB terminal work on the same Plugable dock being funded as a Google Summer of Code project, it would be great to demo this and get things moving… Whatcha say, Google!?

Unfortunately, on Mac OS X, there is a conflict between recent DisplayLink drivers 1.5+ and the Apple drivers (AppleUSBEthernet) for ASIX chips. The DisplayLink drivers appear to open other USB devices as part of enumeration. As a side effect, this causes USB ethernet devices to show as “disconnected” upon return from system boot or hibernate.

That’s in addition to other graphics and ethernet driver compatibility breaks that Apple’s recent OS X 10.6 updates have introduced, including breaking AppleUSBEthernet for non-Apple USB ethernet hardware.

Until these issues settle down and are fixed in the drivers from DisplayLink, ASIX, and Apple, here is a workaround for the current issues with the ethernet function of the Plugable Universal Docking Station:

Step 1 is to download and install ASIX drivers that are compatible with recent Mac OS X 10.6: http://plugable.com/wp-content/uploads/2010/04/AppleDefaultDriver_v2.1.5.zip

Step 2 is to copy the following script to a file (call it “install”), and run “sudo ./install”

#!/bin/bash
sudo echo "#!/bin/bash" > /usr/bin/plugable-eth-reset
sudo echo kextunload -b com.apple.driver.AppleUSBEthernet >> /usr/bin/plugable-eth-reset
sudo echo kextload -b com.apple.driver.AppleUSBEthernet >> /usr/bin/plugable-eth-reset
sudo chown root /usr/bin/plugable-eth-reset
sudo chmod o+x /usr/bin/plugable-eth-reset
sudo defaults write com.apple.loginwindow LoginHook /usr/bin/plugable-eth-reset

Now, logging out and logging back in will automatically reload the ethernet driver. Unfortunately, this does not cover the return from low-power cases. Unless we find an improvement to the workaround, you’ll have to log out/log in or just run “sudo /usr/bin/eth-reset” so trigger the script.

As there may be variations in systems out there, please comment if you get different results, and we’ll post an update here at Plugable if (as we hope) this is fixed more directly in the DisplayLink or ASIX drivers in the future.

And, generally if you’re a Mac OS X user, please be cautious about OS updates which might break 3rd party hardware drivers. If you have non-Apple USB hardware, consider deferring updates until there’s time for other people to report on forums about compatibility.

Last year, he demoed turning your router into a full-fledged computer.

This year, it’s the Google Nexus One phone as a full computer — with attached external keyboard, mouse, display, and more.

The Nexus One demo is using the udlfb Linux kernel module to talk with the DisplayLink device, and it will work with any DisplayLink device, including Plugable’s.

Note the version of udlfb in the 2.6.34 staging tree unfortunately didn’t work for Sven. So he’s now using the latest udlfb from http://git.plugable.com/, which will likely get merged in for kernel 2.6.36.

Also, he used a dual headed cable to get enough power. A powered hub or a docking station/terminal like the UD-160-A won’t need that — it supplies its own power from AC – all the hardware needed is in the one package.

It’s exciting to have all this open source work come together in interesting demos like this.

There was a question recently why udlfb doesn’t use the same compression technique as the Windows drivers. Among other reasons, one is that the RL compression used by udlfb scales down to devices like the ones Sven has been working on — it’s as light as possible on CPU load, while getting decent compression.

Stepping back, it’s clear Apple (and now Microsoft) are making a mistake by limiting the hardware ecosystem around their devices. Android and the other Linux variants have an opportunity here — and considering the Apple juggernaut, they definitely need every advantage.

Sven’s demos show how powerful these scenarios can be. The hardware is ready. Devices like Plugable’s are designed with these scenarios in mind. Now we need to get the software refined and included in standard distributions, so normal consumers can take advantage of all the possibilities and benefits here.

For those that have been waiting — thank you for your patience!

Improvements in the new UGA-2K-A adapters include:

• Updated USB plug and play ID and strings unique to the Plugable UGA-2K-A
• Fix for a voltage problem with DVI connected monitors that occasionally required unplugging both USB and DVI to reset the device
• Groundwork laid for compliance with the “DisplayLink Certified” program

And all the great software compatibility features are the same, including automatic detection, download, and install of drivers via Microsoft’s Windows Update system for Windows 7, Vista, and XP. Mac and Linux compatibility are the same (see product page for limitations — there are important ones to note).

Thank you to all our customers who buy Plugable products! We really appreciate your support.

We’re very excited about the Google funded project to refine USB multiseat on Linux, with the winning proposal from Lucas Nascimento Ferreira at the Federal University of Parana in Brazil.

In addition to providing mentoring, Plugable is also providing donated hardware for this project. Two Plugable Universal Docking stations with recent enhancements for use as a terminal, were just picked up by Lucas in Brazil today. By next month, we expect to have updated versions of the UGA-125-HUB for terminal use to send down.

For those interested in learning more and potentially following Lucas’ work:

• Google’s SoC 2010 Timeline
• Lucas’ winning USB Multiseat Proposal

And we’ll post periodic status updates here.

Linux hasn’t had that support — it would try to set the highest mode the monitor is capable of, often resulting in a black screen. Especially common for the DL-125 chip, with its mode limits of 1440×900/1280×1024.

That’s a shame because the DL-125 chip is a smart choice in many cases – by limiting itself to those lower modes, it stays more consistently within the limits of the USB 2.0 bus, resulting in more consistent performance.

So coinciding with the launch of Plugable’s DisplayLink DL-125 based products (UGA-125 and UGA-125-HUB), changes have been implemented to bring Linux roughly up to the level of Windows and Mac in this area for DisplayLink devices. This also helps devices like the UD-160-A when running on monitors greater than its limit of 1920×1080.

The kernel framebuffer driver udlfb has been enhanced to read the resolution limit from the firmware descriptors of the device, and adhere to it.

On the X server side, we needed a driver which would limit itself to the resulting reduced mode list. Unfortunately, the existing displaylink X server reads EDID directly, and assumes the adapter can do whatever the monitor can do.

We’ve been wanting to get rid of the need for a displaylink-specific X server, and the standard xf86-video-fbdev driver runs with the best existing mode, rather than trying to set a higher one in EDID. So this was a good trigger for converting over.

So xf86-video-fbdev has been enhanced with X Damage protocol support, ported from Roberto’s displaylink driver. This is still a little in-flux from an interface perspective, but from a functional perspective it’s done and fully performant.

So it’s now possible to run with a modified generic fbdev driver, which talks to udlfb, with full performance and without needing defio (although there’s also some good news in the defio space, which will be posted about later).

You can grab the latest udlfb kernel module with a “git clone http://git.plugable.com/webdav/udlfb”. Compile with “make && sudo make install && sudo depmod -a”

And you can grab the latest modified xf86-video-fbdev with a “git clone http://git.plugable.com/webdav/xf86-video-fbdev”. Compile with “./autogen.sh && make && sudo make install”

You’ll need a very recent xorg-macros version (1.4), which in package “sudo apt-get install xutils-dev”

To use the new X server, you must turn on the new “ReportDamage” option to fbdev. Modify your existing xorg conf like this:

Section "Device"
  Identifier "dl"
  Driver "fbdev"
  Option "ReportDamage" "true"
  Option "fbdev" "/dev/fb0"
EndSection

And you should be all set to go. This new X server should work with the existing udlfb in the staging tree of kernel 2.6.31+ for now, as it’s re-using the same original ioctl. But may require modeset changes that are only in 2.6.34+.