Description of problem: With the addition of -br as an option to XFree86, the "XFree86-4.2.0-die-ugly-pattern-die-die-die.patch" should be removed. There is now no way to revert to previous behavior. When connecting using XDMCP, some applications don't appear correctly with the black root... it is not feasible to change all possible servers to xsetroot at login; CDE security makes it difficult to xsetroot before login, and changes don't stick at logout. Version-Release number of selected component (if applicable): 4.3.0-3 (introduced in 4.2.0-6.34) How reproducible: Documented behavior, now unecessary (replaced with '-br' option to XFree86). Steps to Reproduce: 1. N/A 2. 3. Actual results: Expected results: Additional info: Not included in XFree86 4.3.0 (xfree86.org)... not in CVS, either.
We changed the root window default to an all black root, in order to remove the temporary ugly grey-weave from being displayed, which then gets replaced by whatever wallpaper a user uses or the display manager, or an xsetroot image. This is the most visually appealing default root window to the majority of our end users, and up until now, nobody had been able to present a problem with it that couldn't be fixed by xsetroot or similar so I've not investigated any changes to the patch since including it. I intentionally left the patch present despite being aware of the new -br option added in 4.3.0, as we want the default root window to be black everywhere intentionally, and XFree86 4.3.0 doesn't make it the default. Basically we want the opposite of what XFree86 is using right now, which is black by default, but allow user to change it. Now that you've brought this issue to my attention however, I'll probably add a new option "-greyweave" in a future release in order to allow special case uses such as this to default to the more traditional grey weave pattern by default instead, while allowing our intended black root default to remain the default. When I've had time to whip up a patch, I'll update this report for you to give it a shot. Thanks.
Reassigning.. XFree86-Servers is the XFree86 3.3.6 component that last appeared in RHL 7.3
Just one point on the "all black" approach. Many analog flat panels require non-black pixels to self-calibrate on startup. Thus, booting to an all-black screen can result in subsequently poor visual quality on the screen. Alternating black and white pixels is actually the best possible screen on which to calibrate. .. black the worst.
Microsoft Windows, Mac OS/X, numerous other operating systems get by ok without the initial video card state being an ugly 1985 grey weave. As I said, I will add an option at some point, but there is no way that I will put the grey-weave back as the default.
I was just suggesting that you warn users in the release notes... the issue isn't system dependent... it affects users with analog-connected flat panels. From what I've seen, those manufactured with certain versions of Pixelink controllers are most succeptable. We happen to have some that are causing great grief... not only do they self-calibrate when a signal change is detected... they do so really badly when they try to key off of the black background... their calibration also drifts with temperature (hence my other bug report 91799 regarding the backlight).
That's not a software flaw IMHO, but a hardware flaw. No computer software ever makes any guarantee what color the pixels in video memory will be after a video mode change has occurred, and so any hardware assuming pixels will be any particular color is IMHO broken as designed. Have you contacted the panel manufacturer? Workaround: switch videomodes down one and back with CTRL-ALT- +/- Anyway, when the grey weave is made an option, people will be able to use that option to work around the broken hardware design I guess. I'm curious how different versions of Microsoft Windows operates on this same panel. Can you test this and provide such feedback?
The initial blue background is sufficient to sync the panel... but not as accurately as the stipple. Pretty much any non-black pixel pattern provides the electronics a waveform which it can detect. Black has no amplitude... the pixelink controller measures screen width by counting pixels to pixel distance based on amplitude, then "fine-tunes" by averaging the peak amplitude for each pixel across one or more lines (the specific algorithm varies with vendor firmware). For manual calibration, either vertical 1-pixel stripes, or 50% grey are best... in either case unless the calibration is near-perfect, both of those patterns show significant noise. This is probably why most people hate the pattern... their displays are not accurately calibrated, resulting in an absolutely horrible appearance.