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

[Roberto De Ioris]

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.

Obviously there are a lot of use for an fbcon driver, and surely your
approach (without a backing buffer) is the right path to follow for
embedded systems.

My idea is to have a single kernel module but with 3 operational-mode

1) total no-fb policy, with an xorg driver that manage all the blitting
operations

I have commited my current work (the 'nofb' branch) in this direction
at:

http://projects.unbit.it/hg/displaylink

(warning, it has a lot of bug, mainly the xrandr support is very messy)

2) full-fb support (as udlfb) with all the  low-impact compression
technics enabled.


3) light-fb support (as your approach) disabling all the compression
related things.


Last there is still my effort on using the displaylink device as an
additional crt, but all of my intel card are limited to 2048*2048
resolution, dramatically limiting my work.

I am trying to hack the radeonhd driver, but until October i will not
have time to work on this stuff.


I will give a look at your work ASAP, i am very interested in the defio
approach.

If you want i can give you an account in my repository so we can merge
efforts.


-- 
Roberto De Ioris
http://unbit.it
JID: roberto at jabber.unbit.it