Bug 591

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