Update on DisplayLink Linux support (udlfb in 2.6.34)

[Update Jan 2011: Udlfb was promoted from the staging tree to the main kernel (in drivers/video/udlfb.c) in 2.6.38. See documentation in the kernel tree at Documentation/fb/udlfb.txt]

A 10-part udlfb patch series with several enhancements were recently accepted into the Linux kernel staging tree of 2.6.34. Greg’s maintainer patch series passing them on starts here.

This catches the official kernel staging tree with everything on git.plugable.com up to Feb, 2010.

Background

udlfb provides Linux framebuffer (fbdev) support plus a private “damage” notification ioctl used by the Roberto DeIoris’ “displaylink” X server. Udlfb automatically detects and supports all current DisplayLink USB graphics chips – 120,160,115,125,165,195. It supports 16bpp, with modes up to the maximum supported by the DisplayLink chips. Plugging any DisplayLink device into a Linux PC with this support should result in a “green screen” which means udlfb has loaded, set the monitor default mode, and drawn to the device successfully.

What udlfb does *not* do on its own is make configuring X easy – X sits on udlfb, but getting X running still involves editing configuration files like xorg.conf in different ways depending on what you’re trying to do, what distro version you have, and what primary GPU you have.

Features in Linux kernel 2.6.34 so far

  • Improved performance (about 20% average improvement over a variety of “benchmarks” like x11perf, gtkperf, glxgears). Video playback, flash games, etc. are all improved
  • Asynchronous urb dispatch and no mutexes held for extended periods during render
  • Slightly lower CPU consumption, fewer non-localized memory accesses, slightly higher average compression
  • Better handling of switching from X to fbcon VTs and back
  • Driver unloads more cleanly from either bottom-up (USB removal) or top-down (shutdown). Problem reports welcome.
  • More standard EDID parsing and mode handling, using fbdev’s built in mode libraries (but creates a new dependency on them being enabled in kernel)
  • Performance metrics reported through sysfs (read /sys/class/graphics/fbX/*metrics* – but will move to debugfs)
  • 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
  • Support for standard fbdev clients (via defio) – unfortunately buggy yet (see todos)

Depending on timing, some additional todo items might make it, we’ll see.

Versioning

At one point, we wanted udlfb to have its own project cycles and release versioning to help clarify things here while udlfb evolved in the early days. Got pushback on doing this from the kernel maintainers. So versioning of udlfb is purely by kernel version – “this bug is in udlfb in kernel 2.6.34rc1” or whatever. There’ll also be a newer changes that haven’t been submitted to the kernel (e.g. at http://git.plugable.com/). And it’s probably best to just version that per commit/checkin. “This bug shows up in commit 234b4e22…”. This is nice in a way – just check the stuff in somewhere let the world know what you’re doing – the only “release process” you need to coordinate with is getting the patches into the kernel itself. Or feel free also to send patches here, we’ll try to help them through the process.

Todo

  • Add code to read pixel resolution limits from the device’s USB descriptors, and adhere to them. Avoids blank screen when monitors caps exceeds that of the adapter
  • Add pseudo-32bpp mode to help the case of using Xinerama to extend desktop across PCIe/USB adapters. Not planning true 24/32-bpp mode yet because of complexity and perf tradeoffs
  • Disable defio by default, unfortunately, because of several bugs without obvious solutions
    • rendering problems with pages (lines) that no longer get updated – writes to those are no longer triggering deferred processing
    • When running 2 USB adapters, dirty pages for one instance seem to affect the other, and vice versa (udlfb has no common state, so appears to be in defio or mmu handling)
    • cases where we hit a kernel oops in the deferred io handler when it tries to touch the pages it’s been asked to handle.
  • Move perf metrics from sysfs to debugfs and add ABI doc for what remains, per GregKH
  • Fix two ignored return values that Greg’s build environment caught
  • Get a safe method from DisplayLink to detect future chips that might not be compatible with current ones, and bail out of probe

There’s lot of other stuff that could be done – and any patches are very welcome. One big open question is whether fbdev has legs, or whether this effort should be converted over to KMS/DRM/DRI.

26 comments on “Update on DisplayLink Linux support (udlfb in 2.6.34)”

  1. xapient Reply

    just one question because i don’t know where else to ask.. the displaylink device fingervu706 shows ONE white line at the bottom of the screen (it does not in windows) – where is the right place to ask questions about this behaviour (and other things like powermanagment etc.)

    thx

    • Bernie Thompson Reply

      You can ask here. I may not be able to answer all questions, and obviously the testing here is with Plugable devices, but the work should apply to all DisplayLink devices.

      I’ve not seen the line at the bottom of the screen. What version of udlfb are you using (from where?) and how do you have X set up?

      Thanks,
      Bernie

  2. xapient Reply

    thank you very much… i found out today that is (at this time) not possible to power off the display right now (turn of the backlight)
    i can wait.

    the white line is somehow disturbing. it’s allways there even after
    “xset -display :0 dpms force standby”
    it is 1x800px at the bottom of the screen and it is already there when the screen turns green (unplugging the display and plug it in again makes the green screen appear again without a white line – but X is not coming back 🙁 )

    my xorg.conf is simple (again after trying out everything)

    Section “Device”
    Identifier “DisplayLinkDevice”
    Driver “displaylink”
    Option “fbdev” “/dev/fb1”
    EndSection

    Section “Screen”
    Identifier “DisplayLinkScreen”
    Device “DisplayLinkDevice”
    EndSection
    _________________

    modinfo udlfb says:
    vermagic: 2.6.35-14-generic SMP mod_unload modversions
    i am testing kubuntu 10.10 alpha3 (i need 2.6.35 – with older versions the whole screen stays white)

  3. Bernie Thompson Reply

    The version of udlfb in 2.6.35 doesn’t have dpms support. I’d recommend you build the latest module:

    sudo apt-get install module-assistant
    sudo module-assistant prepare
    git clone http://git.plugable.com/webdav/udlfb/
    cd udlfb
    make
    sudo make install
    sudo depmod -a

  4. xapient Reply

    with this version…
    —–
    (modinfo udlfb)
    srcversion: 2B12E8C20B255E7015B9F14

    xset -display :0 dpms force off (off/standby/suspend there’s no difference)
    —–
    …the screen actually turns black immediately but backlight comes back after 3 seconds.. still black – this time without the white line at the bottom.. (much better)

    still there is a white line at the bottom during normal use and there are some other issues: two out of three times the “xset” command produces a distorted picture instead of turning the screen off (it looks like an inproperly connected d-sub vga adapter)

    thx again: i will stay tuned and try “git clone” every week from now on 🙂

    xapient

    • xapient Reply

      any new information why the screen turns on backlight again after a few seconds “forced off” (for at least 4 seconds the screen is really OFF and then it comes back – it is still black but during night it shines a bit to bright ^^ )

      • Bernie Thompson Reply

        Hi Xapient – Sorry, no, I don’t know why it would come back after a few seconds. I’m not seeing that behavior. I’m suspecting there’s something about way X is configured that triggers it to wake/unblank periodically.

        You might want to add a dl_err printf to the udlfb_blank() function in udlfb.c, sudo make install and sudo depmod -a, and then tail -f /var/log/kern.log to watch what’s happening. It would be good to know if the backlight is coming on because udlfb is being told to do so (by X), or if it’s something else more mysterious.

        Cheers,
        Bernie

  5. xapient Reply

    hi bernie,
    i would like to do what you suggested, but there is no udlfb_blank() in udlfb.c (fresh git clone)

    at the moment /var/log/kern.log says:
    “udlfb: wait for urb interrupted: ffffffc2 available: 0”
    (after invoking the dpms force off command.)

    greets, xapient

      • xapient Reply

        oke.. thank you… i could need some help … how exactly do i have to write this line… if i add >> dl_err(“some error”); <> if (blank mode != …. <<

        i get the message "some error" when turning the screen off in kern.log – but thats not what i want.. or is it ? 😉 sry.. i forgot to say "i'm no programmer" just an advanced enduser…

  6. Thor Reply

    Hi

    I’m considering buying a plugable device, but I’m pretty confused on whether or not it will be supporting any type of hardware acceleration. I’m fully aware that a usb device in itself will not be able to give me any hardware acceleration, but for the Windows drivers on the DisplayLink website it states that E.g. OpenGL is supported in windowed mode, not quite sure how this works, but I imagine the primary graphics card will handle the OpenGL rendering and then the DisplayLink driver will copy from the graphics memory to the usb port. Please correct my if I’m wrong. Now I’m running on Linux, and would of course like to know if it’s possible to do something similar for linux? Is it or will it be possible to use OpenGL accelerated graphics on Linux?

    • Bernie Thompson Reply

      Hi Thor,

      Thanks for your question!

      Yes, on Windows the DisplayLink drivers hook themselves into the primary GPU stack, so they do make use of the primary GPU on the system for all Direct3D rendering.

      On Linux, this is not normally the case today. The X server and OpenGL have a framebuffer to write to (the framebuffer provided by the open source udlfb kernel module that then talks with the DisplayLink device). In theory it could make use of some GPU resources to do 3D rendering before writing to the framebuffer, but doesn’t today.

      There’s a project to head in that direction, called PRIME, but it’s just under development, and not yet thinking about USB graphics integration. http://www.phoronix.com/scan.php?page=news_item&px=ODA4NQ

      Another thing roughly similar, is adding Displaylink support directly into another accelarated X driver. A proof of concept was developed on Intel, but has not been actively updated since: http://lists.freedesktop.org/archives/libdlo/2009-October/000400.html

      So, in short, USB graphics on Linux is CPU rendered today. It’s quite low-latency, but not good for OpenGL or Compiz, etc.

      While there’s no fundamental reason it needs to stay that way, it will take a significant amount of development to abstract “rendering” from “output” across all the Linux components in a way that will make USB graphics be able to use the full resources of any GPU(s) on the system. Things are headed that way, it seems, but slowly.

      Another quick note – Plugable currently only has automated distribution in the USA, so we may not be able to reach you (saw you’re at a .dk address). Thanks, though! – this information helps others.

      Best wishes,
      Bernie

  7. Pingback: USB 2.0 To DVI / HDMI /SVGA Adaptor

  8. @onstocks Reply

    Got DisplayLink, love the product, the box came with HDMI and 2048×1152 capability. Took 2 seconds to install on windows. I’m having the green screen issue on Linux though. Has there been any success in creating a quick solution to getting the second screen working as extended on Linux yet?

    Thanks,
    @onstocks

  9. Bernie Thompson Reply

    Hi @onstocks – unfortunately, no major breakthroughs. There is still no support in Linux for rendering across multiple heterogeneous graphics adapters (other than at a higher level, like the older Xinerama solution does).

    The biggest recent news is work by David Arlie on a KMS/DRM driver based on udlfb (details here: http://lists.freedesktop.org/archives/libdlo/2011-February/000878.html) which would mean the DisplayLink driver is more of a peer of the Intel, nVidia, and ATI drivers. But it still won’t solve the multiple adapter limitation.

    So unfortunately, Linux just has some fundamental limitations right now.

    Sorry for the bad news,
    Bernie

    • @onstocks Reply

      That is bad news. I’m pretty sure my Windows 7 is compromised. Just want to confirm, – the DisplayLink Model is UGA-2K-A hooked up to a second monitor. This currently is not capable of running on Ubunto 11.04 – AMD Athlon II x64 ?

      • Bernie Thompson Reply

        Hi John – The issue isn’t that the device isn’t capable (Ubuntu 11.04 will recognize and install the udlfb framebuffer driver, as you’ve seen – the green screen means the open source driver has loaded and everything is working as expected).

        The limitations are at a higher level – configuring X to do what Windows 7 does with Multiple monitors is not easy or in many cases possible. We try to be blunt about it, because we want to make it clear that Linux/X will not give a “Windows experience” for multiple monitors (which is what most people expect, so they walk away disappointed). We want people to walk in with their eyes open.

        But if you’re feeling ambitious and are willing to do some advanced xorg.conf configuration, reference http://displaylink.org/ or our posts at http://plugable.com/category/udlfb/

        But for most Windows users, configuration is too complex – thus the warning about limitations of multi-mon on Linux today. Hope the background helps, even if the story isn’t a happy one. Thanks! Bernie

  10. Sannu Reply

    How about using VirtualGL to get OpenGL calls accelerated by the system’s graphics card? It seems there is some security issues but what is the implications of this in a home users perspective? Is it possible to get OpenGL acceleration and hardware video decoding with this method?

    • Bernie Thompson Reply

      VirtualGL definitely looks like a good thing to draw from, for anyone who wants to work on OpenGL support for USB devices. Thanks for the link.

      • Sannu Reply

        I can try to make some udev rules, scripts or library so that all applications that are launched will get accelerated (without user explicitly using ‘vglrun’ command). I will be glad to help and play around with that but I need help from someone to test those as I don’t have a display link device with me.

    • Bernie Thompson Reply

      Hi Sannu,

      Thanks so much for putting that in a post! Wonderful!

      We’re hoping to have some time to try the steps here soon. Also, you may want to send an email to http://lists.freedesktop.org/mailman/listinfo/libdlo with a link to your post – there’s a larger audience there who might be very interested.

      Thanks!
      Bernie

  11. Lorenzo Reply

    I’m getting this on boot, repeatedly, and holds up boot until I unplug the device:
    udlfb: wait for urb interrupted: ffffffc2 available: 4
    http://pastebin.com/s5YqWGtz

    any ideas? trying to get this working. I’m dieing inside waiting to use my 3rd monitor. so much clutter on my second.

Leave a Reply