[PATCH] exa: fix gnome-panel corruption
Maarten Maathuis
madman2003 at gmail.com
Mon Feb 15 07:40:48 PST 2010
2010/2/15 Michel Dänzer <michel at daenzer.net>:
> On Thu, 2010-02-11 at 20:06 +0100, Maarten Maathuis wrote:
>> 2010/2/11 Michel Dänzer <michel at daenzer.net>:
>> >
>> > Thanks for tackling this, Maarten!
>> >
>> > On Thu, 2010-02-11 at 19:05 +0100, Maarten Maathuis wrote:
>> >> - A mapped pixmap can't be used for acceleration, any decent memory manager
>> >> will refuse this.
>> >> - Source pixmaps may need updating, so move in the pixmap unconditionally, it
>> >> should be a no-op in most cases anyway.
>> >
>> > 'May need'? Have you actually observed this in practice? Only the mixed
>> > pixmap pointed to by pExaScr->deferred_mixed_pixmap should ever have
>> > valid bits in the system memory copy with no corresponding valid bits in
>> > the GPU copy. In which case the new code could still be conditionalized
>> > on
>>
>> Yes i have observed this in practice, the reason is "fairly" obvious.
>>
>> Do software rendering on full pixmap, do hardware rendering as src
>> with preg (driver pixmap created), do software rendering (sw pixmap is
>> killed, but not everything is in hardware pixmap yet).
>
> [...]
>
>> One possibility would be to put "exaDoMigration" with src with preg on
>> the deferred pixmap list, i haven't tested this, but i could try this
>> evening or tomorrow.
>
> Thanks for the clarification and for the extra effort to show another
> possible approach. I agree the first approach is cleaner.
>
>
>> > It should be possible to restructure the code such that the late_failure
>> > label and goto aren't necessary.
>>
>> You cannot assume the prepare access to succeed the 2nd time, although
>> it will in 99.99% of the time.
>
> No such assumption is necessary:
>
> * Call ExaDoPrepareAccess().
> * On success, do the new thing, call ExaDoPrepareAccess() again.
> * Take the current failure path if either ExaDoPrepareAccess()
> call failed.
But that will mean you need a goto, a for loop (in the beginning),
code duplication or something else. I just took the goto as least
invasive.
>
>
>> > Is there a bug report that can be referenced in the commit message?
>>
>> Not to my knowledge.
>
> http://bugs.freedesktop.org/show_bug.cgi?id=26076 ?
>
I forgot about that one, and somehow i didn't show up in my bug search.
>
> --
> Earthling Michel Dänzer | http://www.vmware.com
> Libre software enthusiast | Debian, X and DRI developer
>
>
>
Will send an updated patch this evening.
More information about the xorg-devel
mailing list