"Richard Schwarting" <[EMAIL PROTECTED]> writes: > Yes Francisco. This has fixed the issue of being off-centre and such. > > I'll note that, though X displayed correctly, while using it, new > windows would come up simply as white boxes for the first few seconds, > I'm not sure to. As well, when I did open a window or a menu or such, > the entire desktop would freeze up for a few seconds, my cursor not > even moving and not responding to Ctrl-Alt-Fn. After those few > seconds, things would proceed. > > I tried disabling acceleration by setting Option "NoAccel". Now, my > desktop stopped freezing completely, but things still took an unusual > long time to start drawing, and the desktop felt sluggish. Reading > the man page for siliconmotion, I opted to try Option "AccelMethod" > "EXA", and now things are mostly better. Using EXA, there is the odd > glitch when the cursor hovers over a point (a rectangle around it > becomes a green color, for some inexplicable reason). > > Anyway, I'm interested in getting this fixed downstream before the > next set of distro releases so that others who suffer the same problem > won't need to wait 5 months :) What more can I do in regard to this? > Just created distro-level bug reports and point them to this thread? > > Also, I'm curious whether you have a SM720 Lynx3DM handy yourself or > whether you have to do your work via another SM card. Are they > similar enough that driver changes don't usually break support for > just one of the card types? In the future, if there are any changes > you'd be interested to see tested on an Sm720 Lynx3DM, I'd be happy to > help (presuming this tablet hasn't fallen apart first.). I'd make a > piont of testing newer versions of the driver periodically to help > catch issues with this card earlier. Though, I wonder whether I'm the > only person still using Linux on one :) > > Thank you very much. I hope to repay your helpfulness some day, as > you've really made my life a lot easier :) > > Cheers, > Richard Schwarting > > In fact, the only Silicon Motion hardware I've got access to is another SM720 card. I'm not experiencing those problems on it. Would you send a full log? (BTW, could it be related to the great amount of logging that the SMI_DEBUG flag provokes?).
> On Thu, Dec 4, 2008 at 06:51, Francisco Jerez <[EMAIL PROTECTED]> wrote: >>> 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 >>> >> Hello again, >> >> I've done some corrections to the mode setting code (I'm attaching the >> patch). Could you try it out over the last one and tell me if it works? >> >>> 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 >>>>> [email protected] >>>>> http://lists.freedesktop.org/mailman/listinfo/xorg >>>> >>>> >>>> _______________________________________________ >>>> xorg mailing list >>>> [email protected] >>>> http://lists.freedesktop.org/mailman/listinfo/xorg >>>> >>> _______________________________________________ >>> xorg mailing list >>> [email protected] >>> http://lists.freedesktop.org/mailman/listinfo/xorg >> >> _______________________________________________ >> xorg mailing list >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/xorg >> > _______________________________________________ > xorg mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xorg
pgpoxalV2FQpQ.pgp
Description: PGP signature
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
