[PATCHES] remove direct access to fb module from exa

[Maarten Maathuis]

On Mon, Feb 2, 2009 at 2:35 PM, Michel Dänzer <michel at daenzer.net> wrote:
> On Mon, 2009-02-02 at 01:30 +0100, Maarten Maathuis wrote:
>> On Sun, Feb 1, 2009 at 5:11 PM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>> > On Sun, Feb 1, 2009 at 1:16 PM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>> >> On Sun, Feb 1, 2009 at 3:40 AM, Maarten Maathuis <madman2003 at gmail.com> wrote:
>> >>> In the spirit of correctness and wfb compatibility a few optimisations
>> >>> had to go, but nothing serious.
>> >>>
>> >>> I'll commit this soon'ish if there are no (serious) comments.
>> >>>
>> >>> Maarten.
>> >>>
>> >>
>> >> This new patchset fixes exaValidateGC, so it only changes patch 0004.
>> >>
>> >> Maarten.
>> >>
>> >
>> > This time 6, 7 and 8 changed. Quite a serious bug actually. See the
>> > comment in patch 6 for details.
>> >
>> > Maarten.
>> >
>>
>> Forgot a few cases.
>
> exaImageGlyphBlt served as damage control to avoid migration ping-pong
> with core font rendering. It might be nice to benchmark this and see if
> it's still relevant, and if so try to preserve it by calling down to the
> lower layer and possibly copy some helper functions.
>
> It looks like part of patch 6 fixes a problem introduced by a previous
> patch? If so, just fix that patch directly, or at least split out that
> part into a separate patch.
>
> I'm slightly uneasy about copy'n'pasting large parts of fb code as in
> patch 8, if possible it might be better to build the original code into
> EXA, possibly with symbol mangling as required.
>
>
> Otherwise looks good to me; so, does this allow you to use EXA with wfb?
>
>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
>

Here is the corrected patch set.

The problem about mangling with fb symbols is that you need to do it
at runtime, that would turn out to be very awkward, not to mention
incorrect. For fallbacks we need to obey the wrap chain at all times.

I will check if core font rendering is somehow slow, but i wouldn't
know any correct fix.

The case of patch 8 is something i cannot avoid, since fallbacks have
to go through a wrapped function, that means i need a boolean return
value, instead of void. Making brand new code seemed more error prone.

And yes, with this you can load and run wfb without crashing, my first
attempts haven't resulted in correct rendering, but i'm probably
misunderstanding the memory layout for my particular hardware.

Maarten.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-exa-Remove-one-of-the-many-calls-directly-into-the.patch
Type: application/octet-stream
Size: 2163 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-exa-kill-of-exaImageGlyphBlt.patch
Type: application/octet-stream
Size: 4551 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-exa-add-GC-private.patch
Type: application/octet-stream
Size: 2417 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-exa-properly-wrap-GC-functions.patch
Type: application/octet-stream
Size: 17109 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-exa-use-proper-wrapping-in-exa.c.patch
Type: application/octet-stream
Size: 9324 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-exa-wrap-the-remainder-of-exa_unaccel.c.patch
Type: application/octet-stream
Size: 2821 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-exa-create-ExaCheckGetImage.patch
Type: application/octet-stream
Size: 2647 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0006.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-exa-properly-handle-CopyArea-and-friends.patch
Type: application/octet-stream
Size: 15647 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20090202/18620441/attachment-0007.obj>