EXA glyph corruption
madman2003 at gmail.com
Thu Aug 28 12:15:11 PDT 2008
On Thu, Aug 28, 2008 at 9:01 PM, Daniel Drake <dsd at laptop.org> wrote:
> I'm working on OLPC's upcoming software release, including an update
> from Fedora 7 to Fedora 9. Fedora 9 ships xserver 184.108.40.2066.
> Unfortunately, we encounter a rendering bug with one of our applications
> (etoys). Certain components that move around the screen render badly
> (leave trails, etc) when interacting with the mouse cursor.
> An etoys developer narrowed this down to a small program to reproduce
> the issue:
> It moves a green square around the screen. If you let the green square
> move onto the mouse cursor, you get graphical corruption. See
> http://dev.laptop.org/~dsd/20080822/xshm-bug.png for a screenshot - the
> mouse cursor didn't get included in the screenshot, but it is in the
> white area inside the green square. The square should be solid green
> even with the mouse cursor on top.
> I noticed that Fedora recently added an "exa master upgrade" patch to
> their xserver test builds - backporting the most recent EXA code from
> master. Decided to give this a try in hope that it solves the bug.
> Here is the patch:
> The good news is that it solves the bug, here is a new screenshot:
> The mouse cursor is on top of the green square in that screenshot with
> no rendering glitches.
> The bad news is that text rendering is now quite badly broken:
> with the older X server build, that same screen looks like:
Getting your glyphs cut off is a "known" bug, on CURRENT master it
appears when you provide a composite implementation (then it enables
the glyph cache, previously it enabled it unconditionally), but
fallback at some stage during font rendering.
If provide a composite implementation, then i guess you don't support
rendering onto PICT_a8 surfaces (or PICT_A8 pixmaps at all)?
> I backported the updated exa code from master again, this didn't help.
> Jordan Crouse (geode driver author) also had a look at the text
> corruption. He thinks that EXA might be passing him the wrong glyph
> < CosmicPenguin> It looked to me based on whatever tag I was compiling
> against the other day that the mask I was getting was
> < CosmicPenguin> I only did enough work to verify that the driver was
> rendering correctly
> < CosmicPenguin> keep in mind that I may or may not be missing
> fontconfig or other support software for fully
> effective font fun
> < CosmicPenguin> I am not sure at what point from file to screen the
> was being mismanaged - all I know is that I was doing
> whatever I was told
> < CosmicPenguin> and thats not half bad
> Any ideas?
> We know that whatever caused the regression is some part of this patch:
> xorg mailing list
> xorg at lists.freedesktop.org
More information about the xorg