Plugable

Workaround for Mac OS X Conflicts between DisplayLink and USB ethernet

Posted on 16. Jun, 2010 by Bernie Thompson in Using

Plugable uses DisplayLink chips for USB graphics, and ASIX chips for USB Ethernet functionality. And we have both chips in devices like our Plugable USB 2.0 Universal Docking Station.

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.

Linux Support For Higher-Res Monitors on Lower-Res DisplayLink Devices

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

On Windows and Mac, if you plug in a monitor with a higher resolution than your adapter supports, the driver will automatically fall back to the best common mode between the two.

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

Windows 7 Multi-Monitor Tips and Tricks

Posted on 18. May, 2010 by Bernie Thompson in Windows