Bug 20610

Created attachment 23767 [details]
dmesg

Created attachment 23768 [details]
lspci -vvnn

Created attachment 23769 [details]
xorg.conf

Created attachment 23770 [details]
xrandr --verbose

Is this a regression (ever worked with older driver)?

Could you get gdb trace in X crash? Have you tried with TV_Connector option? see intel man.

@gordon

I do not know. I had forgotten the adapter connected. I have had a working xorg.conf after *alot* of fiddeling around, mostly becouse the configuration of the TV depended in strange ways on the configuration of TMDS. However I lost my xorg.conf, and while trying to find a config that works I removed the adapter and found this behaviour and felt it was time to report.

@wang

TV_Connector does not seem to change anything in the behaviour.

Trying to reproduce the crash (which seems to be a SIGABRT) it seems I was wrong about when xrandr crashes X. X seems to always survive the first time xrandr is run, and crash right after the next.
I will attach bt full from crashed X.

Created attachment 23789 [details]
backtrace

I had som free time and decided to look a bit deeper into this.

I use a S-Video -> Composite connector (which identifies itself as a "S-Video connector) since my TV does not support S-Video.
On the TV a use a SCART-connector that has plugs for S-Video, Composite and audio. Using anything S-Video results in a b/w-picture.

I tweaked i830_tv.c somewhat to get more info about tv_dac. One dump right after TV_DAC has been imported into tv_dac, then one right after the "Destructive detection" (also telling me if that codepath was chosen), and one dump at the end of the message about what connection type was found.

Connecting only with the S-Video cable the intel driver runs the "Destructive detection", gets a TV_DAC at the value of 0xcf0000aa, identifies a S-Video cable and TV_DAC then is 0x50000000 when I run xrandr, and no more "Destructive detection". A b/w-picture all the time (except flicker during xrandr detection).

This looked like this grepped in the log (the values with 0x are the ones from REGDUMP, while the ones without are the ones I added):

grep TV_DAC /var/log/Xorg.0.log
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0): Firstly first, TV_DAC: 70000000
(II) intel(0): After destructive detect, TV_DAC: cf0000aa
(II) intel(0): Detected S-Video TV connection,TV_DAC: cf0000aa
(II) intel(0):               TV_DAC: 0x50000000
(II) intel(0): Firstly first, TV_DAC: 50000000
(II) intel(0): Detected S-Video TV connection,TV_DAC: 50000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0):               TV_DAC: 0x50000000
(II) intel(0): Firstly first, TV_DAC: 50000000
(II) intel(0): Detected S-Video TV connection,TV_DAC: 50000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0):               TV_DAC: 0x50000000
(II) intel(0): Firstly first, TV_DAC: 50000000
(II) intel(0): Detected S-Video TV connection,TV_DAC: 50000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0):               TV_DAC: 0x50000000
(II) intel(0): Firstly first, TV_DAC: 50000000
(II) intel(0): Detected S-Video TV connection,TV_DAC: 50000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0):               TV_DAC: 0x50000000

However if I use the "S-Video -> Composite" adapter the driver first detects 0xcf0000aa during the destructive detection, and therefore detects a S-Video cable. However the next time the value it gets is 0x70000000 and that is detected as nothing (the picture goes away). Same thing next time, and X dies in a SIGABRT almost instantly afterwards.

Grepping the log it looks like this:

grep TV_DAC /var/log/Xorg.0.log
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0): Firstly first, TV_DAC: 70000000
(II) intel(0): After destructive detect, TV_DAC: cf0000aa
(II) intel(0): Detected S-Video TV connection,TV_DAC: cf0000aa
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0): Firstly first, TV_DAC: 70000000
(II) intel(0): No TV connection detected, TV_DAC: 70000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0):               TV_DAC: 0x70000000
(II) intel(0): Firstly first, TV_DAC: 70000000
(II) intel(0): No TV connection detected, TV_DAC: 70000000
(II) intel(0):               TV_DAC: 0x70000000


One test-running the second time I ran xrandr the driver tried with the destructive detection, found a S-Video again, but X still SIGABRT after.

Having no screen connected to the computer it fails to find a screen the first time (TV_DAC: 0x7f0000aa) so it seems like with the adapter the driver finds something during the destructive detect but it fails to remain "detected".

Changed the source to always run the destructive detection.
'xrandr --verbose' works many, many times. But trying anything with 'xrandr --output TV' kills X with an assertion during RRModeInit. So the SIGABRT seems to be becouse of missing screens or something like that.

TV detect is hard. I might just let TV_Connector option to also force TV enable, then you may force it to be S-video as always.

Yeah, I can understand that and I must say I was somewhat surprised that I did not find an option about forceing it already.
That is how I have to do it with my girlfrinds laptop to make those cables/adapters work (it is a ATI-chip running windows).

I also have a 9-pin mini-din that has RGB and Composite out were Composite is working perfectly (detected as Composite and everything) on her laptop, but shows nothing on the media-center (TV_DAC does not even change). Is there diffrent wiring on the 9-pin mini-din for diffrent manufactures (i.e. ATI, Intel) for the mini-din, is it not supported by the chipset or is that just something that my computer-manufacturer (Fujitsu-Siemens branded AOpen motherboard) has not wired up in the S-Video/9-plug mini-din connector?

(In reply to comment #11)
> TV detect is hard. I might just let TV_Connector option to also force TV
> enable, then you may force it to be S-video as always.
> 

zhenyu, make TV_Connector an xrandr option will make user's life easier...

(In reply to comment #12)
> Yeah, I can understand that and I must say I was somewhat surprised that I did
> not find an option about forceing it already.
> That is how I have to do it with my girlfrinds laptop to make those
> cables/adapters work (it is a ATI-chip running windows).
> 
> I also have a 9-pin mini-din that has RGB and Composite out were Composite is
> working perfectly (detected as Composite and everything) on her laptop, but
> shows nothing on the media-center (TV_DAC does not even change). Is there
> diffrent wiring on the 9-pin mini-din for diffrent manufactures (i.e. ATI,
> Intel) for the mini-din, is it not supported by the chipset or is that just
> something that my computer-manufacturer (Fujitsu-Siemens branded AOpen
> motherboard) has not wired up in the S-Video/9-plug mini-din connector?
> 

wikipedia "svideo".. yeah, min-din connector varies per vendor...this indeed brings difficulty for detection.

(In reply to comment #14)
>wikipedia "svideo".. yeah, min-din connector varies per vendor...this indeed
>brings difficulty for detection.

Browsed around wikipedia, and seems to forgotten look at the right article...
For Intel, is this the intel-chipset or is it the maker of the board that decides on what and where in the mini-din you find the signal? And is there any other way to find out then playing with a oscilloscope in the contact (for example if I want to try to build my own composite-out for my board)?

Started to realize that I have started to stray away from topic.

I think someway of forcing output and also being able to do it trough xrandr (to be able to on laptops enable and disable "evil" connectors without having to edit xorg.conf and restart X) would be a good idea.
That way it is possible to move forward with other bugs and leave the auto-detection for rainy days...

One thing I cannot get my head around is why even when I have TV_Connector and the logs says it forces that output it still try to detect the output? It seems to be what fails whit xrandr, since xrandr seems to care about what the probing gives, and not what I try to force upon it.
Would it not be better to just have a logic like 

if TV_Connector, then 
{MSG"This connector is forced"
force-connector-type}
else
{detect-connector-typ}

and be done with it?
Why probe for something if I have told the system it exists?

Sorry for spammiung, but looking at the code I can see that even if I set TV_Connector, there is a logic in i830_tv_detect that if i830_tv_detect_type gives type == TV_TYPE_NONE it returns XF86OutputStatusDisconnected leaving me without a TV even when I force TV_Connector. 
Setting it to always return XF86OutputStatusConnected if dev_priv->force_type makes xrandr work for me.

Created attachment 23889 [details] [review]
force TV connected with TV_Connector option

Could  you test with this patch? Thanks.

(In reply to comment #15)
> (In reply to comment #14)
> >wikipedia "svideo".. yeah, min-din connector varies per vendor...this indeed
> >brings difficulty for detection.
> 
> Browsed around wikipedia, and seems to forgotten look at the right article...
> For Intel, is this the intel-chipset or is it the maker of the board that
> decides on what and where in the mini-din you find the signal? And is there any
> other way to find out then playing with a oscilloscope in the contact (for
> example if I want to try to build my own composite-out for my board)?
> 

yeah, to better resolve this, there indeed need a spec that everyone follows. As you said, board maker could decide which R/G/B DAC is connected to which pin pair in the miniDIN, and accordingly, you would need a miniDIN-to-Component that match what the board requires to work.. Unfortunately, there doesn't seems exist such spec.. and even worse, you can't tell the connection inside of the miniDIN-to-Component, just from its look. Thus if an ordinary user grab a such cable from NV or ATI card and try to use it with Intel board.. it'll become hard to find out..

(In reply to comment #19)
> Created an attachment (id=23889) [details]
> force TV connected with TV_Connector option
> 
> Could  you test with this patch? Thanks.
> 

Works great.
Now when it is moved so the probing does not change type you maybe want to keep the guard so you can force the port off with 'TV_Connector None'.
Have tried that version too, and that worked too.

If you wanna disable TV, randr already has options like "Ignore", "Disable", etc.

(In reply to comment #22)
> If you wanna disable TV, randr already has options like "Ignore", "Disable",
> etc.
> 

Oh, ok. Thanks.

Pushed. Thanks.
commit 4e95327323e3d081b565147f7738eb49c28542bc
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Mon Mar 16 09:30:22 2009 +0800

    TV: force TV as connected with TV_Connector option
    
    In order to bypass failure in TV load detect, TV_Connector option
    will always force TV as connected with user specified connector type.