<div>Thanks so much Roberto, Jaya, and others for all this progress.  By the way, all of this work was very visible at both the Linux Plumbers conference and X Developers conference last week.  We were able do so several multiseat demos (recreatable with the steps at <a href="http://libdlo.freedesktop.org/wiki/MultiSeatTerminal">http://libdlo.freedesktop.org/wiki/MultiSeatTerminal</a>). People were very impressed with it working plug-and-play and with the good performance. Several good discussions were triggered.  So all this work is being seen, thank you!</div>
<div><br></div><div>So now the trick is answering these questions on right way(s) forward.  My assumption has been we need to get down to a single kernel mode driver codebase, that we&#39;d like to get included by default in the distros -- and right now we have three (older udlfb and newer displaylink-mod from Roberto, displaylinkfb from Jaya). And there&#39;s the question of how much smarts should stay above/below the kernel line. So how do we consolidate?</div>
<div><br></div><div>Jaya&#39;s list of goals from the start of this thread all look very positive.  Because the framebuffer interface is (at the surface at least) such a good match to the DisplayLink hardware, keeping as much capability in the framebuffer driver as possible is good (lets us support standard fbdev user-mode clients who aren&#39;t displaylink aware) -- while also keeping it simple and allowing user-mode clients to take over displaylink-specific rendering in a controlled fashion if they really want to optimize (and we still need to settle on that mechanism).</div>
<div><br></div><div>One interesting area of performance concern for Jaya&#39;s driver (once compression is added) is the 4KB granularity of defio - sending any unnecessary pixels over USB will hasten our most important bottleneck.</div>
<div><br></div><div>There have been two solutions talked about:</div><div><br></div><div>1) (For X at least) provide an interface to supply damage information in addition to the touched pages:</div><a href="http://marc.info/?l=linux-fbdev-devel&amp;m=123288616213965&amp;w=2">http://marc.info/?l=linux-fbdev-devel&amp;m=123288616213965&amp;w=2</a><br>
Jaya - did your patches work out?  What is the latest news on them?<div><br></div><div>2) Enhance defio to provide &quot;shadow page&quot; 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.</div>
<div><br></div><div>My loose preference is for #1, as X is such an important client.  But both possibilities are interesting. Is there one best answer?</div><div><br></div><div>Also, at XDC there was some discussion of benchmarks (to help compare and guide our choices here).  It got some good laughs in the room, as good X benchmarks are a dismal science.  Chris Wilson is helping to look into some Cairo-based benchmarks, but until then for any comparisons I&#39;m doing, I&#39;ll be simply using gtkperf and glxgears at default-window and full-screen sizes - and I&#39;d like to add a mplayer -fb test with a standard piece of content.</div>
<div><br></div><div>Again, thanks so much to everyone contributing to this.  Any thoughts on any of it?</div><div><br></div><div><div class="gmail_quote">Best wishes,</div><div class="gmail_quote">Bernie</div></div>