[Libdlo] defio mmap issue

[r10kindsofpeople]

Bernie and Justin,

Is there any further news on this?  I seem be experiencing the
artifacts (using udlfb with #undef CONFIG+FB_DEFERRED_IO commented
out, and QtEmbedded under Ubuntu Server 10.04).   Does the patch work,
and if so, is there any easier way to get to the same end?  I'm still
climbing the learning curve, and frankly, the patch without any
details on how to implement it is a little intimidating.

John

{Sorry for the crude cut-n-paste below to establish context, I've been
trying to read through the archives but only just joined the list}

>Hi Bernie,
>Thanks for the heads up. I'll do some testing and see how it goes.
>
>Justin

>On 26-May-2010, at 3:50 AM, Bernie Thompson <bernie at plugable.com> wrote:

> 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
>
> http://marc.info/?l=linux-fbdev&m=127369791432181
>
> 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,
> Bernie
> http://plugable.com/
>
> 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
>>