Bug 14223

Summary: [945GM TV s-video] output in gray scale
Product: xorg Reporter: William Grzybowski <william88>
Component: Driver/intelAssignee: Wang Zhenyu <zhenyu.z.wang>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: minor    
Priority: low CC: gordon.jin, haien.liu, michael.fu, sebastian-keller, william88
Version: gitKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log
william88: 6.9/7.0+
xrandr --verbose
william88: 6.9/7.0+
xorg.conf
none
dmesg (kernel 2.6.24)
none
acpidump
none
Xorg log with ModeDebug enabled
none
lspci -v
none
"lspci -v" on the 915GM laptop
none
xorg log from git driver version of 2008-11-06 none

Description William Grzybowski 2008-01-24 02:09:31 UTC
The TV S-Video output of my Acer Aspire 5570Z stays in gray scale, doesn't matter if i set the TV_FORMAT to NTSC, PAL, PAL-M on the laptop with xrandr --output TV --set TV_FORMAT XXX or change the format on my TV (auto, NTSC, PAL-M, PAL-N)

It works fine on another OS (Windows)
Comment 1 Gordon Jin 2008-01-24 04:32:50 UTC
William, please attach xorg.conf, Xorg.0.log, and the output of xrandr --verbose.
Comment 2 William Grzybowski 2008-01-24 06:06:30 UTC
Created attachment 13902 [details]
Xorg log
Comment 3 William Grzybowski 2008-01-24 06:07:02 UTC
Created attachment 13903 [details]
xrandr --verbose
Comment 4 William Grzybowski 2008-01-24 06:07:28 UTC
Created attachment 13904 [details]
xorg.conf
Comment 5 Eric Anholt 2008-01-24 10:27:06 UTC
Please do not mess around with the 6.9/7.0+ flag.
Comment 6 William Grzybowski 2008-01-24 10:31:48 UTC
Sorry, I didn't know that, I tought it was just to tell aobut the Xorg version, my mistake.
Comment 7 Gordon Jin 2008-01-24 18:33:07 UTC
xrandr --verbose still shows NTSC-M:
	TV_FORMAT: NTSC-M
	supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
	           PAL-N        PAL

Can you make sure it's really changed to "TV_FORMAT: PAL" after you run xrandr command to set PAL? "--mode xxx" may be required for this command to take effect(at least it used to be). 
Comment 8 William Grzybowski 2008-01-25 02:32:19 UTC
Yes, I already tried that, i just did send you with NTSC because i tought you just wanted to see some options.
xrandr --verbose wih TV_FORMAT = PAL, stills gray =(

TV connected 800x600+0+0 (0x73) normal (normal left inverted right x axis y axis
) 0mm x 0mm
        Identifier: 0x5e
        Timestamp:  37600
        Subpixel:   unknown
        Clones:    
        CRTC:       0
        CRTCs:      0 1
        BOTTOM: 37 (0x00000025) range:  (0,100)
        RIGHT: 46 (0x0000002e) range:  (0,100)
        TOP: 36 (0x00000024) range:  (0,100)
        LEFT: 54 (0x00000036) range:  (0,100)
        TV_FORMAT: PAL
                supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
                           PAL-N        PAL         
  1024x768 (0x72)   22.4MHz
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   20.0KHz
        v: height  768 start  769 end  800 total  801           clock   25.0Hz
  800x600 (0x73)   14.2MHz
        h: width   800 start  801 end  864 total  896 skew    0 clock   15.8KHz
        v: height  600 start  601 end  632 total  633           clock   25.0Hz
  848x480 (0x74)   12.1MHz
        h: width   848 start  849 end  912 total  944 skew    0 clock   12.8KHz
        v: height  480 start  481 end  512 total  513           clock   25.0Hz
  640x480 (0x75)    9.4MHz
        h: width   640 start  641 end  704 total  736 skew    0 clock   12.8KHz
        v: height  480 start  481 end  512 total  513           clock   25.0Hz
Comment 9 Gordon Jin 2008-05-02 06:19:06 UTC
William says: "it could be a problem related to the ACPI of my laptop (if it can be connected in somehow)"

Can you elaborate why you suspect it may be ACPI issue? Thanks.
Comment 10 William Grzybowski 2008-05-02 09:57:45 UTC
Well,
since it works fine in Windows, doesn't on Linux/Freebsd and a some people got it working I suppose it has to be something wrong with my laptop...
In linux, i get some errors about ACPI:

PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
system 00:01: iomem range 0xe0000000-0xefffffff could not be reserved
system 00:01: iomem range 0xfed14000-0xfed17fff could not be reserved
system 00:01: iomem range 0xfed18000-0xfed18fff could not be reserved
system 00:01: iomem range 0xfed19000-0xfed19fff could not be reserved
system 00:01: iomem range 0xfed1c000-0xfed1ffff could not be reserved
system 00:01: iomem range 0xfed20000-0xfed3ffff could not be reserved
system 00:01: iomem range 0xfed40000-0xfed44fff could not be reserved
system 00:01: iomem range 0xfed45000-0xfed8ffff could not be reserved
system 00:03: iomem range 0xfed00000-0xfed003ff could not be reserved

I don't really know if it can affect something in the video driver output, but that is it...
Comment 11 Gordon Jin 2008-05-03 18:37:39 UTC
To further investigate the ACPI issue, could you attach the full dmesg output and acpidump? Thanks.
Comment 12 William Grzybowski 2008-05-03 18:49:31 UTC
Created attachment 16338 [details]
dmesg (kernel 2.6.24)
Comment 13 William Grzybowski 2008-05-03 18:52:50 UTC
Created attachment 16340 [details]
acpidump

I generated this acpidump from freebsd 8-current, but since it retrieve the AML from BIOS, i dont think it's a problem...

let me know if there is more anything I can do.
Comment 14 ykzhao 2008-05-03 20:09:53 UTC
Hi, William
   The warning message in comment #10 is harmless and won't break anything.
   >PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.0
   >PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.0
   >PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.0
   >PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.1
   >PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.1
   >PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.1
   >PCI: Cannot allocate resource region 7 of bridge 0000:00:1c.2
   >PCI: Cannot allocate resource region 8 of bridge 0000:00:1c.2
   >PCI: Cannot allocate resource region 9 of bridge 0000:00:1c.2
  
   In fact there are some bugs about the warning message in kernel bugzilla.
For example: http://bugzilla.kernel.org/show_bug.cgi?id=6539. 
   
   The remaing problem on this laptop is that TV S-Video output stays in gray scale.
   Thanks.
Comment 15 Michael Fu 2008-07-03 19:57:03 UTC
zhenyu, we now have a similar configuration now -945GM with S-video output. Pls contact Gordon to get access to this HW. Let's see if we can reproduce this bug or not...
Comment 16 Gordon Jin 2008-07-10 20:15:49 UTC
Haien, please test s-video on our new 945gm.
Comment 17 liuhaien 2008-07-13 18:17:52 UTC
(In reply to comment #16)
> Haien, please test s-video on our new 945gm.
> 

this bug cannot reproduce on our new 945gm.I can see the desktop,which is flashing on the screen. 
Comment 18 Michael Fu 2008-07-13 19:49:31 UTC
might be your TV is set on different input? I met similar case on the TV in my home, on a wrong TV input, the image is black-n-white.

Also, please double check the gamma setting.
Comment 19 liuhaien 2008-07-13 22:32:53 UTC
(In reply to comment #18)
> might be your TV is set on different input? I met similar case on the TV in my
> home, on a wrong TV input, the image is black-n-white.
> 
> Also, please double check the gamma setting.
> 

I have setted the TV input on S-VIDEO,and the output of xgamma is that:
[root@x-lf ~]# xgamma
-> Red  1.500, Green  1.500, Blue  1.500

Is there any problem?
Comment 20 William Grzybowski 2008-07-15 07:32:16 UTC
Hi.

I'm starting to get scared, is it possible that I am doing something wrong? Since you guys can't reproduce it...

Let me try to attach some additional info.

My TV has support for NTSC and PAL-M (I can switch it using the tv menu control).
Under Windows it works fine if I use it setting NTSC (tv) - NTSC(soft) or PAL-M(soft) - PAL-M(soft).

Under Linux or Freebsd (with the same cable and tv configs, of course) doesn't matter if I try to use it with NTSC (tv) - NTSC(soft) or PAL-M(soft) - PAL-M(soft) (I do switch the software tv format using randr --output TV --set TV_FORMAT NTSC and randr --output TV --set TV_FORMAT PAL-M)

So I suppose it can't be directly related to the output format right?

Am I missing something?

If there is any patch which I can attach and recompile the driver even if it is just for debug information let me know.

Thanks!
Comment 21 Michael Fu 2008-07-17 02:35:32 UTC
william, what's your gamma setting? see comment# 19 on how to get the value.  thanks.
Comment 22 William Grzybowski 2008-07-17 14:50:31 UTC
Hi,

% xgamma 
-> Red  1.000, Green  1.000, Blue  1.000

Already tried to change it, just gets screen whiter or blacker...
Comment 23 Gordon Jin 2008-07-17 20:36:26 UTC
Michael, our machine turns out to be 945g with _SDVO_ TV-out, not 945gm.
Comment 24 Wang Zhenyu 2008-07-27 22:24:26 UTC
Please try lastest 2.4.0 driver or git master, and attach X log with ModeDebug option on. 

What's type of TV link you use? Just SVideo-to-SVideo line? any other converter?
Comment 25 William Grzybowski 2008-07-28 12:14:00 UTC
Created attachment 17937 [details]
Xorg log with ModeDebug enabled
Comment 26 William Grzybowski 2008-07-28 12:19:48 UTC
I just compiled the latest code from git, nothing changes.
I've attached the xorg log with modedebug enabled, hope it helps something (I started X without the cable and then I used `xrandr --auto` (I did change the tv_format also).

It's a svideo-to-svideo link (4 pins) without any kind of converters.

Right now I am using a fedora core 9 with testing repositories...
X.Org X Server 1.4.99.906 (1.5.0 RC 6)
Release Date: 
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.18-92.1.6.el5xen i686 
Current Operating System: Linux venon.lost.garden 2.6.25.11-97.fc9.i686 #1 SMP Mon Jul 21 01:31:09 EDT 2008 i686
Build Date: 24 July 2008  10:49:30AM
Build ID: xorg-x11-server 1.4.99.906-1.fc9 
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Module Loader present
Comment 27 Michael Fu 2008-07-28 19:02:59 UTC
btw, william, would you please tell us the specific model of your laptop? thanks.
Comment 28 William Grzybowski 2008-07-29 03:55:29 UTC
It's an Acer Aspire 5570 2607
I'm attaching the lspci -v
Is there something more specific which you want to know?
Comment 29 William Grzybowski 2008-07-29 03:56:06 UTC
Created attachment 17956 [details]
lspci -v
Comment 30 Sebastian Keller 2008-09-11 20:29:18 UTC
I have probably the same problem but with a 915GM. However older versions of the driver worked for me. For example the ones from Ubuntu Hardy. Perhaps you could try a live cd of that and see if those work for you too.
I filed a launchpad bug a few days after it stopped working in Ubuntu Intrepid, which you can find here:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/246802
But it doesn't contain much information which isn't already here.

This machine is a IBM Thinkpad R52 1858 69G
Comment 31 Sebastian Keller 2008-09-11 20:31:21 UTC
Created attachment 18835 [details]
"lspci -v" on the 915GM laptop
Comment 32 Wang Zhenyu 2008-11-05 19:27:06 UTC
Please test against current xf86-video-intel git master.
Comment 33 William Grzybowski 2008-11-06 12:04:42 UTC
Hi.

Against today current master i cannot get my TV working anymore, not even in grayscale...
The TV just stays in a black screen, i can set the resolution, rate and TV_FORMAT but nothing shows up....

I am attaching my Xorg.0.log , tell me if you need it with ModeDebug On or something else...
My kernel is 2.6.27.4-68.fc10.i686 , Fedora Rawhide...
X.Org X Server 1.5.2

TV connected 1024x768+0+0 (0x42) normal (normal left inverted right x axis y axi
s) 0mm x 0mm
        Identifier: 0x3d
        Timestamp:  37672691
        Subpixel:   unknown
        Clones:    
        CRTC:       0
        CRTCs:      0 1
        BOTTOM: 37 (0x00000025) range:  (0,100)
        RIGHT: 46 (0x0000002e) range:  (0,100)
        TOP: 36 (0x00000024) range:  (0,100)
        LEFT: 54 (0x00000036) range:  (0,100)
        TV_FORMAT: NTSC-M
                supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
                           PAL-N        PAL         
  1024x768 (0x42)   26.9MHz *current
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   24.0KHz
        v: height  768 start  769 end  800 total  801           clock   30.0Hz
  800x600 (0x43)   17.0MHz
        h: width   800 start  801 end  864 total  896 skew    0 clock   19.0KHz
        v: height  600 start  601 end  632 total  633           clock   30.0Hz
  848x480 (0x44)   14.5MHz
        h: width   848 start  849 end  912 total  944 skew    0 clock   15.4KHz
        v: height  480 start  481 end  512 total  513           clock   30.0Hz
  640x480 (0x45)   11.3MHz
        h: width   640 start  641 end  704 total  736 skew    0 clock   15.4KHz
        v: height  480 start  481 end  512 total  513           clock   30.0Hz
Comment 34 William Grzybowski 2008-11-06 12:06:00 UTC
Created attachment 20117 [details]
xorg log from git driver version of 2008-11-06
Comment 35 Wang Zhenyu 2008-11-06 17:00:00 UTC
Could you try with git bisect to see which commit caused this? A starting point might be the first recent TV patch.
Comment 36 Wang Zhenyu 2008-11-06 17:02:31 UTC
(EE) intel(0): underrun on pipe B!

This might be the cause, does it happen everytime?
Comment 37 William Grzybowski 2008-11-07 02:04:48 UTC
(In reply to comment #36)
> (EE) intel(0): underrun on pipe B!
> 
> This might be the cause, does it happen everytime?
> 


Yes, it already was happening before, i just don't know if it happens every single time or just when i try to set some TV_FORMAT or modes.
I'll check it this afternoon and which commit caused this regression.

Thank you,
Comment 38 William Grzybowski 2008-11-07 10:02:05 UTC
Hi,

I used git bisect to track down which commit caused the last regression...

2ae91f0ffdadfb393d526b94e21914a31aa14232 is first bad commit
commit 2ae91f0ffdadfb393d526b94e21914a31aa14232
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Wed Oct 29 20:26:44 2008 +0800

    TV: fix default contrast and saturation modifier
    
    Color knobs was set with higher modifier which caused strong color
    on TV screen. Setting fixed point modifier to default 1.0 makes picture
    on TV look nicer.

:040000 040000 9aa6d3a12ed3907cab0549f9ace675618e212409 231e26c8f08fb5a4338e4c932dd5638291c1f381 M      src

and the git bissect log
# git bisect log     
git bisect start
# bad: [a5b1e62337d4e8840347bb186db48697f0690a19] quirk LVDS on Asus Eee box
git bisect bad a5b1e62337d4e8840347bb186db48697f0690a19
# good: [c4cab00ef7f57fc27776f53263aacec2edf6f959] TV: white space cleanup
git bisect good c4cab00ef7f57fc27776f53263aacec2edf6f959
# bad: [3651341292d90b7ded4c3f013bcb0f46537a113a] TV: fix timing parameters for PAL, 480p, 1080i
git bisect bad 3651341292d90b7ded4c3f013bcb0f46537a113a
# bad: [b404afb755b608b02bcf0be1f8fe8a38d3d7bc1e] TV: save serveral TV_CTL register fields in mode set
git bisect bad b404afb755b608b02bcf0be1f8fe8a38d3d7bc1e
# bad: [2ae91f0ffdadfb393d526b94e21914a31aa14232] TV: fix default contrast and saturation modifier
git bisect bad 2ae91f0ffdadfb393d526b94e21914a31aa14232
Comment 39 Wang Zhenyu 2008-11-09 18:03:58 UTC
What TV format do you use? Could you check what's the result of revert that patch? It's "TV can show up now" or "TV show color correctly then". (I doubt it might not be the root cause of your origin gray TV issue...)
Comment 40 William Grzybowski 2008-11-10 02:09:28 UTC
Hi Wang Zhenyu,

I have great news!

My TV can accept NTSC or PAL-M, i was trying both...

By revert you mean try the HEAD without the "TV: fix default contrast and saturation modifier" commit, right?

So i moved to current and get back to 
OUTREG(TV_CLR_KNOBS, 0x00606000);
where it was
OUTREG(TV_CLR_KNOBS, 0x00404000);

And yes, it is working now, and better than just works, it's a hundred percent!
Working fine with a pretty nice colored screen!

I don't know which commit made the trick (couldn't be that one with OUTRED) but i can find out if you want.

Thank you a lot for you and all team of intel, i am so happy :)
bug solved!
Comment 41 Wang Zhenyu 2008-11-10 17:57:29 UTC
I have fixed color knobs regression with my recent TV changes, patch is on master now. Could you verify that? Thanks for testing!
Comment 42 William Grzybowski 2008-11-11 01:57:22 UTC
Sure, just did it.

Working fine with current git!

Thank you!
Comment 43 Wang Zhenyu 2008-11-11 17:46:40 UTC
Fixed with
commit 65cd0fbb018b2c18f1571dc0924c7d92eaf794ad
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Tue Nov 11 09:36:50 2008 +0800

    TV: fix contrast and saturation for 915/945G
    
    915/945G uses exponent-mantissa format instead of
    fixed-point format on 965G.

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.