Plugable

Plugable Open Source Hardware Samples Program

Posted on 16. Sep, 2010 by Bernie Thompson in udlfb

From time to time Plugable has extra test hardware around our labs. Rather than have it gather dust, we’d like to send it out to the open source community to help foster driver development.

We know how much work open source driver development is — getting hardware should be the easiest part of it. So today we’re announcing a new program to better get test devices out to developers who can use them.

If you’re a developer with a history submitting patches for Linux or other platforms, please submit your request for Plugable sample hardware here. Because we’ll have only a trickle of each type over device over time, an important part of this is having some idea of what prior driver development contributions you’ve made. We’ll try to focus on matching hardware to the developers most likely to be able to contribute improvements in that area.

Plugable’s products cover a fairly wide range of USB and other devices. See http://plugable.com/shop/ for our products that will be available from time to time under this program.

We’ve long been doing this kind of thing with the commercial vendors. Having worked on Windows and at Microsoft, we try to drop off samples to get them using, testing, and developing against our hardware. We’d do the same for Apple or others. This is our attempt to get these same benefits going with the wider open source community.

We hope this will seed some good things over time. And we welcome any feedback or suggestions on this program anytime.

What’s the Best PC for Running Multiple DisplayLink USB Monitors?

Posted on 21. Aug, 2010 by Bernie Thompson in Windows

One of our customers is building a six monitor setup on their PC for stock trading and ESignal Qcharts.

They asked: “What is the best Windows laptop and/or desktop to run six Plugable USB graphics adapters to get six monitors simultaneously on a single PC?” 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.

Hope that helps. Feel free to comment if you have any questions.

DisplayLink Linux kernel driver (udlfb) updates slated for 2.6.37

Posted on 18. Aug, 2010 by Bernie Thompson in UT-1

The latest set of patches for udlfb, the Linux kernel framebuffer driver for DisplayLink chips, has been submitted and looks on track for kernel 2.6.37. This will catch the kernel up to everything on http://git.plugable.com/

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