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

[Roberto De Ioris]

> One interesting area of performance concern for Jaya's driver (once
> compression is added) is the 4KB granularity of defio - sending any
> unnecessary pixels over USB will hasten our most important bottleneck.
> 
> 
> There have been two solutions talked about:
> 
> 
> 1) (For X at least) provide an interface to supply damage information
> in addition to the touched pages:
> http://marc.info/?l=linux-fbdev-devel&m=123288616213965&w=2
> Jaya - did your patches work out?  What is the latest news on them?
> 
> 
> 2) Enhance defio to provide "shadow page" support, such that when a
> PTE is touched and backed, we also alloc a second page and take
> snapshot of the soon-to-be-dirty page before the client has changed
> it. Then we pass both before/after pages to the defio-supporting
> driver to do a more precise detection of differences. This consumes a
> little more memory (but less than the full shadow of the framebuffer
> we keep today), and a little more CPU.
> 
> 
> My loose preference is for #1, as X is such an important client.  But
> both possibilities are interesting. Is there one best answer?
> 


It is the same concept i used in udlfb and displaylink-fb but in a more
standard (and reusable) way. It works, it does not pollute (imho) the
fbdev layer, so i think it is the way to go.

Displaylink devices need to receive less data as possibile and the only
way to do it is to know thee coords of what has changed in the
framebuffer.


> 


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