Created attachment 63374 [details] test app After upgrading OLPC XO-1 from Fedora 14 (xorg-server-1.9) to Fedora 17 (xorg-server-1.12) we are seeing problems with GNOME's notification area. The icons appear all-black, which is the same colour as the GNOME panel which they are drawn upon. I've narrowed this down to a simple test case (attached). This program draws an icon (works OK), then when the window is resized the icon is replaced with all-black. Initial diagnosis at http://dev.laptop.org/ticket/11860 suggests that we're receiving a composite PictOpSrc request with no mask, repeats or transformations. lx_do_composite then reacts in this way: /* All black out of the source */ if (!exaScratch.repeat && (exaScratch.type == COMP_TYPE_ONEPASS)) { lx_composite_all_black(srcOffset, exaScratch.srcWidth, exaScratch.srcHeight); } and the icon goes black. We are not 100% sure if this is a Geode bug or something wrong in the X server. A good first step would be to understand how the driver should respond to PictOpSrc with no mask, repeats or transformations, and if that is even valid at all.
Here is a workaround: http://dev.laptop.org/attachment/ticket/11860/0001-Workaround-for-F17-rendering-bugs.patch
Created attachment 65214 [details] [review] Hack to try to fix it at the correct place without fallbacks
Created attachment 65250 [details] screenshot This doesn't fix the notification area issue. It also makes the test case behave a bit oddly. Here's a screenshot of the window.
Also, the patch seems to cause further misbehaviour. I launch the test app from a gnome terminal, then I drag the terminal over the top of the test app's window, then away again. The test app window goes black, and also the titlebar of the terminal window goes black.
Created attachment 67311 [details] [review] Better hack to try to fix negative srcX/Y cases without fallbacks A bigger refactoring of lx_do_composite is getting too time consuming (with more candle-lit dates with Porter and Duff in order), so here's again a more direct approach try to fix it for now, as we really should just get a new release out rather quickly now with xserver-1.3 compat and misrenderings of modern desktop fixed. The previous hack didn't work for GNOME-3 fallback notification icons due to them being actually srcX=0, srcY=-1 or vice-versa, so it hit the unsigned vs signed bug and entered that conditional branch instead of where the negative coordinate handling code was added. Due to the comment in the patch, this is definitely not final and likely to cause other issues, but might be interesting to test and validate on XO-1 while I figure out and address the potential problem.
Running that patch, my test case is solved, and the battery icon appears in GNOME's tray. I can't see any new rendering problems. I agree with your approach of releasing this sooner rather than later - thanks for not forgetting about this! On a similar topic, the network manager icon in the tray is now appearing all-black. But that was the same before applying this patch. I'll investigate and file another bug if it seems to be something geode-related.
While working on a similar bug in the OLPC's via chrome driver I found a link which explains the magic behind compositing for negative source coordinates: http://lists.x.org/archives/xorg-driver-geode/2010-June/000688.html (just in case that info wasn't fresh in your mind - at least it answers my big question of "what does a negative source coordinate mean?")
The exiting out of the loop approach would defeat the purpose of a lot of the changes made by Frank in that area, in particular handling of destination drawing area being larger than the source pixmap for PictOpSrc cases (but not negative srcX/Y, just larger drawing width/height than source pixmap dimensions). So after some brewing I pushed a different variable tweaking commit that should just make it so that only the source pixmap is composited in this specific case that was completely mishandled before (negative srcX/Y), which should even be correct for PictOpOver, but not so much for PictOpSrc - but I believe not much cases in the wild should need that black rendering for borders, as that's quite undesired to have random black borders in real applications I bet. In the icon case, I believe the rendering is actually to some different pixmap and the black part isn't shown on screen. A more extensive and full fixing is in order in the future and I have a good idea what to do there, but such changes wouldn't be suitable for an impending stable bugfix release, so hopefully in a major version later on. Please test the version pushed to GIT if possible, and see that it fixes the icon bug and doesn't cause any regressions elsewhere.
Thanks a lot! I've tested it briefly - seems to fix the issue, and can't see any other problems. I'll add it to OLPC builds for further testing - if you don't hear back you can assume things are working fine.
Daniel, is this still an issue with the 2.11.16 driver?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-geode/issues/4.
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.