DisplayLink USB Devices on Linux Kernel 3.4.0

Linux kernel 3.4.0 is the first to include a new driver for DisplayLink-based USB 2.0 devices, called “udl”. udl is a port of the udlfb driver to Linux’s DRM architecture. David Airlie is doing this work, and the potential is very exciting. Eventually, this architecture will lead to a host of advantages, including GPU-accelerated 3D rendering to USB graphics adapters.

Both the new “udl”, and older “udlfb” framebuffer driver that we maintain are present in 3.4.0. Unfortunately, the new udl DRM driver is still maturing, and can cause kernel panics. With USB graphics devices present, you can determine which driver (“udlfb” or “udl”) is getting loaded with lsmod:

lsmod | grep "udl"

This change has a particular impact with Fedora 17 — the first open source distro to have automatic USB multiseat support — which shipped with Linux kernel 3.3.

Post-ship, Fedora 17 now offers a software update to kernel 3.4.0, which unfortunately causes problems: udl may be loaded for DisplayLink-based devices, and kernel panics are common and terminals often won’t come up. To the user, it appears to break multiseat.

So to fix the issues you’ll see with 3.4.0, we recommend disabling udl for the time being. The stable udlfb driver is still present in the kernel, and will get matched against your hardware automatically once udl is no longer loaded. The easiest way to do this is to run the following commands and reboot:

echo "blacklist udl" | sudo tee --append /etc/modprobe.d/udlfb.conf
sudo depmod -a
sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

One the server reboots, udlfb should match all USB graphics devices and be fully stable. Please let us know if you have any trouble. And in coming Linux kernel versions, udl will continue to improve and at some point udlfb will be able to be retired in favor of it.


neither object nor array? not implemented yet

Switch to gutenberg-Blocks!
There the JSON Content Importer Block gives an easier way to use the JSON-APIs.
Or: Switch on the Debugmode by adding "debugmode=10" in the Shortcode.

If all is without success: Open ticket at wordpress.org please


We have a Problem with JSON here:
Either we got no JSON from the API. Or the basenode-parameter is not ok.
Switch on the Debugmode of the Plugin!
Switch to gutenberg-Blocks!
There the JSON Content Importer Block gives an easier way to use the JSON-APIs.
Or: Switch on the Debugmode by adding "debugmode=10" in the Shortcode.

If all is without success: Open ticket at wordpress.org please


20 comments on “DisplayLink USB Devices on Linux Kernel 3.4.0”

  1. rob

    Hi
    We have 1 plugable and 3 more ordered…. Using Fedora 17 we ran in to the panics.
    So I followed the blog instructions , did this:
    echo “blacklist udl” | sudo tee –append /etc/modprobe.d/udlfb.conf
    sudo depmod -a

    cat /etc/modprobe.d/udlfb.conf
    # Makes the stock fbdev driver work with the kernel driver
    options udlfb fb_defio=y
    blacklist udl

    rebooted. but we still have the newer module in use:
    udl 23806 1
    syscopyarea 12413 1 udl
    sysfillrect 12582 1 udl
    sysimgblt 12554 1 udl
    drm_usb 12854 1 udl
    drm_kms_helper 31059 2 udl,i915
    drm 205872 6 udl,i915,drm_usb,drm_kms_helper

    from uname our kernel is: 3.4.3-1.fc17.i686 #1 SMP Mon Jun 18 20:52:37 UTC 2012 i686 i686 i386 GNU/Linux

    Do you have another suggestion to get udlfb used instead of udl?

    • bernie

      Hi Rob – Can you try opening /etc/modprobe.d/udlfb.conf as sudo, and see if we are just missing a linefeed after the blacklist udl line? Try adding one, running sudo depmod -a again, and rebooting again. Just let us know – we’ll be able to get udl disabled (in favor of udlfb), and then make any needed updates to these instructions. Thanks for reporting back! Bernie

  2. rob

    just tried those steps. and same result.

    root@fedora17 ~ # cat /etc/modprobe.d/udlfb.conf
    # Makes the stock fbdev driver work with the kernel driver

    options udlfb fb_defio=y

    blacklist udl

    # end

    * after reboot:

    root@fedora17 ~ # lsmod|grep udl
    udl 23806 0
    syscopyarea 12413 1 udl
    sysfillrect 12582 1 udl
    sysimgblt 12554 1 udl
    drm_usb 12854 1 udl
    drm_kms_helper 31059 2 udl,i915
    drm 205872 5 udl,i915,drm_usb,drm_kms_helper

    • bernie

      Quick note to others. Fedora has a unique way of updating initramfs. That was neccessary on Rob’s machine to blacklist the kernel module (but not on mine, I don’t know why). Here’s the command:
      sudo dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

      And the post has been updated with this info. Rob – thanks for your patience!

  3. Dave Airlie

    btw we disabled udl in the f17 configs now, hopefully for f18 we can fix the issues.

    • bernie

      Hi Dave – Thanks for the great work on udl, and thanks also for disabling the F17 configs until the USB multiseat case is stable (USB multiseat is a great testcase, for having many USB devices in use and coming and going).

      I don’t understand the udl codebase and changes yet, but one of the panics I’ve seen is in dpy_deferred_io, and it may be similar to an issue fixed in udlfb in recent months: if any complex operations are triggered in USB probe() or disconnect() — page faults, long-run render operations — it runs into issues with either/both the execution context at that time or race conditions between probe and disconnect. Particularly with fb_defio’s page fault mechanism, there are issues. So in udlfb, I changed to do the minimum amount of talking with the hardware in USB probe() and disconnect(), and deferred the rest (e.g. painting the green screen) to scheduled work outside of the pnp context. This has resolved all the issues we had been able to recreate. Here is background on the patch against udlfb. I don’t know how easily it could be ported to udl:
      Discussion: http://www.mail-archive.com/stable@vger.kernel.org/msg07996.html
      Patch: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8d21547d3c9c3bc653261f26d554cfabc4a083de

      And since so much is different with udl, I’m not at all sure that this is the cause/solution to the current issues – but it may be one worth doing regardless.

      I don’t know if you’ve already seen and been working on this, but I hope that is helpful to you. Please let me know if we can get you any more info. Thanks again! Bernie

  4. disi

    Which device was the first supported by Fedora 17 again?
    I have a DC-125 and only got the green screen so far, given that I do not have to get my hands dirty and just ‘plug & see’ 🙂

    • bernie

      Hi Marcus. Thanks for posting! Your DC-125 was purchased in the first half of 2011, before the changes were made (to the hardware) for Fedora 17 and the kickstarter. Any DC-125 purchased in the US starting May, 2012 or in the EU starting June 2012 has the updates and will work automatically. All UD-160s going back to the middle of 2010 have the updates. Any older ones will only come up to a green screen (seat won’t launch). We want to get more people on Fedora 17, so if you have an older DC-125, just email us at support@plugable.com and we’ll see about exchanging with you for a newer unit. Thanks!

  5. tamer

    hello,
    trying without success on ubuntu 12.04 kernel 3.4.4
    can you help me ? 🙂

    1 – configured kernel, but I can see results for lsmod | grep “udl”
    2 – depmod – a
    3 – dracut to generate image
    4 – hwinfo shows the usb device
    5- dmesg shows the usb devide with udlfb
    6 – what is missing ?

    dmesg | grep -i udlfb
    [ 2.694720] usbcore: registered new interface driver udlfb
    [ 475.408414] udlfb: DisplayLink SUNWEIT USB Display – serial #00000000-001236
    [ 475.408418] udlfb: vid_17e9&pid_024c&rev_0101 driver’s dlfb_data struct at eb7b1000
    [ 475.408420] udlfb: console enable=1
    [ 475.408422] udlfb: fb_defio enable=1
    [ 475.408423] udlfb: shadow enable=1
    [ 475.408500] udlfb: vendor descriptor length:22 data:22 5f 01 0020 05 00 01 03 04 02
    [ 475.408503] udlfb: DL chip limited to 2080000 pixel modes
    [ 475.408548] udlfb: allocated 4 65024 byte urbs
    [ 475.601622] udlfb: Unable to get valid EDID from device/display
    [ 475.601627] udlfb: 640×350 @ 85 Hz valid mode
    [ 475.601630] udlfb: 640×400 @ 85 Hz valid mode
    [ 475.601632] udlfb: 721×400 @ 85 Hz valid mode
    [ 475.601634] udlfb: 640×480 @ 60 Hz valid mode
    [ 475.601637] udlfb: 640×480 @ 72 Hz valid mode
    [ 475.601639] udlfb: 640×480 @ 75 Hz valid mode
    [ 475.601641] udlfb: 640×480 @ 85 Hz valid mode
    [ 475.601643] udlfb: 800×600 @ 56 Hz valid mode
    [ 475.601645] udlfb: 800×600 @ 60 Hz valid mode
    [ 475.601647] udlfb: 800×600 @ 72 Hz valid mode
    [ 475.601649] udlfb: 800×600 @ 75 Hz valid mode
    [ 475.601652] udlfb: 800×600 @ 85 Hz valid mode
    [ 475.601654] udlfb: 1024×768 @ 43 Hz valid mode
    [ 475.601656] udlfb: 1024×768 @ 60 Hz valid mode
    [ 475.601658] udlfb: 1024×768 @ 70 Hz valid mode
    [ 475.601660] udlfb: 1024×768 @ 75 Hz valid mode
    [ 475.601662] udlfb: 1024×768 @ 85 Hz valid mode
    [ 475.601665] udlfb: 1152×864 @ 75 Hz valid mode
    [ 475.601667] udlfb: 1280×960 @ 60 Hz valid mode
    [ 475.601669] udlfb: 1280×960 @ 85 Hz valid mode
    [ 475.601671] udlfb: 1280×1024 @ 60 Hz valid mode
    [ 475.601673] udlfb: 1280×1024 @ 75 Hz valid mode
    [ 475.601675] udlfb: 1280×1024 @ 85 Hz valid mode
    [ 475.601678] udlfb: 1600×1200 @ 60 Hz valid mode
    [ 475.601680] udlfb: 1600×1200 @ 65 Hz valid mode
    [ 475.601682] udlfb: 1600×1200 @ 70 Hz valid mode
    [ 475.601684] udlfb: 1600×1200 @ 75 Hz valid mode
    [ 475.601686] udlfb: 1600×1200 @ 85 Hz valid mode
    [ 475.601689] udlfb: 1792×1344 beyond chip capabilities
    [ 475.601690] udlfb: 1792×1344 beyond chip capabilities
    [ 475.601692] udlfb: 1856×1392 beyond chip capabilities
    [ 475.601694] udlfb: 1856×1392 beyond chip capabilities
    [ 475.601696] udlfb: 1920×1440 beyond chip capabilities
    [ 475.601698] udlfb: 1920×1440 beyond chip capabilities
    [ 475.601701] udlfb: Reallocating framebuffer. Addresses will change!
    [ 475.602371] udlfb: 800×600 @ 60 Hz valid mode
    [ 475.602374] udlfb: set_par mode 800×600
    [ 475.603728] udlfb: DisplayLink USB device /dev/fb1 attached. 800×600 resolution. Using 1880K framebuffer memory

    hwinfo command :

    60: USB 00.0: 0000 Unclassified device
    [Created at usb.122]
    Unique ID: 2UT6.bUSj+jd+0s8
    Parent ID: k4bc.9T1GDCLyFd9
    SysFS ID: /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0
    SysFS BusID: 1-3:1.0
    Hardware Class: unknown
    Model: “DisplayLink SUNWEIT USB Display”
    Hotplug: USB
    Vendor: usb 0x17e9 “DisplayLink”
    Device: usb 0x024c “SUNWEIT USB Display”
    Revision: “1.01”
    Serial ID: “00000000-001236”
    Driver: “udlfb”
    Driver Modules: “udlfb”
    Speed: 480 Mbps
    Module Alias: “usb:v17E9p024Cd0101dc00dsc00dp00icFFisc00ip00”
    Config Status: cfg=new, avail=yes, need=no, active=unknown
    Attached to: #59 (Hub)

    • Rob Willis

      As far as I know there is no workable multiseat model for any version of Ubuntu above 10.04.03. In that version Userful works well. Multiseat works sweet and is fast as can be in Fedora 17

  6. stephane

    Hi Bernie,

    This is good news.

    I have some questions, perhaps not directly linked to multi-seat… But this is probably the right place as the new DRM/USB driver has been introduced here.

    I’m currently trying to see how the displaylink framebuffer could benefit from any HW acceleration coming from the usual GPU on the motherboard (ex: integrated intel gpu, radeon gpu or even more unusual ARM GPUs etc.).

    I saw some projects involving virtual CRTC in the kernel, but this is far from mature (this is experimental and works only on radeon/x86). My goal is to have some acceleration on a Raspberry PI or a Beaglebone to be able to put a DisplayLink display in a car and play video, games etc. fluently.

    So my question is: do you know of any method that could be used to draw on the usual GPU screen and clone (=grab and copy) the screen content to the displaylink framebuffer. I’m not sure if Xorg server is able to do that out of the box (i.e. having 2 clones where one display would be primary (using GPU with accelerated driver) and the other would be secondary (udlfb with grab+copy mechanism).

    Furthermore, by doing that, it would be possible to have a single image cloned to multiple displaylink displays (could be used on some apps where one wants the same image on 2 screens without drawing twice). Example: I’ve 2 kids in my car and I install 1 beaglebone and 2 displays to play some video. The beaglebone would decode/render once but data would be sent to both displays…

    I’m currently doing some tests with latest stable kernel 3.5.4.

    Any idea is welcome.

    Thanks for you commitmnent on displaylink linux drivers.

  7. Don

    Hi

    I have a device with the DL-165 chip that was working fine as a second seat on a fresh install of fedora 17.

    When I upgdated FC17 and rebooted the DisplayLink adapter stopped working with a fast flashing led. I applied the actions above and it all worked again.

    After lots of playing I re installed a fresh FC17 from the CD. Then updated. Then applied the above actions and now the adapter gives a continuous green led but no display. Checked with FC17 live and its working there OK.

    loginctl does not show the adapter
    Its present in lsusb -v although with the line
    “** UNRECOGNIZED: 23 5f 01 00 21 00 04 04 07 00 01 01 00 02 04 00 bd 1f 00 06 00 01 01 07 00 01 07 05 00 01 02 02 05 01 01”

    dmesg also shows the adapter “[ 1.748114] usb 1-2: New USB device found, idVendor=17e9, idProduct=0198
    [ 1.748123] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    [ 1.748128] usb 1-2: Product: WS Tech USB-DVI
    [ 1.748133] usb 1-2: Manufacturer: DisplayLink
    [ 1.748138] usb 1-2: SerialNumber: 511409”

    If I take out the blacklist udl in /etc/modprobe.d/udlfb.conf and reboot then the adapter shows in loginctl and I can assign it to the second seat but it doesn’t survive reboot.

    Any help would be greatly appreciated

    Thanks Don

    • Bernie Thompson

      Fedora broke USB graphics devices with its kernel 3.6.2 update. It enabled udl (the DRM driver), which unfortunately still has problems (kernel panics in defio page handling). Worse, the Fedora build disables all non-DRM framebuffer drivers (like udlfb), so it’s not possible to just blacklist udl or compile udlfb as a module to get back to a working setup. The only solution is to go back to an earlier Fedora kernel version (3.3 series is best; later 3.4 and 3.5 series also ok).

  8. Don

    Thanks for getting back so quick Bernie. I have just tried your patch on FC18 with the latest updates and get the same result.

    This is not good news for all of us with DisplayLink devices. I see the latest still use the DL-165

    Is it not possible to defeat the FC code that disables non DRM?

    I’ve tried a second video card on my Atom MB but it chews too much resource to be practical defeating one of the best arguments for multi-seat.

    Don

  9. Pingback: AOC E2251FWU 22″ DisplayLink USB Monitor | Note To Self

  10. Mikhail

    OS: FC18, Laptop:Toshiba TECRA R840-10E
    I successfully blacklisted udlfb and after reboot, while loading the system it stucks on configuring WPA_SUPPLICANT.

    If disconnect my HSTNN-S02X device – fedora starts normally. Can you help me to sort out with this, please?

  11. Steve Button

    Hi,

    I’ve been searching for a Linux driver for my HP HSTNN-S02X and this is the only reference I can find that actually mentions Linux. I’m using Mint 16 which I installed today, which has 3.11.0-12 kernel. Would I be better off with FC? Happy to give that a spin.

    Thanks,

    Steve Button

    • Bernie Thompson

      Hi Steve – unfortunately, there isn’t yet a Linux distro where multiple monitors “just work” consistently for 3+ monitors. Too much churn in Linux for the many components involved with multiple monitors. Fedora is the distro that has given the most attention to this scenario, but they are also the ones that take the latest changes, which often break things in this area. So, sorry, we don’t have a solid recommendation for now. Lots of people have success here and there — if you’re committed, I’d duplicate one of those setups, down to the little details of components and versions.

Comments are closed.