"Richard Schwarting" <[EMAIL PROTECTED]> writes: > 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
From 9c512b76b7a1255afaa33d9477f2d7a27ec69b55 Mon Sep 17 00:00:00 2001
From: Francisco Jerez <[EMAIL PROTECTED]>
Date: Thu, 4 Dec 2008 15:35:22 +0100
Subject: [PATCH] Some corrections on the Lynx modesetting code.
This fixes 1280x1024 modes on the VGA output with dual head on.
Also, solve a build problem when using -DSMI_DEBUG, as pointed by
Richard Schwarting.
---
src/smi.h | 2 +-
src/smilynx_crtc.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/src/smi.h b/src/smi.h
index 05332f7..fe8d2e6 100644
--- a/src/smi.h
+++ b/src/smi.h
@@ -274,7 +274,7 @@ extern int smi_indent;
# define VERBLEV 1
# define ENTER() xf86ErrorFVerb(VERBLEV, "%*c %s\n",\
smi_indent++, '>', __FUNCTION__)
-# define LEAVE(value) \
+# define LEAVE(...) \
do { \
xf86ErrorFVerb(VERBLEV, "%*c %s\n", \
--smi_indent, '<', __FUNCTION__); \
diff --git a/src/smilynx_crtc.c b/src/smilynx_crtc.c
index f56fd2e..b897ce1 100644
--- a/src/smilynx_crtc.c
+++ b/src/smilynx_crtc.c
@@ -214,8 +214,11 @@ SMILynx_CrtcModeSet_vga(xf86CrtcPtr crtc,
ScrnInfoPtr pScrn=crtc->scrn;
SMIPtr pSmi = SMIPTR(pScrn);
vgaHWPtr hwp = VGAHWPTR(pScrn);
+ int vgaIOBase = hwp->IOBase;
+ int vgaCRIndex = vgaIOBase + VGA_CRTC_INDEX_OFFSET;
+ int vgaCRData = vgaIOBase + VGA_CRTC_DATA_OFFSET;
vgaRegPtr vganew = &hwp->ModeReg;
- CARD8 SR6C, SR6D;
+ CARD8 SR6C, SR6D, CR30, CR33;
ENTER();
@@ -259,14 +262,38 @@ SMILynx_CrtcModeSet_vga(xf86CrtcPtr crtc,
}
vganew->MiscOutReg |= 0x20;
- if(pSmi->Chipset != SMI_COUGAR3DR){
- /* Enable LCD */
- VGAOUT8_INDEX(pSmi, VGA_SEQ_INDEX, VGA_SEQ_DATA, 0x31,
- VGAIN8_INDEX(pSmi, VGA_SEQ_INDEX,VGA_SEQ_DATA,0x31) | 0x01);
+ {
+ unsigned long HTotal=(mode->CrtcHTotal>>3)-5;
+ unsigned long HBlankEnd=(mode->CrtcHBlankEnd>>3)-1;
+ unsigned long VTotal=mode->CrtcVTotal-2;
+ unsigned long VDisplay=mode->CrtcVDisplay-1;
+ unsigned long VBlankStart=mode->CrtcVBlankStart-1;
+ unsigned long VBlankEnd=mode->CrtcVBlankEnd-1;
+ unsigned long VSyncStart=mode->CrtcVSyncStart;
+
+ /* Fix HBlankEnd/VBlankEnd */
+ if((mode->CrtcHBlankEnd >> 3) == (mode->CrtcHTotal >> 3)) HBlankEnd=0;
+ if(mode->CrtcVBlankEnd == mode->CrtcVTotal) VBlankEnd=0;
+
+ vganew->CRTC[3] = (vganew->CRTC[3] & ~0x1F) | (HBlankEnd & 0x1F);
+ vganew->CRTC[5] = (vganew->CRTC[5] & ~0x80) | (HBlankEnd & 0x20) >> 5 << 7;
+ vganew->CRTC[22] = VBlankEnd & 0xFF;
+
+ /* Write the overflow from several VGA registers */
+ CR30 = (VGAIN8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x30) & 0x30) |
+ (HTotal & 0x100) >> 8 << 6 |
+ (VTotal & 0x400) >> 10 << 3 |
+ (VDisplay & 0x400) >> 10 << 2 |
+ (VBlankStart & 0x400) >> 10 << 1 |
+ (VSyncStart & 0x400) >> 10 << 0;
+ CR33 = (HBlankEnd & 0xC0) >> 6 << 5 | (VBlankEnd & 0x300) >> 8 << 3;
}
vgaHWRestore(pScrn, vganew, VGA_SR_MODE);
+ VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x30, CR30);
+ VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x33, CR33);
+
LEAVE();
}
@@ -335,6 +362,7 @@ SMILynx_CrtcModeSet_crt(xf86CrtcPtr crtc,
unsigned long VSyncStart=mode->CrtcVSyncStart;
unsigned long VSyncEnd=mode->CrtcVSyncEnd;
+ /* Fix HBlankEnd/VBlankEnd */
if((mode->CrtcHBlankEnd >> 3) == (mode->CrtcHTotal >> 3)) HBlankEnd=0;
if(mode->CrtcVBlankEnd == mode->CrtcVTotal) VBlankEnd=0;
@@ -364,6 +392,13 @@ SMILynx_CrtcModeSet_crt(xf86CrtcPtr crtc,
(VBlankStart & 0x200) >> 9 << 5 );
VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x4C, HDisplay & 0xFF );
VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x4D, VDisplay & 0xFF );
+ VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x30,
+ (VGAIN8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x9E) & 0x30) |
+ (HTotal & 0x100) >> 8 << 6 |
+ (VTotal & 0x400) >> 10 << 3 |
+ (VDisplay & 0x400) >> 10 << 2 |
+ (VBlankStart & 0x400) >> 10 << 1 |
+ (VSyncStart & 0x400) >> 10 << 0);
VGAOUT8_INDEX(pSmi, vgaCRIndex, vgaCRData, 0x33,
(HBlankEnd & 0xC0) >> 6 << 5 |
(VBlankEnd & 0x300) >> 8 << 3);
--
1.5.6.5
pgpOdcRuoHrqK.pgp
Description: PGP signature
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
