Re: [PATCHES] remove direct access to fb module from exa
On Mon, 2009-02-02 at 01:30 +0100, Maarten Maathuis wrote: On Sun, Feb 1, 2009 at 5:11 PM, Maarten Maathuis madman2...@gmail.com wrote: On Sun, Feb 1, 2009 at 1:16 PM, Maarten Maathuis madman2...@gmail.com wrote: On Sun, Feb 1, 2009 at 3:40 AM, Maarten Maathuis madman2...@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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCHES] remove direct access to fb module from exa
On Mon, 2009-02-02 at 16:08 +0100, Maarten Maathuis wrote: 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. What I mean is to build e.g. fbcopy.c into libexa.so, mangling the symbol names to something like exaFbCopyRegion if necessary. 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. Still, may want to wait until you can rule out a problem with these patches? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCHES] remove direct access to fb module from exa
On Mon, Feb 2, 2009 at 5:27 PM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-02-02 at 16:08 +0100, Maarten Maathuis wrote: 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. What I mean is to build e.g. fbcopy.c into libexa.so, mangling the symbol names to something like exaFbCopyRegion if necessary. It would require modifying fbcopy.c, partially because i need return values on some of the functions. I would also have to split the file up, because half of that file is not machine independent. I could perhaps strip out a part of fbcopy.c and move it to mi. As long as it doesn't require fixing code i don't know. 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. Still, may want to wait until you can rule out a problem with these patches? Normal X gives no regressions and just using wfb with linear accessors (1:1 usage of memory address) is fine too. I see no reason to hold up these patches for those reasons. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
