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