There are three codelines of Linux DisplayLink kernel frambuffer drivers currently in use:
- udlfb (Roberto De Ioris), which is in the Linux kernel staging tree of 2.6.31 and later, and is enabled by default in some recent distros (Ubuntu 9.10). Capable of working with all DisplayLink devices.
- displaylink-mod (Roberto De Ioris), which adds dynamic mode support and a few other minor changes
- displaylinkfb (Jaya Kumar), which tries out some innovative approaches (defio page-fault change detection), uses existing fbdev x servers without modification, but is much slower (80% slower on example test) than udlfb and displaylink-mod, which both use X damage information and RL/RAW compression
- udl (Marcus Glocker) for FreeBSD (not Linux) text/graphics console driver interface, which makes use of damage and ports Huffman-style compression from Florian Echtler’s libtubecable library. This support is currently ahead of what’s on Linux.
You can get more information about these drivers at http://libdlo.freedesktop.org/wiki/HowTo
In general, most of the demos and videos posted here use displaylink-mod. Some performance improvement patches are available at http://git.plugable.com/, but they are a relatively small improvement.
So any conclusions of of the performance work so far?
- Graphics benchmarks on Linux are in rough shape. Most practical approach so far has been simplistically using a combination of glxgears and a few select tests from x11perf. Good video playback tests needed.
- Jaya’s displaylinkfb driver tries some interesting concepts, but the lack of damage information from X means it runs much slower (up to 80% slower) than the alternatives for now.
- The original RL compression in udlfb by Henrik Bjerregaard Pedersen is surprisingly effective, even though it only uses one of RLE or RAW for each 255 pixel segment. It’s relatively CPU-efficient with simple inner loops, and decently USB-efficient in practice.
- The alternating RL/RAW algorithm in the master branch at http://git.plugable.com/ does slightly better, but it varies per test and is not dramatic.
- The shadow/back buffer that udlfb and displaylink-mod keep do provide a significant gain on maybe one out of every 4 tests or so, but X’s damage information is quite accurate — so saving that allocation and the ongoing reads/writes to that extra memory by forgoing the back buffer is definitely viable and should at least be a module option. The ‘noback’ branch at http://git.plugable.com/ has this removed (despite what one comment checkin says), for anyone who wants to try it.
Perhaps the best and quickest path forward to getting support more widely distributed is
- Bringing udlfb up to snuff, since there are just a few functional changes in the displaylink-mod branch, and udlfb already is going through the staging->mainline confidence building process
- For the matching X server, it would be great to have kernel driver that works with both the standard http://cgit.freedesktop.org/xorg/driver/xf86-video-fbdev/ at some level of performance, or with the custom displaylink xserver at some (better) level of performance. Then move things (like damage support, which is key to performance) from the displaylink server to the fbdev server in a standardized way over time.
- Then there’s a bunch of other more involved work to come on configuration and coexistence with multiple graphics controllers. Rough plans are visible in the fog here, but they involve other projects and people.