On Fri, Feb 25, 2005 at 07:35:37PM +0100, Nicolas Joly wrote: >On Wed, Feb 23, 2005 at 08:44:16PM -0500, David Dawes wrote: >> On Mon, Feb 21, 2005 at 03:01:29PM +0100, Nicolas Joly wrote: >> >On Fri, Feb 18, 2005 at 05:04:15PM -0500, David Dawes wrote: >> >> On Fri, Feb 18, 2005 at 07:51:56PM +0100, Nicolas Joly wrote: >> >> >On Thu, Feb 17, 2005 at 04:20:12PM -0500, David Dawes wrote: >> >[...] >> >> >> Another step would be to compare the sequence and parameters for the int10 >> >> >> calls made by the 4.4.0 version of the driver vs the current version. >> >> > >> >> >Will check and report a little later. Any simple way to proceed ? >> >> >> >> The easiest way to do that would be to edit the xf86ExecX86int10_wrapper() >> >> macro in i810/common.h and have it print out the ax, bx and cx >> >> fields of pInt. I would try that with and without enabling the >> >> PrintErrorState() calls that are there. >> > >> >Attached the 2 logs for 4.4.0 and 4.5.0 with int10 ax,bx and cx >> >values, but without PrintErrorState. >> > >> >I'm starting to recompile the modules to include the PrintErrorState() >> >calls ... >> >> I've had a look through the logs you sent, but I don't see anything >> obvious problem. The following lines in one of the logs are not good: >> >> (WW) I810(0): PRB0_CTL (0x000b6007) indicates ring buffer enabled >> (WW) I810(0): PRB0_HEAD (0x008b662c) and PRB0_TAIL (0x00092660) indicate ring buffer not flushed >> >> but they don't appear in the second set of logs. > >Yes. I don't always have them, but i can't figure why yet. > >> The only other thing I can think of right now is to trace through which >> call to VBESetVBEMode is made, and print the parameters in each case, and >> call I830_dump_registers() before the VBESetVBEMode() calls. You'll need >> to build with I830DEBUG defined (uncomment it in i830.h). > >Log file attached. > >I made some other tests today and noticed a few things: > >- The loop problem only occurs with the "unusual" 1024x600 mode. Even > Windows does not deal with that mode. Looks like a BIOS bug ? Most likely, yes. >- The missing 1024x768 mode, that was there with the previous realease > module, seems to be invalidated due to HSync not in default range. > I'm getting a value of 33.8, indeed outside from 28.00-33.00 > range. > I'm currently thinking that the new `i830GetModePool()' function > does not give exactly the same results as `VBEGetModePool()'. > I can get this working mode back by increasing the HSync range to > 28.00-34.00 kHz. In the absence of DDC-probed monitor parameters or explicitly specified parameters, it seems that the fallback monitor defaults were not getting set before VBEGetModePool() was called. Thus, modes that should have been excluded were not being excluded. The vesa driver still has this bug. I'll look into fixing VBEGetModePool() to correctly handle this situation, and add warnings to xf86CheckModeForMonitor() for when it is called before monitor parameters are set. This has been resolved in the current i830 driver, which accounts for the change in behaviour that you are seeing. However, in the case of flat panels, the driver can and should set better default monitor parameters, namely parameters that are consistent with a panel sized mode at 60Hz refresh. Most drivers probably still don't handle this correctly. I modified the neomagic driver to do this shortly before the 4.4.0 release, and that's a good example of how it can be done. David _______________________________________________ XFree86 mailing list XFree86@xxxxxxxxxxx http://XFree86.Org/mailman/listinfo/xfree86
