| Summary: | Updating to xorg-server-1.12.4 breaks xfwm4 themes with 1 pixel width .xpm's | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | bugzilla.5.kyoo | ||||||
| Component: | Server/General | Assignee: | Xorg Project Team <xorg-team> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | CC: | 58designs, andyrtr, cleanrock, crazycasta, cvillelk, evangelos, gentoolinux, jayson.rowe, jcristau, jeremyhu, michalsrb, thomas-lange2 | ||||||
| Version: | unspecified | Keywords: | patch | ||||||
| Hardware: | All | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 40982 | ||||||||
| Attachments: |
|
||||||||
|
Description
bugzilla.5.kyoo
2012-08-28 20:16:05 UTC
I did a 'git bisect' between 1.12.3.901 and 1.12.4 and the following commit seems to have caused this behavior: --------- http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.12-branch&id=3e62f48e "fb: reorder Bresenham error correction to avoid overshoot." --------- For what is worth, the issue is present with Catalyst 12.6 Legacy on my desktop machine, but not on my netbook which uses the xf86-video-intel 2.20.5 driver. Also happens with the NVIDIA driver but not with Nouveau. [1] [1] https://bbs.archlinux.org/viewtopic.php?pid=1152857#p1152857 This bug is also occurring in version 1.13.0. I'm now using 1.13.0 having the same issue. Reverting the patch from comment #1 fixes the issue for me. Issue still in 1.13.2.901. Still in 1.14.0, spoils similar icewm themes as well. Still in 1.14.1 - any word on resolution? I'm still on 1.12.4 but I'm experiencing this problem as well. Has this been fixed in any newer version? If so, which? I'd like XFWM's Default theme to work on my latest Gentoo build. This is still present in 1.15.0. As has been identified this is a problem with http://cgit.freedesktop.org/xorg/xserver/commit/?id=863d528a9f76d0e8f122aebf19f8564a4c67a938 . Specifically the reordering created seriously messes up the algorithm in certain cases (causing offsets of the starting point for instance). I examined what could possibly cause this error in the first place and the only way I can see this drawing to an off-screen location is if, on the last pass through the X_AXIS while look the !mask if is triggered, pushing the dst out of the range (presumably the last point drawn was the lower right corner, or some other pixel that one to the right of would be a segfault pixel). Then the e>=0 if is triggered which causes another write to this invalid location. However, bits will be 0 at this point because it was just set to 0, therefore the write can be masked by an if (bits) which will always fail in this off-screen condition and therefore save us from a write to an invalid location. There is no similar condition that can cause a write to an invalid location when the axis is Y_AXIS because the only write is at the very top of the loop. Therefore, the sum total of the following patch is to revert 863d528a9f76d0e8f122aebf19f8564a4c67a938 and add the if around the second write in the X_AXIS while statement. Created attachment 101029 [details] [review] Patch to maintain no segfault in fbBresSolid while fixing the algorithmic problems created in 863d528a9f76d0e8f122aebf19f8564a4c67a938 The problem is still there in RHEL 6.6 beta, xorg-x11-server-Xorg-1.15.0-16.el6.x86_64. In the end, is this more a Nvidia driver problem ? I can confirm that I see this issue only using Nvidia driver, not Nouveau nor Intel. I've managed to fix it using the patch provided. No, this is **NOT** an nVidia (or any driver) problem (emphasis because the common misconception seems to be that it is an nVidia/ATI/AMD proprietary driver issue, even I shared this misconception before looking at the code). It is a problem with the implementation of the Bresenham (bres for short) line drawing algorithm. I am not sure how the other drivers get around this problem. My assumption (and if I recall correct I may have even tested this) is that they do not call the code in question at all. I'm guessing that they implement the line draw on the graphics chip or something and therefore override this problematic code. This issue is still not fixed with version 1.16.1. Could someone please review and commit Alex' patch? Thank you. Patches to the xserver are only pushed by the xserver maintainer, Keith Packard. He reviews & pushes patches mailed to the xorg-devel mailing list, not those in bugzilla. http://wiki.x.org/wiki/Development/Documentation/SubmittingPatches/ The patch has been accepted as 1b94fd77792310c80b0a2bcf4bf6d4e4c4c23bca. I believe this fixes the problem (it does for me), but will of course defer to the poster if they're still around. Please test to confirm it fixes your specific problem if you can. Will this be backported to older branches? 1.16 for example? Not sure what's to be done for that. The patch should work as is against 1.16. I've already asked on the list, but maybe someone here knows, am I just supposed to make another patch like the other one and make this one against the server-1.16-branch instead of against the master? I'm still getting emails. I switched from xfwm4 about a year ago. After re-installing it, I'm not able to reproduce the problem, with or without the patch. If it looks fixed to those working on it, that sounds good to me. Excuse me, I believe I used a patched version of xorg-server to try to reproduce the problem -.- Nonetheless, what I said before holds true since I no longer use xfwm4. Today I noticed I don't have side borders thus I can't resize window dragging it's border as I usually could. Is it the same issue? xorg-server 1.16.2-1 nvidia-304xx 304.123-9 xfwm4 4.10.1-1 I forgot to add screenshot (link found on arch forum): http://imgur.com/a/eXgb5 Yes, same issue. Until a solution is found dragging from the corner or changing to a theme with 2px+ side borders is the only alternative. True, I tried some other window decorations and got the same result as on screenshot attached to this bug. It looks like (per Alex Oranges previous comment) the fix for this issue is already submitted and commited to the master branch of xserver See "2014-10-27 fb: Fix Bresenham algorithms for commonly used small segments." http://cgit.freedesktop.org/xorg/xserver/log/ It was not applied to the 1.16 branch (nor am I sure how to request it be offically applied). I'll try and research more into that workflow when I can. Until then you can either manually patch and build the package or wait until the patch is applied by maintainers. (In reply to cvillelk from comment #24) > It looks like (per Alex Oranges previous comment) the fix for this issue is > already submitted and commited to the master branch of xserver > > See "2014-10-27 fb: Fix Bresenham algorithms for commonly used small > segments." Resolving this report accordingly. > It was not applied to the 1.16 branch (nor am I sure how to request it be > offically applied). Adding Julien Cristau (1.16 branch maintainer) to CC. If this isn't enough, please nominate the fix to him via e-mail and Cc: the xorg-devel mailing list. (In reply to Michel Dänzer from comment #25) > (In reply to cvillelk from comment #24) > > It was not applied to the 1.16 branch (nor am I sure how to request it be > > offically applied). > > Adding Julien Cristau (1.16 branch maintainer) to CC. If this isn't enough, > please nominate the fix to him via e-mail and Cc: the xorg-devel mailing > list. To git.freedesktop.org:/git/xorg/xserver 4393c7f..a471a15 server-1.16-branch -> server-1.16-branch I just updated to xorg-server (xorg-server-common, xorg-server-xwayland) to 1.16.2.901-1 on my arch installation and issue is gone. *** Bug 75720 has been marked as a duplicate of this bug. *** |
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.