Bug 231113 - rage128 panel setup not smart enough
Summary: rage128 panel setup not smart enough
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 8
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Adam Jackson
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-06 06:20 UTC by xunilarodef
Modified: 2018-04-11 11:41 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-09 07:05:23 UTC
Type: ---

Attachments (Terms of Use)
Picture of corrupted and dysfunctional desktop. (213.84 KB, image/jpeg)
2007-03-06 06:20 UTC, xunilarodef
no flags Details
/etc/X11/xorg.conf from system running after LiveCD boot (575 bytes, text/plain)
2007-03-14 01:20 UTC, xunilarodef
no flags Details
/var/log/Xorg.0.log from system running after LiveCD boot (46.79 KB, text/plain)
2007-03-14 01:24 UTC, xunilarodef
no flags Details
xorg.conf after successful manual configuration via system-config-display (1006 bytes, text/plain)
2007-04-08 08:53 UTC, xunilarodef
no flags Details

Description xunilarodef 2007-03-06 06:20:01 UTC
Description of problem:
  When I boot Fedora7Test2Prime LiveCD on a system with a 1600x1200
display, or on another system with a 1400x1050 display, the desktop is
unusable.  There seem to be at least 7 discontiguous and overlaid
vertical stripes of desktop area.  See the attached image.  A few
vertical stripes of the desktop are displayed twice, and when the
pointing device is moved in these regions, the cursor is cloned and
appears in two locations simultaneously.  At least one vertical stripe
of the desktop is not displayed at all (cursor vanishes and later
reappears in an adjacent stripe during continuous horizontal

Version-Release number of selected component (if applicable):
Fedora7 Test2 Prime LiveCD

How reproducible:
3 out of 3 attempts on 2 different systems.

Steps to Reproduce:
1. Boot Fedora7Test2Prime LiveCD on a system with a high-resolution display.
2. Move cursor, attempt to read information in cascaded sub-menus, ....
Actual results:
See attached image.  Results on 1600x1200 display very similar, but
with different widths of vertical stripes of desktop area.

Expected results:
A useable desktop, with the user able to read all of the information
that is intended to be displayed.

Additional info: ATI Mobility M4

Comment 1 xunilarodef 2007-03-06 06:20:02 UTC
Created attachment 149322 [details]
Picture of corrupted and dysfunctional desktop.

Comment 2 David Zeuthen 2007-03-06 16:11:52 UTC
Interesting. Looks like a video driver problem or X server problem. Reassigning.

Comment 3 Matěj Cepl 2007-03-12 13:50:56 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 4 xunilarodef 2007-03-14 01:20:32 UTC
Created attachment 150012 [details]
/etc/X11/xorg.conf from system running after LiveCD boot

Comment 5 xunilarodef 2007-03-14 01:24:16 UTC
Created attachment 150013 [details]
/var/log/Xorg.0.log from system running after LiveCD boot

  Attached are the X server config file (/etc/X11/xorg.conf) and the X
server log file (/var/log/Xorg.0.log).	In scanning through the
attached Xorg.0.log I noticed:

  (II) R128(0): Not using default mode "1600x1200" (hsync out of range)

I would have expected hsync values in the 75 kHz - 106 kHz range,
not the 31.50 - 37.90 kHz range noted in the log (circa line 516)??

  Given the information in the attached files, are you still
interested in a run without any xorg.conf file?  If so, please offer
me some clues for how to accomplish this from a LiveCD system.	When I
try Ctrl+Alt+Backspace to kill X, my screen slowly fades to solid
white, and I haven't yet discovered any key combination that provokes
any response (e.g. Ctrl+Alt+F1 no longer switches to a shell prompt),
short of the power switch.  Yes, I could remove /etc/X11/xorg.conf,
but how to kill and restart X?	Since there is not a trivial way to
change the contents of /etc/inittab on the CD, simple techniques that
require a reboot would seem ineffective.


Comment 6 xunilarodef 2007-03-14 01:32:46 UTC
[Status was still NEEDINFO after creating attachments, will this content-free
comment toggle the Status as advertised?]

Comment 7 Adam Jackson 2007-04-05 20:12:03 UTC
So I think the solution here is to stretch the sync ranges out when we detect a
panel but don't get DDC, and then inject a panel mode into the candidate list.

Comment 8 xunilarodef 2007-04-08 08:53:31 UTC
Created attachment 151930 [details]
xorg.conf after successful manual configuration via  system-config-display

Comment 9 xunilarodef 2007-04-08 09:00:19 UTC
  This bug is still with us in Fedora7 Test3 Prime LiveCD as well as the Fedora7
Test3 KDE LiveCD.  While I trust ajax's analysis leads to a rapid fix, see below
for one way to circumvent this failure so you can do more testing (if your
system hits this roadblock) while we await Test4.

  It is frustrating that the graphical presentation of the “Welcome to Fedora!”
boot menu (with the choices of e.g. “Fedora-7-Test3-KDE-Live” or
“Fedora-7-Test3-KDE-Live from RAM”) displays quite nicely ... but once X is
started there is only this rather useless scrambled display.

  But with persistence, one can surpass this hurdle.  Surprisingly, the
autoconfig correctly identified the  video adapter, but failed to guess a
compatible display (it was attempting to use 800 x 600 @ 60 Hz Generic CRT
Display).  One way to manually recover from this, if using Gnome: 
  Terminal (the last item in the cascaded submenu, if the text of this submenu
is partially or totally invisible due to the striped overlays;  the resulting
Terminal window will probably need to be dragged to the right to reveal the
shell prompt where one will type the command “system-config-display” [see
One way to manually recover from this, if using KDE is: 
  Terminal  (the next to last item in the cascaded submenu, if the text of this
submenu is partially or totally invisible due to the striped overlays;  the
resulting Terminal window will probably need to be dragged to the right to
reveal the shell prompt where one will type the command ...)
  select the Hardware tab,
  to the right of “Monitor Type” select the “Configure...” command button, 
  (select the checkbox for “Show all available monitors” could be needed in some
cases, but not mine), 
  select Generic LCD Display, select the twisty triangle and 
  from the drop down list select e.g.1600 x 1200, 
In either case, use Ctrl+Alt+Backspace to restart X, and the display is quite
usable, showing all of the previously concealed information with nothing scrambled.

  This circumvention failed with Fedora7 Test2 Prime LiveCD since any attempt to
restart X just leads to the display slowly fading to white, with no further
response from any keystrokes.

  The attached copy of /etc/X11/xorg.conf shows the result of this successful
manual configuration via system-config-display.

Comment 10 Matthew Miller 2007-04-10 15:51:31 UTC
Fedora 7 test bugs should be filed against "devel" -- not obvious, I know.

Comment 11 Bug Zapper 2008-04-03 23:37:47 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 12 xunilarodef 2008-04-07 11:32:14 UTC
  This design flaw / bug persists in all of the released Fedora 7 and Fedora 8
versions I have tried, including conventional install media, LiveCDs, and
pxeboot.  I cannot confirm that it remains in the current rawhide pre-Fedora 9
until we progress to where X will at least show its face through the R128 driver
- https://bugzilla.redhat.com/show_bug.cgi?id=439022

Comment 13 Bug Zapper 2008-11-26 07:12:07 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 14 Bug Zapper 2009-01-09 07:05:23 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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