Bug 14223

William, please attach xorg.conf, Xorg.0.log, and the output of xrandr --verbose.

Created attachment 13902 [details]
Xorg log

Created attachment 13903 [details]
xrandr --verbose

Created attachment 13904 [details]
xorg.conf

Please do not mess around with the 6.9/7.0+ flag.

Sorry, I didn't know that, I tought it was just to tell aobut the Xorg version, my mistake.

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). 

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

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.

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...

To further investigate the ACPI issue, could you attach the full dmesg output and acpidump? Thanks.

Created attachment 16338 [details]
dmesg (kernel 2.6.24)

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.

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.

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...

Haien, please test s-video on our new 945gm.

(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. 

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.

(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?

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!

william, what's your gamma setting? see comment# 19 on how to get the value.  thanks.

Hi,

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

Already tried to change it, just gets screen whiter or blacker...

Michael, our machine turns out to be 945g with _SDVO_ TV-out, not 945gm.

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?

Created attachment 17937 [details]
Xorg log with ModeDebug enabled

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

btw, william, would you please tell us the specific model of your laptop? thanks.

It's an Acer Aspire 5570 2607
I'm attaching the lspci -v
Is there something more specific which you want to know?

Created attachment 17956 [details]
lspci -v

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

Created attachment 18835 [details]
"lspci -v" on the 915GM laptop

Please test against current xf86-video-intel git master.

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

Created attachment 20117 [details]
xorg log from git driver version of 2008-11-06

Could you try with git bisect to see which commit caused this? A starting point might be the first recent TV patch.

(EE) intel(0): underrun on pipe B!

This might be the cause, does it happen everytime?

(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,

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

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...)

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!

I have fixed color knobs regression with my recent TV changes, patch is on master now. Could you verify that? Thanks for testing!

Sure, just did it.

Working fine with current git!

Thank you!

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.