[Libdlo] Generic fbdev X server on DisplayLink devices

[Bernie Thompson]

Hi Alexander,

On Mon, May 31, 2010 at 4:55 AM, Alexander Todorov <atodorov at otb.bg> wrote:
> Hi Bernie,
> this is good news. Have you posted this patch to fbdev developers? If yes can
> you share a link/issue tracker for those interested to monitor the patch
> acceptance.

To be ready to run the patch review gauntlet, there's still a lot of
research to do on the interface -- figuring out why a similar effort
by Jaya was started and dropped in Jan 2009. Finalizing the details of
the interface.  I sent an email (not a patch) last week to the
linux-fbdev list but it didn't trigger any responses:
http://marc.info/?l=linux-fbdev&m=127446874215785&w=2

Thanks for offering to track and perhaps add a voice to get the patch
moving forward, once it's submitted. Will email when that's done.

> As of now there are two X server drivers on git.plugable.com: xf-video-udlfb and
> xf86-video-fbdev. What are their differences and which one is the preferred one?

Some of the work on udlfb over the last few months has been making the
fbdev support it in more generic, so that the generic xf86-video-fbdev
driver can run on it.  That works on 2.6.34+ with defio support
enabled.

But for when defio is off -- as it is currently by default in the
git.plugable.com branch for fundamental performance reasons, and
(hopefully temporary) quality reasons -- all that's needed for the
generic fbdev driver to work is to be able to send notifications to
udlfb about what regions of the framebuffer have been touched. The
git.plugable.com branch of xf86-video-fbdev adds that damage support.

There's no performance or functional advantages to the
displaylink-specific X server (xf-video-udlfb) -- there never was any
essential device specific code there -- and for my own work I've moved
completely to xf86-video-fbdev.

So the hope is we're now able to drop the maintainance burden of a
separate displaylink-specific X server, without any loss of
functionality.

But we'll still need to have patching efforts going to add any
essential functionality to fbdev (for now, damage support -- perhaps
in the future, enhancing generic fbdev's randr support).

Hope that makes sense. :)

Thanks for tracking this,
Bernie