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

Richard Schwarting aquarichy at gmail.com
Sat Dec 6 12:05:36 PST 2008 

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


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
>

More information about the xorg mailing list