Bug 54168 - Updating to xorg-server-1.12.4 breaks xfwm4 themes with 1 pixel width .xpm's
Updating to xorg-server-1.12.4 breaks xfwm4 themes with 1 pixel width .xpm's
Status: RESOLVED FIXED
Product: xorg
Classification: Unclassified
Component: Server/General
unspecified
All Linux (All)
: medium normal
Assigned To: Xorg Project Team
Xorg Project Team
: patch
Depends on:
Blocks: xserver-1.12
  Show dependency treegraph
 
Reported: 2012-08-28 20:16 UTC by bugzilla.5.kyoo
Modified: 2014-12-12 17:20 UTC (History)
11 users (show)

See Also:


Attachments
screenshot of the issue (162.78 KB, image/png)
2012-08-28 20:16 UTC, bugzilla.5.kyoo
no flags Details
Patch to maintain no segfault in fbBresSolid while fixing the algorithmic problems created in 863d528a9f76d0e8f122aebf19f8564a4c67a938 (1.54 KB, patch)
2014-06-14 05:51 UTC, Alex Orange
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description bugzilla.5.kyoo 2012-08-28 20:16:05 UTC
Created attachment 66246 [details]
screenshot of the issue

With xorg-server 1.12.3.901 and xorg-server-common 1.12.3.901, there is no issue.  However, if I update both packages to 1.12.4, xfwm4 fails to show parts of themes 1 pixel wide.  In the attached screenshot, the image for part of the border that should show the window title is 1 pixel wide.  A 2 pixel wide image does not do this.  XFCE bug report: https://bugzilla.xfce.org/show_bug.cgi?id=9246 concludes it's an xorg problem.

Distribution: Arch Linux (rolling release)
Architecture: x86
Comment 1 Evangelos Foutras 2012-08-29 18:29:36 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
Comment 2 Thomas Lange 2012-10-25 19:56:06 UTC
This bug is also occurring in version 1.13.0.
Comment 3 Christian Birchinger 2012-11-17 16:25:08 UTC
I'm now using 1.13.0 having the same issue.

Reverting the patch from comment #1 fixes the issue for me.
Comment 4 Johan 2013-02-24 06:13:14 UTC
Issue still in 1.13.2.901.
Comment 5 Michael Shigorin 2013-03-22 16:41:35 UTC
Still in 1.14.0, spoils similar icewm themes as well.
Comment 6 Jayson Rowe 2013-04-21 19:58:14 UTC
Still in 1.14.1 - any word on resolution?
Comment 7 nolan+freedesktop 2014-02-17 10:41:40 UTC
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.
Comment 8 bugzilla.5.kyoo 2014-02-18 04:04:10 UTC
This is still present in 1.15.0.
Comment 9 Alex Orange 2014-06-14 05:50:02 UTC
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.
Comment 10 Alex Orange 2014-06-14 05:51:53 UTC
Created attachment 101029 [details] [review]
Patch to maintain no segfault in fbBresSolid while fixing the algorithmic problems created in 863d528a9f76d0e8f122aebf19f8564a4c67a938
Comment 11 Daniel Boca 2014-09-15 07:15:05 UTC
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.
Comment 12 Alex Orange 2014-09-16 01:06:30 UTC
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.
Comment 13 Thomas Lange 2014-09-26 16:23:03 UTC
This issue is still not fixed with version 1.16.1.
Could someone please review and commit Alex' patch? Thank you.
Comment 14 Alan Coopersmith 2014-09-26 20:32:10 UTC
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/
Comment 15 Alex Orange 2014-10-29 01:43:54 UTC
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.
Comment 16 Thomas Lange 2014-10-29 12:51:45 UTC
Will this be backported to older branches?
1.16 for example?
Comment 17 Alex Orange 2014-11-03 16:20:21 UTC
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?
Comment 18 bugzilla.5.kyoo 2014-11-04 01:48:22 UTC
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.
Comment 19 bugzilla.5.kyoo 2014-11-04 01:50:04 UTC
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.
Comment 20 jakub 2014-11-19 21:14:56 UTC
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
Comment 21 jakub 2014-11-19 21:20:13 UTC
I forgot to add screenshot (link found on arch forum): http://imgur.com/a/eXgb5
Comment 22 cvillelk 2014-11-19 21:27:26 UTC
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.
Comment 23 jakub 2014-11-19 22:44:41 UTC
True, I tried some other window decorations and got the same result as on screenshot attached to this bug.
Comment 24 cvillelk 2014-11-19 23:01:53 UTC
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.
Comment 25 Michel Dänzer 2014-11-20 00:57:11 UTC
(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.
Comment 26 Julien Cristau 2014-11-23 16:06:42 UTC
(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
Comment 27 jakub 2014-12-12 17:20:10 UTC
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.