Bug 97160 - The change to black background should be reversed as there is a "-br" option to X.
Summary: The change to black background should be reversed as there is a "-br" option ...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86   
(Show other bugs)
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-11 02:27 UTC by Michael Breuer
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-01 16:57:23 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michael Breuer 2003-06-11 02:27:47 UTC
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
Actual results:

Expected results:

Additional info:

Not included in XFree86 4.3.0 (xfree86.org)... not in CVS, either.

Comment 1 Mike A. Harris 2003-06-11 06:27:00 UTC
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

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.


Comment 2 Mike A. Harris 2003-06-11 10:14:47 UTC
Reassigning..  XFree86-Servers is the XFree86 3.3.6 component that last appeared
in RHL 7.3

Comment 3 Michael Breuer 2003-06-11 12:32:51 UTC
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.

Comment 4 Mike A. Harris 2003-06-11 12:42:15 UTC
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.

Comment 5 Michael Breuer 2003-06-11 12:51:17 UTC
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).

Comment 6 Mike A. Harris 2003-06-11 13:05:27 UTC
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

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?

Comment 7 Michael Breuer 2003-06-11 14:42:52 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.