[Libdlo] Status of defio support

[Bernie Thompson]

The original udlfb and displaylink-mod from Roberto rely on a private
ioctl to notify the driver what areas of the framebuffer have been
damaged, and should be sent to the device.

This means that Roberto's custom X server, which sends this ioctl
based on X damage events, works great, but all other standard fbdev
clients which use the mmap interface won't.

Jaya's defio module (used by several other framebuffer drivers, e.g.
e-ink ones), mmaps the framebuffer in a different way - writes fault,
defio accumulates dirty pages, then the driver is notified of those
dirty pages on a deferred basis.  This eliminates the need for a
private, non-standard ioctls to be sent by clients for virtual
framebuffers that live in normal system RAM.  All normal clients can
work. On the downside, the damage info is much less precise, so having
a shadow framebuffer allocated becomes more essential, and it takes
extra CPU cycles to scan it to hone in on just the changed pixels.

The udlfb driver work recently has been towards merging both methods,
supporting both types of clients in a almost-best-of-both worlds kind
of way.

Currently, it has the following characteristics:

* All custom or standard fbdev clients are supported
* It has a compile-time dependency on defio and the sys_ virtual
rendering functions to provide the compatibility with standard
clients.
* It tries to allocate a hw shadow framebuffer for both scenarios, but
can still run if the allocation fails.  If that happens, defio clients
will run much more slowly, damage ioctl clients only a little slower.
Shadow on/off can easily become a module option in the future (e.g.
for embedded scenarios where memory is more precious than render
performance).
* Once the private damage ioctl is called the driver assumes the
client knows how to send more precise damage, and stops doing any
defio deferred rendering, relying only on the ioctl damage info. As it
stands, defio is still running and it still takes faults, however, so
that incurs some overhead.
* Unrelated to defio, it uses the standard in-kernel EDID processing
functions, eliminating the drm_edid.h header confusion, etc. - but it
has a dependency on them being present.

What problems remain before a patch can be submitted (with defio and
related performance and other features currently at git.plugable.com)?

1) With defio, pages sometimes don't seem to have their write fault
set up properly, resulting in a persistent black line on the screen. I
see an avg of one or so on a 1920x1080 16bpp screen (which takes 1013
4K pages to map it). Often don't see it on smaller resolutions.
Perhaps a race at mmap time?
2) With defio, running multiple non-X clients on 2 or more DisplayLink
screens will consistently fault in deferred IO processing in udlfb
(you'll see it in dlfb_render_hline) A scenario where a page isn't
mapped in?
3) No 24/32bpp support, which would ease or clarify the Xinerama problems
4) A longer list of smaller things

Repros and ideas on these problems 1 & 2 are welcome.  And as always
feedback or better ideas on any of it. I'd love to have a patch series
soon (within 2.6.34 cycle), which covers all the big-ticket items
udlfb will need, and leaves only minor patching to go, if any.

On the issue of whether udlfb needs to take the dependencies on defio,
etc. -- on balance, I think it's the best choice.  By supporting
standard fbdev clients fully (and once we have 24/32bpp support), we
can eliminate a ton of confusion, as questions of "how do I get udlfb
working?" can be answered (for better or worse) with "the same as any
other framebuffer driver"

Now, could udlfb be flexible enough to build anyway, falling back
completely into private ioctl mode, if the dependencies aren't
present?  Perhaps, but it's pain and it's not typical.  There are
several other framebuffer drivers that have dependencies on the same
stuff we do.  That kind of configurability would be both a blessing
and a curse ("it built. Why won't standard fbdev X servers and apps
work?").  I wouldn't choose to prioritize the effort until/unless we
get feedback from the distros that they won't take drivers with these
dependencies (but there's good evidence they already are).

So again, it's all about progressing what's in the standard kernel
tree, and getting higher-level configuration support into the distros
-- at that point, it can be plug and play. Until then, caveat emptor -
this is only for early, advanced users.

Best wishes,
Bernie