|Summary:||/usr/X11R6/lib/modules/libvgahw.a wreaks havoc on several video cards|
|Product:||xorg||Reporter:||Jim Cornette <jim-cornette>|
|Component:||Lib/other||Assignee:||Xorg Project Team <xorg-team>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:||2976, 2991, 3094|
Description Jim Cornette 2005-06-16 18:10:17 UTC
Intel, MGA and many other video cards are failing because of /usr/X11R6/lib/modules/libvgahw.a 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
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 xorg-x11-6.8.2-37 Thanks!
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 7 Mike A. Harris 2005-07-13 02:55:38 UTC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242 (and 10 million others) ;)
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. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162274 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.