[Libdlo] defio mmap issues

Bernie Thompson bernie at plugable.com
Tue May 25 12:50:52 PDT 2010

Just an update on this problem (detail below) of horizontal artifacts
with defio enabled in udlfb, and then using a standard (non-damage
aware) mmap client like the generic fbdev X server ....

Others ran across these same problems in a different (non-DisplayLink)
context, and are working on a fix.  I've not tested these patches to
defio yet, but they may resolve this issue


Note: There's some further discussion on the list, so this is likely
not the final patch they'll run with.  But it's great that there
appears to be a fix on the horizon for this.

Best wishes,

On Wed, Jan 13, 2010 at 4:36 PM, Bernie Thompson <bernie at plugable.com> wrote:
> On Mon, Jan 11, 2010 at 6:57 AM, <justin at dynam.ac> wrote:
>> On a side note, and maybe for a latter email, I'm also getting horizontal
>> artifacts on the screen after several hours of operations. Reading the
>> archives, I saw someone else post on this, and there was a thought there
>> was a race condition on the memmap. This is very reproducible for me
>> (takes about 1 hour though) so if I can provide further info to help debug
>> that, I'm willing to take on the challenge!
> Here are some datapoints from trying to track down this issue:
> * The problem happens both with the latest udlfb from git.plugable.com, and
> with jaya's original defio driver patch posted a few months back. So it
> could be a problem carried forward, but it doesn't look like a new problem
> ..
> * It can be seen more frequently with faster processors and larger screens.
> On my atom with 1920x1080, it's intermittent and small corruption.  On a
> faster Celeron with 3 1680x1050 screens, it starts happening quickly with
> any significant screen activity.
> * And a fun one: on that multi-screen setup, once you get large areas of the
> one screen (one DL device) to fail to render ... then moving the mouse and
> triggering rendering on the *other* DL device/screen, for the corresponding
> lines on the screen, refreshes the first device/screen properly (!)  Since
> udlfb keeps no shared state between different DisplayLink devices,
> apparently this confusion is happening at the defio/vma/page table level.
> Defio is used by several other framebuffer drivers, but perhaps not at these
> resolutions and not for multiple screens.  Has anyone seen other evidence
> that would support/contradict this being a general defio problem?  Or
> perhaps something simple/stupid that udlfb is doing to trigger it?
> Thanks,
> Bernie

More information about the Libdlo mailing list