Bug 168764 - xorg-X11 testing labs rpm does not fill screen to edges of monitor
xorg-X11 testing labs rpm does not fill screen to edges of monitor
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
4
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: X/OpenGL Maintenance List
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-20 03:04 EDT by nicholas manojlovic
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-27 12:41:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
FC4-49.2 (63.74 KB, text/x-log)
2005-09-22 12:08 EDT, nicholas manojlovic
no flags Details
FC4-45 (49.19 KB, text/x-log)
2005-09-22 12:14 EDT, nicholas manojlovic
no flags Details
log with VideoRAM set to 64 (fails) (63.74 KB, text/x-log)
2005-09-22 21:51 EDT, nicholas manojlovic
no flags Details
VideoRAM enforced to 32mb (fails) (63.74 KB, text/x-log)
2005-09-22 22:05 EDT, nicholas manojlovic
no flags Details

  None (edit)
Description nicholas manojlovic 2005-09-20 03:04:19 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.0.6-1.2.fc4 Firefox/1.0.6

Description of problem:
Following the crash resulting from the xorg update, this rpm (and its companion xorg set) was installed from the testing labs to fix PCI overflow security issues etc..

It brought back i810 device functionality however I am suspicious of the following issue: the screen does not fill to the edges of the monitor. 

in WinXP and xorg-x11-6.8.2-37.FC4.45.i386 this issue did not exist.

allow me to speculate; 
? - the refresh rate is not correct - in functioning environments, this issue occurs when the monitor is set to refresh at 75hz rather than the correct 85hz. out of the box WinXP selects 75hz and requires manual adjustment. FC4 functioning xorg-X11 (including the rpm set included on the installation media) is able to automatically select 85hz without problems. (I include this information because I am unaware how monitors/vid inform the chipset of their functionality in case it helps).

? - xorg.conf is missing information. I will include my xorg.conf for your perousal. 

? - other ideas?

please let me know what other information I could produce to help solve this bug.

Version-Release number of selected component (if applicable):
xorg-x11-6.8.2-37.FC4.49.1.i386

How reproducible:
Always

Steps to Reproduce:
1. update to testing labs xorg-x11-6.8.2-37.FC4-49 to fix crash for i810
2. screen functions but is offset and does not fill to edges of monitor. perspective looks okay, but there are black bars on the top, left and bottom. 
3. previous versions of xorg-x11 (including set on fc4 installation media) did not have this error. WinXP does not have this problem when monitor is at 85hz refresh.
  

Additional info:

intel 865 chipset 'extreme' video card included on PIV motherboard in shuttleX SB61G using i810 device.

Dell CRT 17inch 70.2Khz / 87hz. 

---

# XFree86 4 configuration created by pyxf86config

Section "ServerLayout"
	Identifier     "Default Layout"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"

# RgbPath is the location of the RGB database.  Note, this is the name of the 
# file minus the extension (like ".txt" or ".db").  There is normally
# no need to change the default.
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Red Hat 6.0 and later now use a font server independent of
# the X server to render fonts.
	RgbPath      "/usr/X11R6/lib/X11/rgb"
	FontPath     "unix/:7100"
EndSection

Section "Module"
	Load  "dbe"
	Load  "extmod"
	Load  "fbdevhw"
	Load  "glx"
	Load  "record"
	Load  "freetype"
	Load  "type1"
	Load  "dri"
EndSection

Section "InputDevice"

# Specify which keyboard LEDs can be user-controlled (eg, with xset(1))
#	Option	"Xleds"		"1 2 3"
# To disable the XKEYBOARD extension, uncomment XkbDisable.
#	Option	"XkbDisable"
# To customise the XKB settings to suit your keyboard, modify the
# lines below (which are the defaults).  For example, for a non-U.S.
# keyboard, you will probably want to use:
#	Option	"XkbModel"	"pc102"
# If you have a US Microsoft Natural keyboard, you can use:
#	Option	"XkbModel"	"microsoft"
#
# Then to change the language, change the Layout setting.
# For example, a german layout can be obtained with:
#	Option	"XkbLayout"	"de"
# or:
#	Option	"XkbLayout"	"de"
#	Option	"XkbVariant"	"nodeadkeys"
#
# If you'd like to switch the positions of your capslock and
# control keys, use:
#	Option	"XkbOptions"	"ctrl:swapcaps"
# Or if you just want both to be control, use:
#	Option	"XkbOptions"	"ctrl:nocaps"
#
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "IMPS/2"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5"
	Option	    "Emulate3Buttons" "yes"
EndSection

Section "Monitor"
	Identifier   "Monitor0"
	VendorName   "Monitor Vendor"
	ModelName    "Dell E773s"
	DisplaySize  320	240
	HorizSync    30.0 - 70.0
	VertRefresh  50.0 - 160.0
	Option	    "dpms"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "i810"
	VendorName  "Videocard vendor"
	BoardName   "Intel 865"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	Monitor    "Monitor0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     16
		Modes    "800x600" "640x480"
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     24
		Modes    "1024x768" "800x600" "640x480"
	EndSubSection
EndSection

Section "DRI"
	Group        0
	Mode         0666
EndSection
Comment 1 Mike A. Harris 2005-09-20 04:39:25 EDT
Please indicate the last exact version-release of xorg-x11 for FC4 that did
not have this problem for you.  If there are multiple previous builds that
worked, indicate as many known-working ones as you can.  This will help
narrow down when things changed.

Thanks in advance.
Comment 2 nicholas manojlovic 2005-09-20 04:49:42 EDT
(In reply to comment #1)
> Please indicate the last exact version-release of xorg-x11 for FC4 that did
> not have this problem for you.  If there are multiple previous builds that
> worked, indicate as many known-working ones as you can.  This will help
> narrow down when things changed.
> 
> Thanks in advance.

Every version of xorg from FC2 to FC4 has worked correctly until this update:
https://www.redhat.com/archives/fedora-announce-list/2005-September/msg00063.html
(which, of course, also caused the crash).
Comment 3 nicholas manojlovic 2005-09-20 05:16:37 EDT
Further information:

I reverted back to xorg-6.8.2-FC4-45.

The screen now fills to the edges correctly. I dont know how dynamic these
things are but the monitor now reports:
68.6kHz / 84hz

whereas with FC4-49 it reported:
70.2Khz / 87hz. 

Comment 4 nicholas manojlovic 2005-09-20 05:23:58 EDT
And to test I went back to FC4-49. 

I can confidently say this is a genuine bug as the problem reappears! Once again
the monitor reports:
70.2KHz / 87Hz

Comment 5 Alexei Podtelezhnikov 2005-09-22 09:38:17 EDT
Please *attach* (don't paste) /var/log/Xorg.0.log corresponding to both 
correctly and incorrectly started versions to compare and pinpoint the bug. 
The files actually indicate how the default refresh rate is selected. 
Comment 6 nicholas manojlovic 2005-09-22 12:08:19 EDT
Created attachment 119147 [details]
FC4-49.2

Here is the incorrectly refreshing display as outlined in the bugreport.
Comment 7 nicholas manojlovic 2005-09-22 12:14:16 EDT
Created attachment 119148 [details]
FC4-45

Here is the log which correctly sets the refresh rate.
Comment 8 Alexei Podtelezhnikov 2005-09-22 17:23:35 EDT
Two big differences in log files stick out:    
    
1) 49.2 detects twice as much memory for free. Wow! I wonder if that's   
correct. You may try to enforce the correct amount with    
VideoRAM 32768 (or 65536 whichever is correct) in Section "Device" of   
xorg.conf   
   
than later,  
2) 49.2 doesn't echo what your monitor reports back via DDC, but refresh  
limits seems to be detected correctly. Despite 49.2 is very verbose in 
rejecting bad available rates, the final choice seems identical at the end. 
 
than later, 
3) A couple of failures on 49.2: 
+(WW) I810(0): Extended BIOS function 0x5f05 failed. 
+(II) I810(0): Setting refresh with VBE 3 method. 
 
Well... Try enforcing VideoRAM in xorg.conf.... Report back, even if it fails. 
Comment 9 nicholas manojlovic 2005-09-22 21:51:51 EDT
Created attachment 119172 [details]
log with VideoRAM set to 64 (fails)

when xorg.conf has a section that looks like this:

Section "Device"
	Identifier  "Videocard0"
	Driver	    "i810"
	VendorName  "Videocard vendor"
	BoardName   "Intel 865"
	VideoRAM    65536

It still fails. To my knowledge, this video card has 64mb onboard RAM, or at
least, thats what the *marketing* specs say. I'm quite prepared for the fact
the reality is different. In any case, Ill halve the number above and report
back again. Cheers all :)
Comment 10 nicholas manojlovic 2005-09-22 22:05:25 EDT
Created attachment 119173 [details]
VideoRAM enforced to 32mb (fails)

For completeness sake, here is the log genereated with an xorg.conf that has
VideoRAM 32768. Still no workaround.

Cheers again
Niko
Comment 11 Mike A. Harris 2005-09-23 01:09:48 EDT
Just an untested hypothesis...  This sounds to me like it may be a
regression in the updated i810 driver.  It might be worthwhile disabling
the new i915/945 support patch and rebuilding and seeing if that removes
the regression.

xorg-x11-6.8.2-add-i945-support.patch is the patch in question.

Can you try that?  If not, let me know and I'll do a rebuild of it
later this week and put it on people.redhat.com somewhere.

Comment 12 nicholas manojlovic 2005-09-23 04:16:03 EDT
Sorry, Im a bit clueless when it comes to that.

Ill dig around google and try it out but I might need you to do it for me if
you're not too busy.

Its not a huge issue, Im happy to live with FC4-45 for now. 
Comment 13 Mike A. Harris 2005-09-23 14:45:44 EDT
Please edit your xorg.conf, and add the following option to the "ServerFlags"
section.  If there is no ServerFlags section, create a new one as such:

Section "ServerFlags"
        Option "PciOsConfig" "1"
EndSection

Then save and exit, and reboot the system, then start the X server up again.
Indicate wether the video problem is resolved or not.  If the problem
is still present, remove the above option, and replace it with the following
option instead, and try again:

        Option "PCIProbe1" "1"

Does this option resolve the issue?  If not, please try the following:

        Option "PCIProbe2" "1"

If any of these 3 options work around the problem, please update the bug
report to let us know which ones.  Be sure to reboot the machine before
each try, to ensure a full hardware reset.

This will help us to narrow down wether the problem is related to the PCI
configuration changes, or elsewhere.  Thanks in advance for testing.

Setting status to "NEEDINFO_REPORTER" and awaiting feedback.
Comment 14 nicholas manojlovic 2005-09-24 00:56:04 EDT
(In reply to comment #13)
> Please edit your xorg.conf, and add the following option to the "ServerFlags"
> section.  If there is no ServerFlags section, create a new one as such:
> 
> Section "ServerFlags"
>         Option "PciOsConfig" "1"
> EndSection
> 
> Then save and exit, and reboot the system, then start the X server up again.
> Indicate wether the video problem is resolved or not.  If the problem
> is still present, remove the above option, and replace it with the following
> option instead, and try again:
> 
>         Option "PCIProbe1" "1"
> 
> Does this option resolve the issue?  If not, please try the following:
> 
>         Option "PCIProbe2" "1"
> 
> If any of these 3 options work around the problem, please update the bug
> report to let us know which ones.  Be sure to reboot the machine before
> each try, to ensure a full hardware reset.
> 
> This will help us to narrow down wether the problem is related to the PCI
> configuration changes, or elsewhere.  Thanks in advance for testing.
> 
> Setting status to "NEEDINFO_REPORTER" and awaiting feedback.


Unfortunately, none of these options creates a workaround.
Comment 15 Alexei Podtelezhnikov 2005-09-26 15:06:14 EDT
Mike created a build with the i945 patch disabled. 
ftp://people.redhat.com/mharris/testing/fc4/xorg-x11/6.8.2-37.FC4.49.3.test_no_i945.0 
You can try it. Others report good results with it in bug 169093. 
Comment 16 Mike A. Harris 2005-09-26 15:18:35 EDT
Alexei:

Thanks, I forgot to put the URL here.  ;)
Comment 17 nicholas manojlovic 2005-09-27 04:23:09 EDT
Indeed, the latest testing labs RPMs with i945 patch disabled solve this problem. 

Thanks Mike! Looking forward to seeing this in yum :)


Comment 18 Steven Bakker 2005-09-27 08:56:24 EDT
I can confirm this version works on my Dell Latitude D400.

I had a different problem than above, though: xinerama stopped working after
xorg-x11-6.8.2-37.FC4.45. Newer versions just resulted in blank screens,
sometimes the external screen would be filled with some random colour patterns,
but I always ended up having to reboot to reset the display.

Log files showed no errors, it just stopped logging after recognising the V_BIOS.

It _did_ always disable DisplayInfo due to "Bad V_BIOS checksum". In older
versions I had to disable it by hand, newer versions always disabled it
automatically. However, specifying the sync/refresh manually always worked up to
and including 6.8.2-37.FC4.45. After that, no go.

This version fixes it, so I can now enjoy my extended desktop again :-)

If anyone is interested in the log files, let me know. I still have it on my
disk, but it seems to be related to the i945 patch breaking the sync/refresh
(quite badly in my case).

Thanks,
Steven
Comment 19 Mike A. Harris 2005-09-27 15:30:44 EDT
This bug is not resolved, please don't close it.

The rpms I built are *test* rpms for diagnostic purposes only.  They are
not an official ERRATA release, and they wont be released as an official
update.

Just to clarify things, the latest official xorg-x11 update we released
has an updated i810 driver which adds support for Intel i945 chipsets, and
updates other support.  Changes in this new driver have the unfortunate
side effect of regressing support for some users.  The test build I've
had you guys test, removes the i945 support patch only for diagnostic
purposes to help determine if it is this new support patch that has caused
the regression you are experiencing.  This is only a temporary diagnostic
test.  We are not removing the i945 support patch in an official update.

The current state, is that we need to determine what if any driver options
help people to work around the problems in the new driver, so we can try
to find a real solution.  The preference of course will be to find a solution
that "just works" for people and does not require manual intervention or
manual configuration, however that may or may not be easily possible.

One thing is certain, is that we are tracking the official X.Org driver
whatever direction it goes, as maintaining a diverging driver fork is
definitely not an option.  ;o)


Setting status back to "REOPENED", to continue diagnosis.
Comment 20 Mike A. Harris 2005-09-27 18:03:24 EDT
Using the current FC4 xorg-x11 update rpm (not the test release I
provided above), if you use the following option in the device
section of xorg.conf, does it change the problem or make it go
away at all?

    Option "NoDDC"

If this option doesn't change anything, what about the following:

    Option "VBERestore"

Please update with your testing results.

Thanks in advance.
Comment 21 Naaman Campbell 2005-09-28 02:26:41 EDT
(In reply to comment #13)
> Please edit your xorg.conf, and add the following option to the "ServerFlags"
> section.  If there is no ServerFlags section, create a new one as such:
> 
> Section "ServerFlags"
>         Option "PciOsConfig" "1"
> EndSection
> 
> Then save and exit, and reboot the system, then start the X server up again.
> Indicate wether the video problem is resolved or not.  If the problem
> is still present, remove the above option, and replace it with the following
> option instead, and try again:
> 
>         Option "PCIProbe1" "1"
> 
> Does this option resolve the issue?  If not, please try the following:
> 
>         Option "PCIProbe2" "1"
> 
> If any of these 3 options work around the problem, please update the bug
> report to let us know which ones.  Be sure to reboot the machine before
> each try, to ensure a full hardware reset.
> 
> This will help us to narrow down wether the problem is related to the PCI
> configuration changes, or elsewhere.  Thanks in advance for testing.
> 
> Setting status to "NEEDINFO_REPORTER" and awaiting feedback.


After performing the following:

rpm -e --allmatches --nodeps --noscripts xorg-x11-Mesa-libGLU
yum install xorg-x11-Mesa-libGLU

The second suggested configuration change worked:

Section "ServerFlags"
        Option "PCIProbe1" "1"
EndSection

This was successful for a HP Compaq dc7100 with the following lspci output:

00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express
Chipset Family Graphics Controller (rev 04) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company: Unknown device 3006
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at cfe00000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 3800 [size=8]
        Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at cff00000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller: Intel Corporation 82915G Express Chipset Family
Graphics Controller (rev 04)
        Subsystem: Hewlett-Packard Company: Unknown device 3006
        Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Region 0: Memory at cfe80000 (32-bit, non-prefetchable) [disabled]
[size=512K]
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Comment 22 nicholas manojlovic 2005-09-28 03:01:43 EDT
(In reply to comment #19)
> This bug is not resolved, please don't close it.
> 
> The rpms I built are *test* rpms for diagnostic purposes only.  They are
> not an official ERRATA release, and they wont be released as an official
> update.
> 
> Just to clarify things, the latest official xorg-x11 update we released
> has an updated i810 driver which adds support for Intel i945 chipsets, and
> updates other support.  Changes in this new driver have the unfortunate
> side effect of regressing support for some users.  The test build I've
> had you guys test, removes the i945 support patch only for diagnostic
> purposes to help determine if it is this new support patch that has caused
> the regression you are experiencing.  This is only a temporary diagnostic
> test.  We are not removing the i945 support patch in an official update.
> 
> The current state, is that we need to determine what if any driver options
> help people to work around the problems in the new driver, so we can try
> to find a real solution.  The preference of course will be to find a solution
> that "just works" for people and does not require manual intervention or
> manual configuration, however that may or may not be easily possible.
> 
> One thing is certain, is that we are tracking the official X.Org driver
> whatever direction it goes, as maintaining a diverging driver fork is
> definitely not an option.  ;o)
> 
> 
> Setting status back to "REOPENED", to continue diagnosis.

Apologies for closing the bug. I thought you would open a new bug 'i915 breaks
i810' or something. 

Option "NoDDC"
Option "VBERestore"

in Section Device both fail to fix the problem. Workaround detailed in comment
21 also does not fix the problem here.
Comment 23 Leon Stringer 2005-10-03 14:28:21 EDT
Hi the update caused this problem for me. Setting PciOsConfig to 1 fixed it. Tnx.
Comment 24 Leon Stringer 2005-10-03 14:30:14 EDT
Hi the update caused this problem for me on my Intel D845GERG2 board. Setting
PciOsConfig to 1 fixed it. Tnx.
Comment 25 Alastair Scobie 2005-10-11 11:54:10 EDT
Update to xorg-x11-6.8.2-1.FC3.45.2 (on FC3) caused similar problem for me with
HP D530, Dell GX260 and Dell GX270 (at least) with a variety of TFT panels.

So far, I've only tried the above options on an HP D530 with Nec 1760 TFT and
neither fixed the problem.

Comment 26 Steven Bakker 2005-10-19 05:19:31 EDT
Hi, sorry it took a while to try again with xorg-x11-6.8.2-37.FC4.49.2. Tried
the suggestions in Comment #13 (Pci0sConfig, PCIProbe1, PCIProbe2) and #20
(NoDDC, VBERestore), all failed to get a working desktop in Xinerama.

Cheers,
Steven
Comment 27 Allen 2005-11-27 17:02:01 EST
A success report.

hardware:
Rosewill R910E lcd monitor
Shuttle SB61G2v3 with onboard Intel 82865G graphics

software: all latest FC4 according to yum

Current Xorg is at 49.2 (latest). All previous xorg pkgs failed to show anything
on LCD. Last good pkgs were 45. VT's worked all along though. While
experimenting with FC5t1 had the same problem (do I report this to FC5 related
bugzilla?). Read through bugs #168764 and #169093 and the following suggested
fixes did not help: Pci0sConfig, PCIProbe1, PCIProbe2. The 'NoDDC' worked in
FC5t1. So I tried it on FC4 after upgrading to 49.2. Worked.

I can attach log files if you like. I can go back to 45 (got practice) or remove
the NoDDC option and send you the logs.
Comment 28 Tom Dunstan 2006-01-07 03:46:50 EST
Hi folks

Not sure if the problem that I'm experiencing is this bug or another one.

I just upgraded a fairly vanilla FC4 install, and my resolution fell back from a
custom 1280x800 mode which is the top res for my laptop back to 1024x768.

I had previously gotten that resolution to work by following the instrauctions
at http://www.cs.cornell.edu/~scs49/install_linux.html#destHeader107 . That had
been working up until the update that I did today.

I note that in my /var/log/Xorg.0.log, I see the line:
(II) I810(0): Not using built-in mode "1280x800_60.00" (width too large for
virtual size)

I'm pretty sure that that was the mode that I was using before the update, since
it's the one that I manually added when following the instructions linked to above.

I have tried all 5 options listed above (NoDDC etc), rebooting for each, without
luck. I'm appy to post my Xorg.0.log if that'll help. If you think this isn't
related to this bug, I'll post a new one.

Cheers, Tom

Oh, btw: Dell Inspiron 700m, Intel 855GME 
Comment 29 Mike A. Harris 2006-06-27 12:41:14 EDT
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".

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