On Mon, 2003-10-20 at 18:40, David Dawes wrote:
> On Mon, Oct 20, 2003 at 11:13:12AM +0300, Alexey E. Suslikov wrote:
> >keywords: openbsd, x11, i830, ring buffer, lockup
> >
> >> It just occurred to me where I had seen this type of black screen problem
> >> before. It happens when using the "vesa" driver with an 845G. We work
> >> around this in the i810 driver by remembering the initial video mode
> >> and simply re-initialising it when exiting/VT switching instead of using
> >> the VBE save/restore mechanism. This workaround is only actived for
> >> 845G hardware. You could try enabling it for all hardware by changing
> >> this line in i830_driver.c from:
> >>
> >> if (!I845G_VBE_WORKAROUND || !IS_845G(pI830)) {
> >>
> >> to:
> >>
> >> if (!I845G_VBE_WORKAROUND) {
> >
> >hmmm... my yesterdays reply was lost somewhere... ok, let's repeat :)
> >
> >turning on I845G_VBE_WORKAROUND magically SOLVES the problem on
> >4.3.99.14 in both accel and noaccel setups:
> >
> > VideoRam
> > default(8192) 2048 32768
> >Accel ok ok ok
> >NoAccel ok ok ok
> >NoAccel+SWcursor ok ok ok
>
> That's good news.
>
> >David, thanks a lot. if you have some spare time, can you write some
> >explanations on this case?
>
> It's pretty much as I already said. Without this workaround, the driver
> (just like the vesa driver) uses the video BIOS VBE save/restore calls
> to save and restore the original video mode. Using these appears to be
> a problem in at least some cases. I only ever saw the problem with 845G
> systems, and so only enabled the workaround for that case.
>
> The workaround instead saves the original mode number, and uses the
> VBE set mode call to go back to that original mode when exiting or VT
> switching.
>
> In the 845G cases I saw, where even the generic vesa driver showed this
> problem consistently at the first VT switch or exit, it must be a bug
> in the video BIOSes. There are a lot of other variables in the i810/i830
> driver case.
>
> Anyway, I'll commit a fix to enable this workaround by default in all cases.
>
> Thanks for the detailed testing and reporting.
I haven't been following this too closely, but was this happening only
on BSDs? The VBE thing stuck out in my mind, as there was just an issue
in DRI (the radeon mergedfb changes) where using the generic int10
emulation caused the driver to crash, while the linux-specific one
didn't. I don't think it got tracked down and a later change fixed it,
but might there be general problems with the generic int10 emulation? I
know many FreeBSD systems get warnings in the logs about "Bad V_BIOS
checksum." Would any of this be significant?
--
Eric Anholt eta@xxxxxxxxxx
http://people.freebsd.org/~anholt/ anholt@xxxxxxxxxxx
_______________________________________________
XFree86 mailing list
XFree86@xxxxxxxxxxx
http://XFree86.Org/mailman/listinfo/xfree86
