On Tue, 1 Jan 2002, Mark Vojkovich wrote:
> In XFree86 CVS, the vesa driver appears to be doing portIO
> to legacy vga registers. This makes things complicated because
> these registers are shared between the primary and secondary
> cards, and it places a large burden upon XFree86's RAC code
> to make sure these registers are routed to the correct card
> at the correct time.
>
> My guess is that either the RAC code didn't handle this correctly
> back in 4.0.2 or the vesa driver was doing something that
> it shouldn't. The corruption you are describing actually
> sounds like the vesa driver tried to restore the console
> fonts, something it shouldn't have done if it was the
> secondary card. Actually, looking at the vesa driver in
> CVS it's not immediately obvious to me that it isn't trying
> to restore the fonts on secondary cards. These are stored
> in the first 64K or so of the framebuffer. If you've built
> from source you could try commenting the font restoration
> stuff out in the vesa driver to make sure it's not doing that.
thanks for the suggestion. i've got the cvs sources, which i used in
part to track down the minimal bit of code to reproduce the problem.
i tried commenting out the font restoration code (as well as the font
saving code) for the vesa driver (by #ifdef'ing out everything but the
decl for both SaveFonts and RestoreFonts). the same display glitch
appears after restarting X 4.0.2 with the modified vesa driver and DPMS
turned back on.
i did some grunt work to more tightly define the problem and used xmag
to count the corrupted lines. 12 fully corrupted 1280 pixels lines,
plus another 1024 corrupted pixels on the next line, for 64 kB total
corrupted memory, just as you guessed. strange that commenting out the
font code didn't do anything. i'll try adding debugging ErrorFs to
the vesa driver module just to make certain i'm loading the corrent
driver and let you know if i can narrow the problem down further that way.
the other bit that might help is this: when the screen gets into this
state, everytime i try to move the cursor to the vesa driven screen, the
corrupted bits change in time with cursor movement, almost as if the vesa
driver now thinks the display memory is mapped over the nvidia screen.
it's got to be some wierdness like that, because when i do the "xset s
reset" bit, i have to "repaint" the vesa screen (meaning i have to move
the cursor over the whole screen to force a repaint). i tend to repaint
just kpanel at the bottom until i can see the icon for a term window,
then pop up a term and use that to repaint large bits of the vesa screen.
i hope this helps some.
> If you have an option in your system bios to switch
> which card is the primary, you might try that. Both the
> "nv" and "nvidia" drivers should work OK on secondary
> cards, but with the "nvidia" drivers you may need to be
> running the very latest drivers and may need option "UseInt10Module"
> to get it to post properly.
it's a pretty old bios (old BX MB), and i don't remember such an option,
but i'll try rebooting and giving it a look. i've got oldish, but quite
stable nvidia drivers (0.9-769) installed, but i'll try upgrading to
the current batch if i can switch the geforce2 to secondary card.
> I don't know why 4.1.0 isn't working for you. Was that only
> when trying with a two card setup?
i didn't even bother to try 4.1.0 in a one card setup, although i probably
should have. i'm scrounging around for another HD so i can do a clean
install of a minimal OS and 4.1.0 to isolate that set of problems.
if it was a simple upgrade i would have just done it over 4.0.2, but
when it didn't work i backed out the upgrade and i'd really rather work
on an isolated HD 'til i get the kinks out.
thanks so much for your time, and your help. i'll see if i can't make
the vesa driver do some more tricks when i get another spare moment.
erik 'evil veteran programmer' vogan
~ Of all the races in all of the Galaxy who could have come and said a
big hello to the planet Earth, he thought, didn't it just have to be the
Vogons. - HHGttG
> On Sun, 30 Dec 2001, erik vogan wrote:
>
> > hello,
> >
> > i recently set up a dual head system running a 17" sony at
> > 1280x1024x32 bpp off an nVidia GeForce2 GTS ("screen AGP") and a 14"
> > dell monitor at 800x600x16 bpp off an ancient scavenged Diamond Stealth
> > 64 VRAM (2 MB) ("screen PCI")
> > [ XF86Config / XFree86.0.log at end of message ].
> >
> > configuration under 4.0.2 was pretty simply, and the system came
> > up and functioned (quite a shock at first). i upgraded KDE to 2.2.2
> > to allow me to use the extra screen real estate, and KDM came up fine
> > (background on both screens). upon logging a user into KWM, however,
> > the second screen blanked to the standard X hatch, then "screen AGP"
> > showed my KDE background with display artifacts across the top 30 lines
> > or so. attempting to move the cursor onto "screen PCI" (to the right)
> > caused these display artifacts to saturate the top 30 lines or so of
> > "screen AGP". pulling up a terminal window and entering "xset s reset"
> > (found in the xpert archives) corrected the problem.
> >
> > it seemed every time the screensaver kicked on the same fix ("xset
> > s reset") was required. some playing with xset allowed me to reproduce
> > the problem with "xset dpms force suspend". i've paired the xset code
> > down to minimal "break" and "fix" cases this afternoon. basically,
> > the offending lines are:
> >
> > break:
> > DPMSForceLevel(display, DPMSModeSuspend);
> >
> > fix:
> > XResetScreenSaver(display);
> >
> >
> > commenting out 'OPTION "DPMS"' in XF86Config fully corrected the
> > situation with respect to both login and coming back from the screensaver.
> >
> > conclusion 1: my Dell 14" monitor (circa 1992) does not do DPMS
> > conclusion 2: Xfree86 4.0.2 has a bug in how it deals with DPMS
> > with regard to multiheaded mixed-DPMS systems.
> >
> > this is just gross speculation, but it appears that X is somehow
> > mapping the display memory (or a portion of it) for "screen PCI" onto
> > the base of the display memory for "screen AGP" after DPMS is
> > engaged. XResetScreenSaver somehow modifies this behaviour.
> >
> > NOTE: before i played with the xset code i attempted to upgrade
> > to xfree 4.1.0, but i got nothing from KWM past the background on
> > "screen AGP" (no kpanel at the bottom of "screen AGP"), so no term window
> > to check the "xset s reset" fix. that was before i disabled DPMS,
> > and i haven't tried 4.1.0 again since i modified my setup to exclude DPMS.
> >
> > any suggestions on where to look / what to do in order to patch the
> > code to allow DPMS on the screen that supports it ? any ideas why 4.1.0
> > was such an impressive failure ?
> >
> > thanks for any pointers.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
