Bug 3557 - /usr/X11R6/lib/modules/libvgahw.a wreaks havoc on several video cards
Summary: /usr/X11R6/lib/modules/libvgahw.a wreaks havoc on several video cards
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/other (show other bugs)
Version: 6.8.2
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact:
: 3805 (view as bug list)
Depends on: 2976 2991 3094
  Show dependency treegraph
Reported: 2005-06-16 18:10 UTC by Jim Cornette
Modified: 2005-11-29 07:52 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Jim Cornette 2005-06-16 18:10:17 UTC
Intel, MGA and many other video cards are failing because of 
in the version of X released with FC4 and which was in FC4 test versions midstream.

I feel that this library and its routines needs to be investigated with the
different video cards.

intel 815 displays a blue border with visible text and some wrapping of text output.

Intel 865G just shows no video on the VT.

This only happens once X is launched. Runlevel 3 is fine until X is started.
Runlevel 5 shows the same symptoms. so level 3 then startx and runlevel 5 act
the same>
Comment 1 Jim Cornette 2005-06-16 18:12:47 UTC
also MGA
Comment 2 Luc Verhaegen 2005-06-16 18:31:49 UTC
Yes, the blue borders is quite funny really. But it has nothing to do with
vgaHW, it has however to do with xf86Mode.c imposing old VGA blanking length
restrictions. The blue actually is the result of a wrong setup of the overscan
colour or palette. The blanking limit was worked around by overscanning, which,
when decently set up, tends to be black. But overscanning is archaic and might
confuse output devices depending on a blank signal.

I'll be using the blanking limits example as part of my presentation at the .eu
meeting sunday, as it clearly outlines the work needed at the DIX level. In this
presentation, i also outline moving away from vgaHW code. Even though vgaHW
provides a much needed abstraction mechanism for register accesses, it is needed
to keep code clear, readable and uniform.

The bad thing is that this requires a lot of work to a lot of drivers. And,
currently, barely any drivers see active work. Again, as i will outline on sunday.

So please don't dump everything on vgaHW alone.
Comment 3 Luc Verhaegen 2005-06-16 18:38:45 UTC
The unichrome driver already catches this issue btw. I've been generally aiming
for vgaHW helper independence there. You can check out via_mode.c
ViaModePrimaryVGA: "Caught X working around an old VGA limitation"
Comment 4 Jim Cornette 2005-06-16 18:51:23 UTC
Thanks for the explanation.
hopefully the intended changes correct the problem. You have a far greater
understanding of the issue than I can ever imagine to be the scope of the problem. 
I'll let the root cause be worked out by those with the greater understanding of
the problem.
As a curiousity, I did a cmp against the two different lib versions and got the
below output.

cmp libvgahw.a libvgahw.a.fromfc3
libvgahw.a libvgahw.a.fromfc3 differ: byte 28, line 2

The .fromfc3 version is from FC3 and the libvgahw.a version is from

Comment 5 Jim Cornette 2005-06-23 17:19:41 UTC
Added Trident video card to reference
Comment 6 Adam Jackson 2005-06-25 14:47:55 UTC
there's a downstream bug about this where gcc4 miscompiles vgahw.  i don't have
the url handy though.
Comment 8 Jim Cornette 2005-07-15 12:04:57 UTC
This bug problem most likely can be cured by adding volatile to the source code
in areas where it is needed.
discusses sample programs and such.
Could this parameter be added to xf86Mode.c who know programming?

gcc4 seems to need this in the code now.
Comment 9 Jim Cornette 2005-07-15 12:07:54 UTC
I meant could this parameter be added to the source code where it is
appropriate? xf86Mode.c seems to be a logical first choice to attempt the
addition of the volatile parameter.
Comment 10 Adam Jackson 2005-08-01 10:10:41 UTC
*** Bug 3805 has been marked as a duplicate of this bug. ***
Comment 11 Alan Hourihane 2005-11-30 02:52:19 UTC
Closing. Bug in gcc4 caused miscompilation.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.