Upgraded Plugable Universal Docking Station

Posted on 06. Mar, 2010 by Bernie Thompson in Windows

The Plugable Universal Docking Station is getting some minor but nice upgrades to the latest chips for each function. All new units shipped from March 1, 2010 forward have these new features:

  • Upgraded the DisplayLink DL-160 to the newer DL-165
    • Previous maximum resolution was 1680×1050, now 1920×1080
  • Moved from two 4-port NEC USB hubs internally to a single FE 2.1 7 port USB hub
    • When using as a terminal, previously could daisy-chain 2 docks, now up to 4. All devices attached to the dock show on the same hub
  • Upgraded ASIX AX88772 ethernet chip to newer AX88772A
    • Auto-MDX support (automatically detects straight or cross-over cabling)

We’ve also shrunk the paper package size for less waste, and a have smaller connector for the (otherwise same) AC adapter.

The size and look of the docking station itself hasn’t changed, and all the same adapters, cables, and other hardware are included.

To the laptop docking station user on Windows or Mac, the changes won’t be immediately obvious, as the same drivers support both versions of hardware.

On Linux, both old and new chips have the same in-kernel support. In the terminal case, the USB configuration is now simpler (all devices are off the same USB hub), and that means a change in the udev rules for devices plugged into usb ports (keyboard and mouse are one hub less deep). Look for a future post on that.

So, with the new version, here’s the Windows Update experience you’ll see — without using any driver disks first, just plugging into a fresh Windows 7 machine with its own network connection up, letting it find and download drivers automatically.


Win7 first connect experience. Mouse and composite keyboard also attached

If you need to distinguish the versions from the outside (e.g. so you can make sure to give a newer one to someone who wants 1920×1080 resolution), the model number on the bottom of the older units all start with 0920J1.

Enjoy the upgrades on the new UD-160-A docking stations, and as always make use of our public problem reporting and support at http://getsatisfaction.com/plugable any time.

Emacs macro to ease the pain of checkpatchitis

Posted on 19. Feb, 2010 by Bernie Thompson in udlfb

In order to submit patches to the Linux kernel — as I’ve been doing lately to help improve Linux’s DisplayLink driver udlfb — the changed code has to pass a script called checkpatch.pl, which flags violations of the Linux kernel style guidelines.

Style wars (e.g. “tabs vs. spaces”) are a never-ending source of tension on projects, so I actually appreciate automation like checkpatch.pl to just lay down the law, and be done with it.

But .. having to sift through endless warnings when you run checkpatch.pl late in the development process is frustrating. And there’s no way most occasional kernel patchers will remember all the rules (especially if you strongly disagree with some of them — which I do). It’s much better if your editor can just warn you when you step off the golden path of enlightenment. I use emacs, so I looked around for solutions, but they were only incomplete, or not real-time (e.g. checkpatch.pl has an –emacs option to run in the compile window of emacs).

So here’s something a little less incomplete that I’ve added to my .emacs file to catch the majority of checkpatch.pl errors in real-time (by highlighting the offending code in red). Works only on recent emacs versions. Hopefully it’ll be useful to others pounding away on their patches.

;; *** BEGIN highlight checkpatch.pl warnings and errors ***
(add-hook 'c-mode-common-hook
    (lambda ()
      ;; this sets defaults to match many checkpatch.pl guidelines
      (c-set-style "linux")))
;; but doesn't warn us about violations these regexp catch common ones
(custom-set-faces
    '(my-warning-face ((((class color)) (:background "red"))) t))
(add-hook 'font-lock-mode-hook
    (function
        (lambda ()
            (setq font-lock-keywords
                (append font-lock-keywords
		    '(("^.\\{81\\}" (0 'my-warning-face t)))
                    '(("\\/\\/.*" (0 'my-warning-face t)))
                    '((";[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '((",[_A-Za-z0-9]+" (0 'my-warning-face t)))
                    '(("return[[:blank:]]*(.+);" (0 'my-warning-face t)))
                    '(("([_A-Za-z0-9]+[\\*]+)" (0 'my-warning-face t)))
                    '(("[[:blank:]]+\\)"(0 'my-warning-face t)))
		    '(("^[[:blank:]]+{[[:blank:]]*$" (0 'my-warning-face t)))
		    '(("[_A-Za-z0-9]+\\*[[:blank:]]" (0 'my-warning-face t)))
		)))))
;; exercise to reader - move regexps into c hook
;; *** END highlight checkpatch.pl warnings and errors ***

Any enhancements or corrections are welcome.

Preparing more udlfb patches for linux-next

Posted on 12. Feb, 2010 by Bernie Thompson in udlfb

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.

Testing and any problem reports would be helpful. The code that will be submitted is at http://git.plugable.com/gitphp/index.php?p=udlfb&a=summary

There are many dozens of checkins in git as inter-related problems have been explored and the code incrementally improved. Before submitting, I’ll be reconstituting them into a smaller number of more analyzable email patches: make everything checkpatch.pl clean, reorganize things to match final layout, then per-feature patches. We’ll see how that goes.

Major features:

* Support for standard fbdev clients (via defio)
* Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears)
* Asynchronous urb dispatch and no mutexes held for extended periods during render
* Slightly lower CPU consumption, less touching memory, slightly higher average compression
* Better handling of switching from X to fbcon VTs and back
* Driver should unload cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
* Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics*)
* EDID reported through sysfs (read /sys/class/graphics/graphics/fbX/edid)
* Can compile as module with or without defio or sys_ dependencies
* Lots of cleanup – tested on 64-bit, closer to endian clean, checkpatch.pl clean

What it does not have:

* 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)

Page 1 of 612345...Last »

Plugable is Digg proof thanks to caching by WP Super Cache