[Libdlo] [RFC 2.6.30 1/1] defio fbdev displaylink implementation

[Greg KH]

On Tue, Sep 15, 2009 at 02:36:03PM +0200, Roberto De Ioris wrote:
> On Tue, 2009-09-15 at 18:36 +0800, Jaya Kumar wrote:
> > Hi Friends, Greg, Roberto, Bernie,
> > 
> > I'm new to the libdlo mailing list. Greg was kind enough to send me a sample
> > DisplayLink device and I've been experimenting with it using the interesting
> > libdlo library and also the excellent udlfb driver.
> > 
> > I wanted to share some of the code that I've been writing to make it work on
> > embedded devices (I'm currently testing it on a BeagleBoard B6). I have
> > written a new fbdev driver for the controller and I hope it can be of some
> > interest or use to the libdlo community. I've appended it as a patch against
> > the 2.6.30 omap tree. I think it should also apply cleanly to other trees if
> > others are interested in working together on it.
> > 
> > Here are some features that I focussed on for this driver:
> > - use of defio. This enables it to work transparently with existing
> > userspace fbdev applications, such as Xfbdev. I've been testing it with the
> > unmodified Xfbdev from the beagleboard OE distro.
> > - avoiding the use of a backbuffer and keeping memory use low
> > - use of URB queuing
> > - looking like a typical fbdev driver and using standard edid and
> > screeninfo structures
> > 
> > I haven't done any optimization or cleanup on the implementation yet. I
> > am planning on putting multiple stride24 commands per urb and also to try
> > to make the Huffman encoding mechanism from Florian's tubecable work here.
> > I would welcome any patches and improvements and would be happy to also
> > test with other embedded devices if anyone wants to send me some. :-)
> > 
> > Okay, I hope this is of interest and I welcome your feedback.
> > 
> > Thanks,
> > jaya
> > 
> > ps: anyone going to the FOSS Dev Camp in Portland next weekend?
> 
> 
> 
> Hi Jaya, i have done a lot of tests during this summer, and i have
> reached the conclusion that best performance and lowest memory footprint
> (for an X11 environment) would be to expose the urb buffer to user space
> (via mmap) and let the X11 driver do the blitting stuff and limiting the
> kernel to initialize the device and doing modesetting.

Ick, no.  If you are going to want to do that, just use usbfs to send as
many urbs as you want.  We can do this from userspace at line-speed
quite easily, no need to mmap buffers and such.  So no kernel driver
would be needed, unless you want to tie into the KMS settings (which I
recommend).

thanks,

greg k-h