Hello. I'm not sure if that changed anything, but things sort of work.
After patching, recompiling, and reinstalling the driver, X would still be off centre. However, I restarted the computer the first time I ran X, everything appeared as I would hope. I then brought it down and back up again, but it was out of centre again. Restarting it a dozen times didn't help. However, I tried putting my computer to sleep and waking it up, and, as with a fresh restart, X displayed correctly again. However, simply switching VTs to a console and back to X make it off again. I've updated the bug[1] with the log file with SMI_DEBUG defined and from a session of (after resuming from suspend): X working, switching to a console, switching back to not having it work. Would it be worthwhile to have me try the driver without the patch again and see whether I can make it work after suspend/resume or a power cycle? Thanks again Francisco. Richard 1. https://bugs.freedesktop.org/show_bug.cgi?id=18816 On Tue, Dec 2, 2008 at 15:32, Francisco Jerez <[EMAIL PROTECTED]> wrote: >> Thank you, again. >> >> Yes, the MTRR errors do not appear to be fatal. >> >> Option "UseBIOS" "off" makes a big difference. The screen is no >> longer just black, and I can see a background and the moving cursor! >> However, it is as though the hsync and vsync are terribly off- as the >> display is quite a bit off-centre, wraps around the screen, is >> sometimes repeated along the horizontal, and has visible moving scan >> lines. >> > Hi, I think I have reproduced your problem, maybe the offset display is > because screen centering is active on server start up. > > If so, the patch I'm attaching will probably solve it. > > BTW, I wonder if the UseBIOS option should default to off, with all > these laptops with broken bioses. > >> I have uploaded a copy of my Xorg.0.log using the "UseBIOS" "off" and >> using -logverbose 7 to the bug: >> https://bugs.freedesktop.org/show_bug.cgi?id=18816 >> >> I will replace it with one with SMI_DEBUG defined this afternoon (I >> didn't have time this morning :D). >> >> I will also try different combinations of modes and v/hsync, though >> I'm wondering whether the offset weird display is actually caused by >> incorrectly set values for them, as I've tried rates that had worked >> previously. >> >> Cheers, >> Richard Schwarting >> >> On Tue, Dec 2, 2008 at 04:48, Francisco Jerez <[EMAIL PROTECTED]> wrote: >>> Hi, >>> >>> "Richard Schwarting" <[EMAIL PROTECTED]> writes: >>> >>>> Thanks for the responses. >>>> >>>> == Silicon Motion from git == >>>> >>>> Yes Francisco, I've tried the latest code from >>>> git://anongit.freedesktop.org/xorg/driver/xf86-video-siliconmotion and >>>> that led to what I thought was the same error, since I was still left >>>> with a blank screen, but now I see that it is differently. >>>> >>>> Having just recompiled that driver, I get the following when running: >>>> (==) Log file: "/var/log/Xorg.0.log", Time: Tue Dec 2 00:24:54 2008 >>>> (==) Using config file: "/etc/X11/xorg.conf" >>>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1) >>>> Invalid argument (22) >>>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1) >>>> Invalid argument (22) >>>> error setting MTRR (base = 0x14200000, size = 0x00800000, type = 1) >>>> Invalid argument (22) >>>> >>> That happened because the SM720 framebuffer aperture is misaligned, I >>> think the old pci layer code handled that automatically and split the >>> memory range across several MTRRs. >>> >>> That error is worrisome, but it shouldn't be fatal. I think I'll have >>> a look at it soon. >>> >>>> Of course, I should perhaps try the recent git silicon motion driver >>>> with the current Xorg server in git, so I'm leaving that to set up >>>> overnight. >>>> >>>> note: The vesa driver doesn't work with this card for me either right now. >>>> >>>> == MTRR error context == >>>> >>>> For some added context, that error "error setting MTRR" appears to >>>> come from the function "pci_device_linux_sysfs_map_range(...)" from >>>> libpciaccess's linux_sysfs.c which appears to get called as a method >>>> "map_range" of a structure of struct pci_system_methods >>>> linux_sysfs_methods. >>>> >>>> I think this would be the map_range that's being called in >>>> libpciaccess's pci_device_map_range in the lines: >>>> err = (*pci_sys->methods->map_range)(dev, >>>> >>>> &mappings[devp->num_mappings]); >>>> I'll try to verify that tomorrow. >>>> >>>> == Xorg.0.log == >>>> >>>> For the Xorg.0.log from a run with the Xorg server packaged in Ubuntu >>>> 8.10 and the current Silicon Motion driver from git, I've attached it >>>> to: >>>> https://bugs.freedesktop.org/attachment.cgi?bugid=18816 >>>> >>> >>> I had a look at it, and I suspect that you could get it working >>> again by using Option "UseBIOS" "off" (or maybe Option "NoAccel") in >>> the device config file section, but I don't exactly know what is going >>> on. Could you send a more verbose log, e.g. with the "-logverbose 7" >>> server option, and maybe rebuild the driver with "-DSMI_DEBUG" among >>> the CFLAGS? >>> >>>> == Random Thoughts == >>>> >>>> Since I think this is the same issue I encountered with Fedora 9 at >>>> the start of the summer, I'm wondering whether I'm the only Linux user >>>> left using this particular card or whether the others are just >>>> avoiding the current X (or whether my system is in a faulty >>>> configuration) :D >>> >> _______________________________________________ >> xorg mailing list >> xorg@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/xorg > > > _______________________________________________ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg