Bug 591 - bad video timing? Sony PCG-C1VN Vaio Picturebook notebook
Summary: bad video timing? Sony PCG-C1VN Vaio Picturebook notebook
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/mach64 (show other bugs)
Version: 6.8.1
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
Keywords: regression
Depends on:
Reported: 2004-05-03 13:50 UTC by Adam J. Richter
Modified: 2005-06-03 20:29 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

XF86Config file (5.53 KB, text/plain)
2004-05-03 13:51 UTC, Adam J. Richter
no flags Details
"Xorg -verbose" log (14.71 KB, text/plain)
2004-05-03 13:55 UTC, Adam J. Richter
no flags Details
"Xorg -logverbose 4" output from x11r6.7 server (52.80 KB, text/plain)
2004-05-05 17:34 UTC, Adam J. Richter
no flags Details
"logverbose -4" output for (51.45 KB, text/plain)
2004-05-07 08:31 UTC, Adam J. Richter
no flags Details
"logverbose -4" output for (51.44 KB, text/plain)
2004-05-07 09:31 UTC, Adam J. Richter
no flags Details
Proposed patch to pATI->LCD{V,H}Sync{Start,Width} calculation (1.02 KB, text/plain)
2004-05-08 17:14 UTC, Adam J. Richter
no flags Details
[FIXED_X11R68x] Updated patch from Marc Aurele La France (2.57 KB, patch)
2004-05-20 17:11 UTC, Adam J. Richter
roland.mainz: 6.8-branch+
Details | Splinter Review

Description Adam J. Richter 2004-05-03 13:50:44 UTC
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
Comment 1 Adam J. Richter 2004-05-03 13:51:50 UTC
Created attachment 257 [details]
XF86Config file
Comment 2 Adam J. Richter 2004-05-03 13:55:03 UTC
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)
Comment 3 Adam J. Richter 2004-05-03 20:32:20 UTC
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.
Comment 4 Adam J. Richter 2004-05-04 12:09:18 UTC
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:	Failed to compile	Failed to compile	Compiles.  Segfaults when Xorg starts after a little video
initialization.  Video modes are correctly restored after segfault.	Same result as	Compiles.  Same bad video as X11R6.7.	Compiles.  Same bad video as X11R6.7.	Compiles.  Same bad video as X11R6.7.

Comment 5 Adam J. Richter 2004-05-04 13:07:46 UTC
I have just tried rebuilding and reinstalling from the full XFree86-
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. 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, .2 and so on.
Comment 6 Adam J. Richter 2004-05-04 16:14:42 UTC
I have tried rebuilding XFree86-4.3.0 and successively patching it.  Here
are the results so far.

4.3.0		works	works (patched, make World, make install)	works (patched, cd programs/Xserver, make all, make install)	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.
Comment 7 Adam J. Richter 2004-05-04 20:20:46 UTC
I have now done a "make clean && make World && make install" on
and and confirm that the misbehavior seems to begin at	works	fails in the same way that does.
Comment 8 Adam J. Richter 2004-05-05 11:49:48 UTC
Marc Aurele La France (ATI driver author) was kind enough to reply to my email
about this problem and speculated that - would behave as 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 and x11r6.7.

Here is a summary of my experiments so far, in case my comments above are
becoming difficult to follow.


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: + Option "LcdSync" + 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:
x11r6.7 + Option "LcdSync"
x11r6.7 + Option "NoLcdSync"
Comment 9 Adam J. Richter 2004-05-05 17:34:00 UTC
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- with "-logverbose 4" produces exactly the same log file, byte
for byte.
Comment 10 Adam J. Richter 2004-05-07 08:31:24 UTC
Created attachment 271 [details]
"logverbose -4" output for

Per Marc's request, I have recorded the "-logverbose 4" output from xfree86, the last version that worked.

Among the differences between the 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- 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.
Comment 11 Adam J. Richter 2004-05-07 09:31:49 UTC
Created attachment 272 [details]
"logverbose -4" output for

The "logverbose -4" output from xfree86- (the first version that breaks
on my Picturebook) is a bit closer to that of  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
Comment 12 Adam J. Richter 2004-05-08 17:14:36 UTC
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.
Comment 13 Adam J. Richter 2004-05-20 17:11:22 UTC
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.
Comment 14 Adam J. Richter 2004-05-20 17:13:56 UTC
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. 
Comment 15 Mike A. Harris 2004-10-18 03:08:19 UTC
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.
Comment 16 Mike A. Harris 2004-10-18 03:12:30 UTC
Just noticed this bug is also misfiled against "xserver/kdrive" instead of

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).
Comment 17 Mike A. Harris 2004-10-18 03:14:58 UTC
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.
Comment 18 Dan Williams 2004-10-23 09:23:40 UTC
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 19 Daniel Stone 2004-11-22 03:01:45 UTC
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 20 Daniel Stone 2004-11-22 03:02:16 UTC
Comment on attachment 278 [details]
Proposed patch to pATI->LCD{V,H}Sync{Start,Width} calculation

wrong patch
Comment 21 Daniel Stone 2004-11-22 03:02:26 UTC
Comment on attachment 308 [details] [review]
[FIXED_X11R68x] Updated patch from Marc Aurele La France

ask about the right patch
Comment 22 Roland Mainz 2004-12-08 05:57:38 UTC
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 23 Roland Mainz 2004-12-14 23:59:07 UTC
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  <-- 
new revision:; previous revision: 1.3
/cvs/xorg/xc/programs/Xserver/hw/xfree86/drivers/ati/ativga.c,v  <--  ativga.c
new revision:; 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...
Comment 24 Adam Jackson 2005-04-03 14:46:43 UTC
mass update: this bug was applied to the stable 6.8 branch but NOT to HEAD!
Comment 25 Alan Coopersmith 2005-06-04 13:29:40 UTC
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:
        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.