Fwd: X.org PCI changes breaks support for Silicon Motion SM720 Lynx3DM card?

Francisco Jerez currojerez at gmail.com
Sat Dec 6 14:42:35 PST 2008 

"Richard Schwarting" <aquarichy at gmail.com> 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 <currojerez at gmail.com> 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 <currojerez at gmail.com> 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 <currojerez at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> "Richard Schwarting" <aquarichy at gmail.com> 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 at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>>>
>>>>
>>>> _______________________________________________
>>>> xorg mailing list
>>>> xorg at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>>>
>>> _______________________________________________
>>> xorg mailing list
>>> xorg at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
>> _______________________________________________
>> xorg mailing list
>> xorg at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xorg
>>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20081206/1169ba95/attachment.pgp>

More information about the xorg mailing list