[Libdlo] dynamic modeset patch .. thank you sir, I'll have another

[Bernie Thompson]

As we know, we've got a lot of udlfb enhancements floating around, so
the knotty problem is getting them all properly submitted back to the
kernel.

I took a wrong approach first time around, trying to merge one
codeline wholesale, then merge the next, then fix, then enhance ...
Though it wouldn't be hard to fix up that first patch to resolve the
big issues, annoyances would remain, and future patches would replace
large chunks of the same stuff.

So, I'd like to shift back to take functional things one by one in a
more solid fashion, drawing from both Roberto's post-udlfb changes and
Jaya's displaylinkfb (defio) codelines.  A little more work, but fewer
and smaller individual patches, and less likely to cause angst I hope.

So one thing that hasn't changed is dynamic modeset based on EDID is
the most important missing feature of udlfb in the kernel tree,
probably the largest diff, so that's the focus still.  Depending on
how quickly patches are taken, this will be a 1/1 or may become part
of a patch series.

I'll have an email patch shortly, but for anyone who wants to get a
head start on identifying problems or any feedback (any testing would
be welcome), the work is also checked into git here:
http://git.plugable.com/gitphp/index.php?p=udlfb&a=shortlog&h=refs/heads/udlfb-0.2.3-01-dynamic-modeset

This patch will not contain any of the ioctl or (the larger portion
of) the refcount/mutex changes that caused problems with the first
patch -- we'll leave those to later.

As far as expectations -- based on the code and testing so far, this
should be functionally a little better displaylink-mod (now higher res
modes like 1920x1080 work, etc.), but still will have any race
conditions udlfb has.  It's still got all the endian and platform
issues of udlfb.  Performance-wise with X, it should be more
performant than displaylinkfb, equally performant to udlfb, but
perhaps slightly less than displaylink-mod (because of the missing new
ioctls).  Any results other than that would be good to hear about.

Questions on my mind with this first modeset patch:

* Is anything about this approach going to run aground process-wise or
technically?
* In the new probe(), is there any consequence to using vmalloc
without setting pages reserved, for framebuffer that will be mmap'd?
Based on docs in kernel remap_pfn_page() fn, and limited testing, it
appears to be fine on 2.6 kernels.  But most/all samples to date have
set vmalloc'd pages to "reserved" in this circumstance.  I'm motivated
to figure this out, because as we add defio support from Jaya's
driver, it'll be helpful to have both direct mmap and defio share a
common setup. But either way can work.
* I suspect the fbdev-devel list would have a bunch of valuable
feedback, if we reviewed patches through there.  Should we?  Avoid
cross-post how?
* Any other ideas, comments, or thoughts are welcome.

Todo list for future patches:
* Add some low-level perf metrics to help evaluate the impact of future patches
* Add sysfs attributes to reset and read those metrics
* Move to list of URBs and async dispatch to reduce CPU wait, keep usb busy
* Refcounting and synchronization - review and try to simplify, use
atomic ops, etc.
* Enable defio support, get standard fbdev clients to work universally
* Rework ioctls, look to get essential ones (damage notifications?)
added to fbdev generally
* Give DisplayLink-native user mode clients a command pass-through
mode (sysfs? ioctl/mmap?)
* Perf improvements like those queued up at
http://git.plugable.com/gitphp/index.php?p=displaylink-mod&a=summary
* ...

Thanks to Roberto and Jaya for their work on this driver.  This
modeset work is still just merging their stuff (in particular, taking
a lot of Jaya's for the first time).

Bernie