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

[Jelle de Jong]

Hi Bernie,

Thank you very much for the great detailed repose!

Bernie Thompson wrote, on 02-01-10 01:55:
> 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/

I am kind of a mulitseat expert, I professionally develop, maintain
and support them for clients, based on my own setup. Not based on
displaylink technology though. I only want to use the displaylink
device to add an additional monitor to my laptop for making my work
easer when doing administration work.

http://imagebin.ca/view/ihqtFJ7.html [demonstration system I brought
to HAR2009 for hackers to play with]

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

This is partly very good news. I needed to know if the technology was
in such shape that it could be used fully with complete F/OSS
technology. This in comparison with the proprietary FGLRX and NVIDIA
drivers that are still needed to get the full features of the
graphical cards. Causing for me a broken by design chipset.

I am wondering how far the project is from having all the needed code
inside the Linux kernel and the Xorg project. This is the beginning of
the plug and play experience. Having to do a lot of configuration
afterwards is not a direct issue for me.

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

I hope the developers are working too an xrandr compatible
configuration system. The idea of plug and play graphical cards will
be working some day, there are also laptops with on the fly switch
able graphics cards (intel <-> nvidia)

> 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.
> 
> From my perspective, until a device works out of the box with a
> distro, without end-user fiddling, it's not interesting.  So there
> just isn't anything interesting here yet for normal end-users, despite
> some good progress in some fundamental pieces in the last 6-9 months.
> 
> I don't mean to sound too negative, and I'm happy if someone else
> wants to express a rosier picture. But it's important to understand
> that Linux support that's on-par with Windows for scenarios like
> extended desktop is not something that's here today.  And it's unclear
> given the current level of community engagement when things might come
> together, but certainly more engagement from more people would speed
> things up.

I would be interesting in reading the options and expectations of
other developers that are making this great technology happen for Linux.

Seems I have to start looking for a SiS VGA chipset for an USB to VGA
adapters. The SiS drivers are included in Debian stable. [sisusb]

Thank you!

Kind regards,

Jelle de Jong