[Libdlo] would like some advise about the sustainability of the libdlo project

[Bernie Thompson]

Hi Jelle,

I'll try to write up a shot at a longer answer here, because this is
clearly the top-line question.

In short - for "normal" end-users who want an experience like Windows,
USB displays (from any vendor) can't be configured easily on any Linux
distro today.  It's not anywhere near where Windows or Mac is, in
terms of ease of configuration. Once you get it running, however,
rendering performance is competitive.

So it's for adventurous or advanced users only, and is likely to
remain that way for some time.

In the case of DisplayLink chips, the problem isn't information about
how to program the device.  Everything needed for a performant
solution is in open source code, and works in particular, limited
scenarios combined with careful, rather complex configuration: e.g.
http://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/

There's a kernel framebuffer driver in the kernel staging tree, and
it's getting updates even as primary ownership of the driver has been
wobbily handed around to 3 different developers in its first 6 months
of life (by the way -- Greg recently picked up the dynamic mode
setting patch posted last month, for the 2.6.34 kernel, which is
great).

There's lots more than can be done in udlfb -- e.g. the support for
the standard xf86-video-fbdev X driver, which is at git.plugable.com,
and will come as a patch when it's code review worthy; 24/32bpp
support; porting Florian's rendering stuff, etc.

But nothing that can be done in a kernel framebuffer driver or an X
server alone, will make it possible for things to "just work" on Linux
(if anyone wants to argue differently, that'd be welcome).

The key configuration problems that need solved with USB displays on
Linux are tied up on other big changes happening with the way graphics
works and is configured on Linux, some of which are being worked on,
some not -- but all are moving targets owned by many different groups
of people.

For the last several years, xorg has focused on auto-configuration of
devices, but that support is only for standard PCI connected graphics
adapters.  There's some more flexibility in upcoming org releases, but
it's not clear how easily or when distros will be able to pick up USB
display auto-configuration.

To play in that system, it's likely you'll want a driver written to
the new kernel mode setting model (which include framebuffer
interfaces as a subset).  They have 4 drivers written to those new
interfaces (intel, ati, nvidia, vmware), and have expressed that
they're working to stabilize with those, with the expectation that
additional devices will be developed later.  So it's unclear whether
the current investments in the udlfb fbdev driver is the right
approach long-term, or whether effort should switch to KMS.

For supporting a single extended desktop with multiple adapters, xorg
is in transition from xinerama to xrandr.  But things are not working
even for multiple PCI adapters yet
(http://ubuntuforums.org/showthread.php?t=1058961), so adding USB into
the mix is yet more in the future.  There's other issues like render
sharding, etc. too.

Also within xorg, there's a split between traditional 2D X (and the
significant benefits of things like the damage extension for low
bandwidth busses), and a 3D desktop composition model. Beyond a
simpler render codepath, not using 3D composition is the primary
reason by Linux is much snappier on USB displays than Vista, Win7, or
Mac even today -- but only when not running compviz, etc.

For supporting each graphics device as it's own terminal (the scenario
I've tended to focus on), again things are in transition -- e.g. GDM
moving from gdmdynamic to consolekit for the launching of terminal
instances, amongst other things.

And of the distributions in use today, there's unfortunately a
confusing mish-mash of different incompatible versions of all these
different evolving pieces.  Writing one description of how to get
things working has become impossible.  There's always a lot in flux on
Linux, but it seems like it's particularly so right now.