| 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: | |
| Severity: | major | ||
| Priority: | high | CC: | libv |
| Version: | 6.8.2 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 2976, 2991, 3094 | ||
| Bug Blocks: | |||
|
Description
Jim Cornette
2005-06-16 18:10:17 UTC
also MGA 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 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! 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. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242 (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. 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. 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. |
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.