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
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.
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"
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
As a curiousity, I did a cmp against the two different lib versions and got the
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
Added Trident video card to reference
there's a downstream bug about this where gcc4 miscompiles vgahw. i don't have
the url handy though.
(and 10 million others) ;)
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.
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.
*** Bug 3805 has been marked as a duplicate of this bug. ***
Closing. Bug in gcc4 caused miscompilation.