Bug 94775 - exaGlyphs() ignores the given operator unless a mask format is specified
Summary: exaGlyphs() ignores the given operator unless a mask format is specified
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/EXA (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-01 09:08 UTC by Uli Schlachter
Modified: 2016-05-10 02:27 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Example program demonstrating the problem (5.32 KB, text/plain)
2016-04-01 09:08 UTC, Uli Schlachter
no flags Details

Description Uli Schlachter 2016-04-01 09:08:51 UTC
Created attachment 122658 [details]
Example program demonstrating the problem

Thanks to the help of many people with the final hint coming from Michel Dänzer on IRC, I finally figured out https://github.com/i3/i3/issues/2248.

To reproduce this issue, run the attached program (gcc -Wall -Wextra -O2 test.c $(pkg-config --cflags --libs xcb xcb-render) && ./a.out). The expected result is an override-redirect window in the top left corner of the screen showing "something black" on a yellow background. However, the actual result is white instead of black.

I *think* (but have no way to actually verify this) that this is because in xserver/exa/exa_glyphs.c the function exaGlyphs() ignores its "op" argument unless a mask format is specified. My test program does not use a mask.

A partial fix would be pass an operator to exaGlyphsToDst(). However, that could produce incorrect rendering with intermediate flushes and some operators that cannot easily split (e.g. Out).

Another possible fix could be to just use a temporary pixmap, even if no mask format was specified, when an operator other than Over is used (Over is hardcoded in exaGlyphsToDst()).

Since I cannot reproduce this problem myself, all of the above is just a theory.
Comment 1 Michel Dänzer 2016-04-01 10:04:56 UTC
Possible fix: https://patchwork.freedesktop.org/patch/79199/
Comment 2 Ingo Bürk 2016-04-01 13:42:24 UTC
One user in the original issue (https://github.com/i3/i3/issues/2248#issuecomment-204391320) stated that the fix works for them.
Comment 3 James 2016-04-11 17:20:45 UTC
After building everything from source(xserver with this patch),I found that "slim" login manager froze.
Maybe some dependencies which depend on xserver aren't compatible with this patch...
By building everything and then rebuild xserver,it seemed to work.
Comment 4 James 2016-04-11 17:21:42 UTC
(In reply to James from comment #3)
> After building everything from source(xserver with this patch),I found that
> "slim" login manager froze.
> Maybe some dependencies which depend on xserver aren't compatible with this
> patch...
> By building everything and then rebuild xserver,it seemed to work.

rebuilding
Comment 5 Michel Dänzer 2016-05-10 02:27:35 UTC
commit 140c2f1a54dbc2503311e9a011e841aa1f277cbd
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Apr 1 18:24:00 2016 +0900

    EXA: Honour op parameter to exaGlyphs even if maskFormat == NULL


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.