continued from pixman@, original thread here: https://lists.freedesktop.org/archives/pixman/2018-August/004759.html
On Wed, 2018-08-29 at 18:14 +0200, Frédéric Fauberteau wrote: > Le 2018-08-29 16:33, Adam Jackson a écrit : > > This is a curious backtrace though. You're crashing while trying to > > draw the black solid fill for the initial map of the root window. Fine, > > but you're doing so in software, even though you have glamor enabled, > > and glamor surely can usually accelerate solid fills. So you're hitting > > a software fallback for some reason, and if I had to guess... > > The area to fill is 2960x1050 but actually, I have two screens: > ----------------- ------------- > > | | | > > | | | > > 1680x1050 | | 1280x1024 | > > | | | > > | |-----------| > > ----------------- > > Do you think it could be a reason to write in an unmapped region...? Probably not? Typically the allocation for the root window is a rectangle big enough to bound all the outputs within it, so actually 2960x1050 in your case. The missing corner below the 1280x1024 display still has memory behind it. > It is a RS780/RS880 (Radeon HD 3200). If the bug comes from the Mesa > driver, it's a big issue since we are totally late with the update (we > are on MesaLib 11.2.2) That should be new enough to not have the problem I was describing. Unfortunately, that means I'm out of ideas. I think there are probably at least two bugs here: the fallback shouldn't crash, but neither should the fallback occur. Probably the second one is a bit easier to figure out. I'd start by rebuilding xserver with some printf-debugging in the body of glamor_poly_fill_rect_gl(), to see which 'goto bail' path is getting hit. (xserver spells printf ErrorF, which will print into both the X log and stdout.) - ajax _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel