No subject

automatically on this distro (and others), even if they don't yet do
anything useful out of the box. :)

Ubuntu 9.10 includes the 2.6.31 kernel and automatically finds and
loads the modules from the staging tree, including udlfb.  The distro
doesn't have anything else yet (doesn't have Roberto's X server).
And, of course, current versions of xorg still auto-configure only PCI
graphics controllers with its hal enumeration, so xorg.conf needs
customized for usb displays yet.  The version of udlfb in staging does
not have dynamic mode setting, but otherwise relatively functional,
decently performant, and ready for fbdev client applications to use
it. Any fbdev clients anyone is using, other than X itself?

Building on this kind of thing, hopefully progress can be made on
merging the best parts of the DisplayLink kernel driver branches out
there now (udlfb, displaylink-mod, displaylinkfb, and freebsd udl) and
continue progress moving the Linux driver from staging into the main
kernel.  The patches I've been using are checked in at
http::/git.plugable.com/  -- including some performance work, support
for displays over 1650x1080, and playing with removing the backbuffer
allocation entirely to look at performance numbers. At this point, I'm
patching against displaylink-mod, but thinking perhaps the most
expedient path forward to get in the mainline as early as possible is
bringing udlfb up to snuff?

For the X server, I've been using Roberto's xf-driver-displaylink
server. Best case, we'd want 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) from the displaylink server to the fbdev server in a
standardized way over time.

The purpose of libdlo as a user mode library is still unclear --
perhaps just a reference implementation -- but it will definitely need
updates to defer to a kernel framebuffer driver, when present, to
manage ownership of the device.  It's obviously not useful to include
libdlo in isolation in distro plans.

This is kinda unrelated to DisplayLink, but for multiseat, Ubuntu 9.10
breaks things initially with the new GDM 2.28 version (gdmdynamic is
now broken/gone), but it is replaced with the new ConsoleKit support
which is the future, so it's a foundation for porting things to that.

On the extended desktop side of things, things are perhaps less clear.
 For Roberto's leading-edge work on adding framebuffers as additional
CRTCs within Intel/ATI/nVidia X servers, I'd assume the resolution
limitations (e.g. 2K limitation of current/older Intel chips) will
recede over time, making this a viable strategy.  But it seems like
there should be more flexible ways of rendering to and adding
"offscreen" output surfaces as additional CRTCs, but perhaps the core
xserver needs significant work to factor out those things.

Some more background on the perf work mentioned above is at
http://plugable.com/2009/11/02/displaylink-kernel-framebuffer-performance/

Lots of work done and yet to be done here, by many disconnected
people.  Any thoughts, advice, or patches on any of this very welcome
of course.

Best wishes,
Bernie
http://plugable.com/