Previous versions of XFree86 worked on my Sony PCG-C1VN Picturebook notebook computer's 1024x480 flat panel display at its native resolution. X11R6.7 does not. Under X11R6.7, the panel turns black the pixels slowly turn bright white in a circular pattern radiating inward toward the center of the screen, which I assume is some kind of analog effect from the flat panel being fed some kind of invalid video mode. I don't leave the display in this state for more than a few seconds for fear of doing permanent hardware damage. However, I have left it in this state long enough to compensate for the fact that X11R6.7 takes much longer to start on my other machines than previous versions of XFree86. The default text video mode is restored if I hit Ctrl-Alt-Backspace to make the X server exit or Ctrl-Alt-F1 to make the X server switch to the first text virtual console. (Note that I have to hit these keys repeatedly and quickly, or they have no effect, but I believe that behavior started in a recent version of XFree86.) According to the attached XFree86 log, the computer has an ATI video chip and a Sharp flat panel. The following variants also produce the same apparent hardware timing problem on the display: 1. Deleting all of the Modeline statement from my /etc/XF86Config. 2. Replacing the "1024x480" Modeline with one that I derive from the remark in the log file 'Built-in mode "Native panel mode:" 42.MHz 40.8 kHz, 84.6 Hz'. 3. Removing /etc/XF86Config 4. Deleting the 'driver "ati"' line from /etc/XF86Config. Other notes: 1. Changing 'driver "ati"' to 'driver "radeon"' results in an error message about no screens being found. 2. Replacing 'driver "ati"' with 'driver "vga"' results in an apparently working 640x480 display. I suspect that it is only in 16 colors and unaccelerated, although I haven't checked, since I'm more concerned about having the ati driver working again. I will attach my XF86Config file at the output from the X server when run with "-verbose."
Created attachment 257 [details] XF86Config file
Created attachment 258 [details] "Xorg -verbose" log By the way, messages like the following surprise me, given that the flat panel is 1024x480 (i.e., larger than 400x300). (II) ATI(0): Not using default mode "400x300" (exceeds panel dimensions)
To avoid duplication of effort, I should mention that the patch at http://www.bastille-linux.org/jay/vaio.html did not have any effect.
I have tried replacing X11R6.7/programs/Xservers/hw/xfree86/drivers/ati with the corresponding directory from some previous XFree86 snapshots from ftp://ftp.xfree86.org/pub/XFree86/develsnaps/. The results were: 4.3.99.9 Failed to compile 4.3.99.13 Failed to compile 4.3.99.14 Compiles. Segfaults when Xorg starts after a little video initialization. Video modes are correctly restored after segfault. 4.3.99.15 Same result as 4.3.99.14. 4.3.99.16 Compiles. Same bad video as X11R6.7. 4.3.99.901 Compiles. Same bad video as X11R6.7. 4.3.99.902 Compiles. Same bad video as X11R6.7.
I have just tried rebuilding and reinstalling from the full XFree86-4.3.99.9 snapshot, as opposed to just copying the programs/Xserver/hw/xfree86/drivers/ati directory into the X11R6.7 tree. That resulted in a X server with a very different malfunction. At first the screen is solid black, but then there is a solid white rectangle, perhaps 64x64 at the left edge of the screen, that keep scrolling down and then appearing reappearing at the top. The rest of the screen is solid black, except that every half second or so, it will briefly change to a black and white pattern that looks like a corrupted version of the X "root weave" pattern. 4.3.99.9 is the earliest "develsnap" that is still available as a full .tar.bz2 file from ftp://ftp.xfree86.org/pub/XFree86/develsnaps/, although there are diff files for 4.3.99.1, .2 and so on.
I have tried rebuilding XFree86-4.3.0 and successively patching it. Here are the results so far. 4.3.0 works 4.3.99.1 works (patched, make World, make install) 4.3.99.2 works (patched, cd programs/Xserver, make all, make install) 4.3.99.3 Running XFree86 fails with unresolved Mach64 symbols after having done only an incremental rebuild and install from the programs/Xserver directory. Now I'm doing a full make clean, make World, make install. However, since I will be gone for the next few hours, I am posting this update now.
I have now done a "make clean && make World && make install" on 4.3.99.2 and 4.3.99.3 and confirm that the misbehavior seems to begin at 4.3.99.3. 4.3.99.2 works 4.3.99.3 fails in the same way that 4.3.99.9 does.
Marc Aurele La France (ATI driver author) was kind enough to reply to my email about this problem and speculated that 4.3.99.10 - 4.3.99.15 would behave as 4.3.99.9 does. I have now verified that this is true at least for .13, .14 and .15 (each rebuilt with "make clean && make World && make install"). Marc also suggested that I try Option "LcdSync" or Option "NoLcdSync". These had no effect either way with 4.3.99.15 and x11r6.7. Here is a summary of my experiments so far, in case my comments above are becoming difficult to follow. Works: 4.3.0 4.3.99.1 4.3.99.2 White rectangle repeatedly scrolling down left side of screen. Rest of screen is usually black but periodically flashes a corrupted image every half second or so: 4.3.99.3 4.3.99.9 4.3.99.13 4.3.99.14 4.3.99.15 4.3.99.15 + Option "LcdSync" 4.3.99.15 + Option "NoLcdSync" Really wrong video, same as x11r6.7. Screen goes solid black, then gradually change to white in a pattern radiating in from the outside borders. This appears to be some kind of physical effect on the panel from a really bad video mode or perhaps no signal at all while the back light is still on: 4.3.99.16 4.3.99.901 4.3.99.902 x11r6.7 x11r6.7 + Option "LcdSync" x11r6.7 + Option "NoLcdSync"
Created attachment 265 [details] "Xorg -logverbose 4" output from x11r6.7 server Marc asked for the output from "Xorg -logverbose 4", so I'll also include it here in case it becomes useful to anyone else. XFree86-4.3.99.15 with "-logverbose 4" produces exactly the same log file, byte for byte.
Created attachment 271 [details] "logverbose -4" output for 4.3.99.2 Per Marc's request, I have recorded the "-logverbose 4" output from xfree86 4.3.99.2, the last version that worked. Among the differences between the 4.3.99.2 and x11r6.7 logs, I notice that the following messages are absent from the x11r6.7 log: (II) ATI(0): BIOS Data: BIOSSize=0x10000, ROMTable=0x0106. (II) ATI(0): BIOS Data: ClockTable=0x0A1E, FrequencyTable=0x09F8. (II) ATI(0): BIOS Data: LCDTable=0x0178, LCDPanelInfo=0xEC62. (II) ATI(0): BIOS Data: VideoTable=0x0000, HardwareTable=0x0156. (II) ATI(0): BIOS Data: I2CType=0x0F, Tuner=0x00, Decoder=0x00, Audio=0x0F. Also, several of the Mach64 "non-shadow register values" and "shadow register values" are different. I suspect that my statement that the x11r6.7 log and the xfree86-4.3.99.15 logs were identical was a mistake, because the log file includes some version information. I probably accidentally made two copies of the same log file.
Created attachment 272 [details] "logverbose -4" output for 4.3.99.3 The "logverbose -4" output from xfree86-4.3.99.3 (the first version that breaks on my Picturebook) is a bit closer to that of 4.3.99.2. So, examining it may help point to the most relevant changes. For example, only five bits are different in the "Mach64 non-shadow register values": - 0x1410: 010103FF 0A000000 88000024 02002400 + 0x1410: 011503FF 0A000000 88000024 02002400 ^^ - 0x1460: 5C10152C 03A087E4 00000000 00000000 + 0x1460: 5E10152C 13A087E4 00000000 00000000 ^ ^ - 0x14A0: 73330001 00000401 0075249E E0000C81 + 0x14A0: 73330001 00000401 4075249E E0000C81 ^
Created attachment 278 [details] Proposed patch to pATI->LCD{V,H}Sync{Start,Width} calculation Marc sent me a patch which fixed the problem, except for what appeared to be a one pixel tall horizontal white line at the bottom of the screen. I've made the following patch from Marc's idea which seems to make the video work OK. If Marc thinks that this patch is right, I will change the bug's status to resolved. In the meantime, I'll leave the bug report open as I'd like to give Marc a chance to comment while I wanted to report this news in the bug database as soon as possible.
Created attachment 308 [details] [review] [FIXED_X11R68x] Updated patch from Marc Aurele La France Apparently, the "+ 1"'s were not necessary at all. Here is a new patch that reflects that from Marc. Marc's patch also includes a change to drivers/ati/ativga.c that I don't quite understanding. I think its purpose might be to address the same problem on some other hardware, but I'm not sure. Applying just the change to atipreinit.c works OK, but I'm posting Marc's entire patch for completeness. Marc says he plans to develop some other more general change for the next XFree86 release.
Since the updated change from Marc seems to fix the problem, I am changing this bug's status to "fixed", although I'm not sure if changing status to "fixed" is supposed to wait until the patch is integrated into some X.org source tree.
Someone just pointed out on the "xorg" mailing list that the issue reported in this bug report is not "FIXED". Technically "FIXED" means that the a solution to the problem has been found, and has been committed directly into X.Org CVS. Once it is committed to CVS, then the bug report can safely and correctly be marked "FIXED". This bug was closed "FIXED" just because there is a patch attached that fixes it, however bugs marked "FIXED" will never get looked at by anyone, because "FIXED" means "is in CVS", so there's no point to ever look at bugs that are in the "FIXED" state. Please leave bugs open until the code is in CVS.
Just noticed this bug is also misfiled against "xserver/kdrive" instead of "xorg". Someone asked on the mailing list why this bug wasn't ever fixed. Well now you know. ;o) File bugs against the correct product, assigned to the correct component, and then leave them open until any fixes are committed to CVS. Once committed to CVS, the developer who did so will close the bug as "FIXED". Since this was filed against the wrong component then closed as "FIXED", it's of no surprised that nobody ever looked at it again, and the bug allegedly exists in xorg still (I haven't confirmed this, but am taking the person's word for it from xorg list).
An additional note, is that part of this patch appears might be applied to current CVS head. It isn't clear if the entire thing is in CVS head currently or not, however someone can check and confirm/deny.
Mike, just checked, and none of this patch has been applied to HEAD as of the date of this reply. Its quite a small patch too. Any way to get it committed since its been sitting around for a while and is fairly simple?
Comment on attachment 278 [details] Proposed patch to pATI->LCD{V,H}Sync{Start,Width} calculation would be nice to have along with benh's patch (due tomorrow apparently)
Comment on attachment 278 [details] Proposed patch to pATI->LCD{V,H}Sync{Start,Width} calculation wrong patch
Comment on attachment 308 [details] [review] [FIXED_X11R68x] Updated patch from Marc Aurele La France ask about the right patch
Comment on attachment 308 [details] [review] [FIXED_X11R68x] Updated patch from Marc Aurele La France Approved in the 2004-12-06 release-wranglers conference call (the author needs to be explicitly listed in the commit comment). Please do not commit it yourself, I'll do that later today...
Comment on attachment 308 [details] [review] [FIXED_X11R68x] Updated patch from Marc Aurele La France Patch checked-in into X11R6.8.x stable branch: /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.365.2.84; previous revision: 1.365.2.83 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/atipreinit.c,v <-- atipreinit.c new revision: 1.3.4.1; previous revision: 1.3 /cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/ativga.c,v <-- ativga.c new revision: 1.2.4.1; previous revision: 1.2 cvs commit: Using deprecated info format strings. Convert your scripts to use the new argument format and remove '1's from your info file format strings. Mailing the commit message to xorg-commit@lists.freedesktop.org...
mass update: this bug was applied to the stable 6.8 branch but NOT to HEAD!
Patch committed to Xorg CVS head as well now, closing as FIXED for real this time. CVSROOT: /cvs/xorg Module name: xc Changes by: alanc@gabe.freedesktop.org 05/06/04 13:26:28 Log message: 2005-06-04 Alan Coopersmith <alan.coopersmith@sun.com> * programs/Xserver/hw/xfree86/drivers/ati/ativga.c: * programs/Xserver/hw/xfree86/drivers/ati/atipreinit.c: Sync with 6.8.2 branch: Bug #591 (https://bugs.freedesktop.org/show_bug.cgi?id=591) attachment #308 [details] [review] (https://bugs.freedesktop.org/attachment.cgi?id=308): Fix video timing problems with Sony PCG-C1VN Vaio Picturebook notebook && co. Patch by Marc Aurele La France Modified files: ./: ChangeLog xc/programs/Xserver/hw/xfree86/drivers/ati/: ativga.c atipreinit.c Revision Changes Path 1.974 +10 -0 xc/ChangeLog 1.4 +10 -0 xc/programs/Xserver/hw/xfree86/drivers/ati/ativga.c 1.5 +3 -2 xc/programs/Xserver/hw/xfree86/drivers/ati/atipreinit.c
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.