Plugable

The Nexus One Phone-Top

Posted on 09. Jun, 2010 by Bernie Thompson in udlfb

Sven Killig has a sense of where computing is headed: Powerful computers are everywhere, including in your pocket. And he has the skills to push things ahead, to show us glimpses of what’s coming.

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.

Plugable UGA-2K-A In Stock

Posted on 02. Jun, 2010 by Bernie Thompson in Windows

After being sold out for some time, the Plugable UGA-2K-A USB to VGA/DVI/HDMI Adapter is now finally back in stock. This adapter has the DisplayLink 195 chip inside, supporting up to 2048×1152.

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.

Endurance Technology Contributions

Posted on 28. May, 2010 by Bernie Thompson in udlfb

Endurance Technology, a software consulting company in the UK who has done previous work on DisplayLink devices, has contributed back a branch of work done on the Fall 2009-era DisplayLink kernel framebuffer (udlfb) and X driver (xf86-video-displaylink).

The goal of their project was to get an embedded platform working on Centos 5.3. You can read more in their release note for the work.

To make the contributions easier to diff, they’ve been checked into a git branch from a (best guess) of the code Endurance started from.

The changes are available here for the kernel driver and here for the X server.

To actually build it, you may need their full package.

It’s unclear what of these changes might get picked up, as things have moved on since. One of the main features of this code is providing a default EDID blob in udlfb. The plan for udlfb at this point is to allow the edid sysfs interface of udlfb to be written to, to allow (and give responsibility) to a user-mode entity to supply a default edid, if one isn’t available from hardware.

Thanks again to Endurance for being diligent about contributing changes back.