Could you upload attachments one by one, instead of the zip file? Thanks.

Created attachment 18713 [details]
lspci -vvvv output

Created attachment 18714 [details]
My xorg.conf file

Created attachment 18715 [details]
xrandr output after boot

Created attachment 18716 [details]
xrandr output after sleep

Created attachment 18717 [details]
Xorg startup log after boot

Created attachment 18718 [details]
Xorg startup log after sleep

Is the TV the only output you are using? i.e. are you connecting VGA or DVI monitor at the same time?

The xrandr and log shows DVI(TMDS)+TV are detected before sleep while VGA+DVI are detected after sleep.

Are you in X or not starting X yet when you do sleep?

This seems dup with bug#17178

I have TV-out connected only. But Mac Mini actually has only DVI-port and TV-out is an adapter to that DVI port. So in practice there's always DVI and TV-out connected.

Yes, bug#17178 seems to be similar issue, I will try that patch posted there later today.

Forgot to answer to X question. I currently start X manually after boot and before sleep I kill it.

(In reply to comment #11)
> Forgot to answer to X question. I currently start X manually after boot and
> before sleep I kill it.

So how about if sleep in X? 

(In reply to comment #12)
> (In reply to comment #11)
> > Forgot to answer to X question. I currently start X manually after boot and
> > before sleep I kill it.
> 
> So how about if sleep in X? 
> 

I tried that but nothing new, same outputs from xrandr and TV picture is
messed. I compiled now 2.4.2 version of the driver and I also applied the patch
from bug#17178, but nothing changed.

Then I tried my own test hack and changed line from i830_tv.c's
i830_tv_detect_type function so that instead of returning TV_TYPE_NONE; it
returns TV_TYPE_SVIDEO; The behaviour is still the same, but xrandr shows that
TV is connected.

Then, in addition to above hack I modified i830_crt.c's i830_crt_detect_hotplug
to return always false, but still the result is no picture on TV, allthough the
screen is not so messed up anymore, mostly just not showing anything. Now also
the xrandr output after sleep is same than before sleep.

Created attachment 18808 [details]
xrandr output with tv detect hack

Created attachment 18809 [details]
xrandr output with tv and crt detect hacks

Created attachment 18810 [details]
Xorg startup log with both hacks

Actually the less messy screen with the hacks is because output is DVI instead of VGA. Without those detect modifications output after S3 is 800x600@60 from VGA, with those hacks it is 800x600@60 from DVI. I tested this by unplugging the tv out adapter and attaching my monitor when the TV screen was messed up.

I tried latest patch suggestion from bug#17178 but didn't help at least in this case. Xrandr still shows that VGA would be connected after sleep.

I can not reproduce this issue on our gm965(Mini).

Any ideas how this could be solved? I've tried to find some way to force the correct output, but haven't find a solution yet. Even hardcoded-hack would be enough for me at this point as currently my only option is to use TV-out (I'm building a HTPC). And on the other hand I need to have the sleep instead of power-off because as I cannot wakeup the system with remote if the device is powered off.

Still reproducable with 2.5.0 version of the drivers. I also tried Fedora 10 beta live CD, but TV out doesn't seem at all. No picture in the TV even after boot.

Created attachment 20180 [details]
Xorg startup log after boot with 2.5.0 version of driver

Created attachment 20181 [details]
Xorg startup log after sleep with 2.5.0 version of driver

Created attachment 20182 [details]
xrandr output after boot with 2.5.0 version of driver

Created attachment 20183 [details]
xrandr output after boot with 2.5.0 version of driver

Created attachment 20184 [details]
Xorg startup log after boot with yesterday's git version

Created attachment 20185 [details]
Xorg startup log after sleep with yesterday's git version

Created attachment 20186 [details]
xrandr output after boot with yesterday's git version

Created attachment 20187 [details]
xrandr output after sleep with yesterday's git version

I added new log files from Xorg startup and xrandr output with 2.5.0 version of the drivers and yesterdays version from git.

With 2.5.0 the results are the same than before, but with recent git the situation is different. The good part is that ffter the sleep VGA is not anymore detected wrongly as connected (as stated in the bug#17178).
The bad part is that the TV out doesn't work even after the boot although it seems like that in the xrandr output. But in reality my tv screen changes from blue (no signal) to black, but doesn't show anything else. After the sleep TV is detected as disconnected and tv screen stays blue (no signal).

Can you enable ModeDebug option and attach log with current git again? thanks.

Created attachment 20502 [details]
Xorg startup log after boot with 20081122 git version

Created attachment 20503 [details]
Xorg startup log after sleep with 20081122 git version

Created attachment 20504 [details]
xrandr output after boot with 20081122 git version

Created attachment 20505 [details]
xrandr output after sleep with 20081122 git version

Logs with ModeDebug attached. Now the functionality after boot was back to normal, TV out was working ok. But still no valid signal after S3 sleep and TV out is detected as disconnected.

ok, thanks. I think the problem is relate to suspend/resume in drm/i915, that currently no SDVO, TV register got carefully save/restore. I'll make a patch to let you try, but requires building a kernel. 

Could you first try to run suspend within X? not first switch vt or exit X, then suspend?

Kernel build shouldn't be a problem. I'm happy to test any patches that can help in this case.

I've tried to suspend straight from X, it doesn't change the situation. Although I didn't try it with the latest git yet, but I can do that this evening.

I tried the suspend from X, no difference in functionality compared to suspend made from shell.

Any news on this? I've successfully compiled 2.6.28 kernel for my system so I should be able to test any patches provided. Although I've had some problems getting 2.5.99 drivers to compile and work correctly, but I think I can solve those problems. I've also updated my system now to Fedora 10.

I compiled libdrm-2.4.4 and 2.6.0 version of the driver. Functionality is back to the situation that after the sleep VGA seems to be connected. I will attach logs with ModeDebug.

Created attachment 22095 [details]
Xorg startup log after boot with 2.6.0 version of driver

Created attachment 22096 [details]
Xorg startup log after sleep with 2.6.0 version of driver

Created attachment 22097 [details]
xrandr output after boot with 2.6.0 version of driver

Created attachment 22098 [details]
xrandr output after sleep with 2.6.0 version of driver

Could you test my debug patch at bug #11211?

I tried that patch on top of 2.6.0 driver version, didn't help, still same symptoms. I'll add the logs (-debugpatch-).

Last week I also tried your SDVO patches that were posted to mailing list. I got bit different results with them. As you can see from the logs (SDVOpatched-) displays are not detected wrong after the sleep in the sense that X refuses to start because no screens are detected. Then I also added my dirty hack (SDVOpatched-hacked) which just returns always SVIDEO detected. X starts, but doesn't show any picture although xrandr shows the same results than before sleep.

If you compare the lines in SVDOpathced-drv2.6.0-Xorg logs it seems that there is just few lines of differences before and after sleep. I wonder if I could hack those few register values so that the values would be identical to the state after boot. It seems that the registers are SDVOC, DVOC, PORT_HOTPLUG_STAT, PIPESTAT and then the TV_* registers.

Created attachment 22713 [details]
Xorg startup log after boot with 2.6.0 version of driver with debug patch

Created attachment 22714 [details]
Xorg startup log after sleep with 2.6.0 version of driver with debug patch

Created attachment 22715 [details]
xrandr output after boot with 2.6.0 version of driver with debug patch

Created attachment 22716 [details]
xrandr output after sleep with 2.6.0 version of driver with debug patch

Created attachment 22717 [details]
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches

Created attachment 22718 [details]
Xorg startup log after sleep with 2.6.0 version of driver with SVDO patches

Created attachment 22719 [details]
xrandr output after boot with 2.6.0 version of driver with SDVO patches

Created attachment 22720 [details]
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches + TV detect hack

Created attachment 22721 [details]
Xorg startup log after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack

Created attachment 22722 [details]
xrandr output after boot with 2.6.0 version of driver with SDVO patches + TV detect hack

Created attachment 22723 [details]
xrandr output after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack

I just took git versions of libdrm and 2d driver and now the situation is that X won't start at all with DVI output, even right after boot Xorg.log says that no usable configuration found. X does starts with VGA or TV adapter. But after sleep TV adapter causes X not to start.

Hi, Tero, 

would you please kindly have a try with the patch in https://bugs.freedesktop.org/show_bug.cgi?id=22035#c9?

it's a KMS version, but I suggest you to port it your UMS environment to have a try fist... thanks.

Created attachment 26884 [details]
please try the debug patch against latest driver in UMS mode, thanks.

(In reply to comment #60)
> Hi, Tero, 
> would you please kindly have a try with the patch in
> https://bugs.freedesktop.org/show_bug.cgi?id=22035#c9?
> it's a KMS version, but I suggest you to port it your UMS environment to have a
> try fist... thanks.
In order to make easier, I produce the UMS patch, please try it against latest intel driver, then upload log file with modedebug option on.

Thanks
Ma Ling

(In reply to comment #61)
> In order to make easier, I produce the UMS patch, please try it against latest
> intel driver, then upload log file with modedebug option on.

Hi,

Thanks for the patch I will definitely test it and send you the log file. Unfortunately it may take some time as my Mac is another town currently. I hope I can test this in the end of next week, but in worst case it might take 5 weeks. I think that I need to update the system to have the 1.6 version of xserver and 2.6.29 kernel to get the latest driver to work.

(In reply to comment #62)
> (In reply to comment #61)
> > In order to make easier, I produce the UMS patch, please try it against latest
> > intel driver, then upload log file with modedebug option on.
> Hi,
> Thanks for the patch I will definitely test it and send you the log file.
> Unfortunately it may take some time as my Mac is another town currently. I hope
> I can test this in the end of next week, but in worst case it might take 5
> weeks. I think that I need to update the system to have the 1.6 version of
> xserver and 2.6.29 kernel to get the latest driver to work.

ping ~

Ok, I finally got some logs. I did a upgrade from Fedora 10 to Fedora 11 and basically everything broked down, but today I got it somewhat working again.

I took the libdrm 2.4.11 from (http://dri.freedesktop.org/libdrm/libdrm-2.4.11.tar.bz2) and intel driver from git (git://git.freedesktop.org/git/xorg/driver/xf86-video-intel) and applied the patch. With this driver I wasn't able to start xfce4, the whole system just hangs and no picture with any connection (tv, dvi, vga).

But I was able to start twm with startx command using different monitor connectors. (I used the twm also in Fedora 10 when testing). Twm opens the desktop and I'm able to move the mouse, but nothing else works, so I think there's still problems with the system. 

Anyway, the situation still seems to be the same. After the boot TV connection is detected, but after suspend TV is not detected and X won't start as there's no active connections. I will attach the Xorg.log files.

Created attachment 27298 [details]
Xorg startup log after boot with tv_detection.patch

Created attachment 27299 [details]
Xorg startup log after suspend with tv_detection.patch

I forgot to tell that I had to add 'nomodeset' to kernel options in grub to get anything to really work.

(In reply to comment #67)
> I forgot to tell that I had to add 'nomodeset' to kernel options in grub to get
> anything to really work.

hi
I updated  latest xf86-video-intel driver againt drm-intel-next branch.

Yes in UMS TV can't work nomally from S3, although xrandr shows TV connected, TV screen still get black. In KMS mode TV works fine from S3.
The root cause is when comming back from S3, tv need to be re-set based on current mode line. In KMS mode our driver has re-set TV registers in resume function, but In UMS mode we don't know when TV come back from S3, so it is hard to re-set TV registers.

Thanks
Ma Ling

(In reply to comment #68)
> Yes in UMS TV can't work nomally from S3, although xrandr shows TV connected,
> TV screen still get black. In KMS mode TV works fine from S3.
> The root cause is when comming back from S3, tv need to be re-set based on
> current mode line. In KMS mode our driver has re-set TV registers in resume
> function, but In UMS mode we don't know when TV come back from S3, so it is
> hard to re-set TV registers.

So if I can get the KMS mode working the TV should also work fine after coming from S3? If I get the latest driver version, should it work without 'nomodeset' kernel option? Or do I need to compile the driver into kernel to get it work correctly?

Thanks,
Tero

> So if I can get the KMS mode working the TV should also work fine after coming
> from S3?
sure :)
> If I get the latest driver version, should it work without 'nomodeset'
> kernel option? 
yes it may work nomally without nomodeset.

Thanks
Ma Ling

I compiled the libdrm-2.4.12 and 2D driver version 2.8.0. With 'nomodeset' option functionality is the same as before, after S3 no screens are detected and X fails to start at all.

Without the 'nomodeset' option X starts after S3, but TV is detected as disconnected and I get flickering very unstable picture on TV as it seems that the screen is detected as VGA. Also with KMS mode the screen is messy right after the boot also, video picture is just vertical lines, so KMS mode is unusable. I thought that this was because of the XvMC bug (bug#22872) but applying the patch from mailing list didn't help. I will add the logs and my current xorg.conf file so you can check is there something I could try with KMS mode.

Created attachment 27902 [details]
My current xorg.conf file

Created attachment 27903 [details]
Xorg startup log after boot with 2.8.0 version of driver, with nomodeset option

Created attachment 27904 [details]
Xorg startup log after S3 with 2.8.0 version of driver, with nomodeset option

Created attachment 27905 [details]
Xorg startup log after boot with 2.8.0 version of driver

Created attachment 27906 [details]
Xorg startup log after S3 with 2.8.0 version of driver

Created attachment 27907 [details]
xrandr output after boot with 2.8.0 version of driver, with nomodeset option

Created attachment 27908 [details]
xrandr output after boot with 2.8.0 version of driver

Created attachment 27909 [details]
xrandr output after S3 with 2.8.0 version of driver

Have you tested on kernel version v2.6.31-rc2-459-g2a2430f without the 'nomodeset' option ? Because I'm sure the VGA detection has been fixed.

Thanks
ma Ling

(In reply to comment #71)
> I compiled the libdrm-2.4.12 and 2D driver version 2.8.0. With 'nomodeset'
> option functionality is the same as before, after S3 no screens are detected
> and X fails to start at all.
> Without the 'nomodeset' option X starts after S3, but TV is detected as
> disconnected and I get flickering very unstable picture on TV as it seems that
> the screen is detected as VGA. 
Yes as we said in UMS mode our TV can not switch back from S3 normally.

Also with KMS mode the screen is messy right
> after the boot also, video picture is just vertical lines, so KMS mode is
> unusable. 

Could you please update your kernel version against latest drm-intel-next to commit 2a2430f4542467502d39660bfd66b0004fd8d6a9, with 2D driver version 2.8.0 in KMS mode TV should come back from S3.

Thanks
Ma Ling

I updated the kernel to 2.6.31-rc2 snapshot (commit 2a2430f4542467502d39660bfd66b0004fd8d6a9). And I used 2.8.0 driver version with KMS mode. VGA is now detected correctly to be disconnected after S3, but unfortunately so is TV too. DVI is detected as connected so there's no picture in TV still. Logs attached.

Also, I noticed that with this kernel and driver combination the picture after boot is black&white as the Mac Mini would output S-Video signal to composite connector. With the 2.6.29 kernel the picture is colored. One thing I noticed also is that with KMS mode the margin settings doesn't work for TV, but I get error like this:

[root@localhost ~]# xrandr -display :0 -q --verbose --output TV --set RIGHT 15
X Error of failed request:  BadRROutput (invalid Output parameter)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  15 (RRGetOutputProperty)
  Serial number of failed request:  26
  Current serial number in output stream:  26

Should I file another bug for this, or is this know functionality?

Created attachment 28148 [details]
Xorg startup log after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode

Created attachment 28149 [details]
Xorg startup log after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode

Created attachment 28150 [details]
xrandr output after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode

Created attachment 28151 [details]
xrandr output after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode

Created attachment 28152 [details]
My current xorg.conf file

(In reply to comment #82)
> 
> [root@localhost ~]# xrandr -display :0 -q --verbose --output TV --set RIGHT 15
> X Error of failed request:  BadRROutput (invalid Output parameter)
>   Major opcode of failed request:  149 (RANDR)
>   Minor opcode of failed request:  15 (RRGetOutputProperty)
>   Serial number of failed request:  26
>   Current serial number in output stream:  26
> 
> Should I file another bug for this, or is this know functionality?
> 

TV->TV1

(In reply to comment #88)
> (In reply to comment #82)
> > 
> > [root@localhost ~]# xrandr -display :0 -q --verbose --output TV --set RIGHT 15
> > X Error of failed request:  BadRROutput (invalid Output parameter)
> >   Major opcode of failed request:  149 (RANDR)
> >   Minor opcode of failed request:  15 (RRGetOutputProperty)
> >   Serial number of failed request:  26
> >   Current serial number in output stream:  26
> > 
> > Should I file another bug for this, or is this know functionality?
> > 
> 
> TV->TV1
> 

Oh, my bad. But still with TV1 it doesn't work:

[root@localhost ~]# xrandr -display :0 -q --verbose --output TV1 --set RIGHT 15
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  149 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  27
  Current serial number in output stream:  27

(In reply to comment #89)
> 
> [root@localhost ~]# xrandr -display :0 -q --verbose --output TV1 --set RIGHT 15
> X Error of failed request:  BadName (named color or font does not exist)
>   Major opcode of failed request:  149 (RANDR)
>   Minor opcode of failed request:  11 (RRQueryOutputProperty)
>   Serial number of failed request:  27
>   Current serial number in output stream:  27
> 
RIGHT->right margin, use what xrandr list...yeah, I don't like it either...

(In reply to comment #86)
> Created an attachment (id=28151) [details]
> xrandr output after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS
> mode
It seems that the mentioned commit is not shipped in 2.6.31-rc2 kernel.
commit 354ff96772540d2e836194bf14dd9c05c274055c
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Wed Jul 8 14:13:12 2009 +0800

    drm/i915: Restore the KMS modeset for every activated CRTC

Will you please try the latest upstream kernel(2.6.31-rc5/rc6) and see whether TV is detected correctly after S3 in KMS mode? (Please don't add the boot option of "nomodeset".)

Thanks.
> 

(In reply to comment #91)
> Will you please try the latest upstream kernel(2.6.31-rc5/rc6) and see whether
> TV is detected correctly after S3 in KMS mode? (Please don't add the boot
> option of "nomodeset".)

I will try it when I have possibility to do that, might take couple of weeks as I'm again away from the Mac Mini for some time.

I got finally possibility to test later kernel version (2.6.31.5) with 2.9.0 driver package. But nothing changed, still black screen after suspend. And when trying to start X, it reports that no screens found. Worth of noticing is that already the terminal screen is lost after suspend. In other words I can see the terminal output on tv-screen after quitting the X, but when I suspend and then resume the screen is black ie. wrong screen mode. for tv out.

I'll add the logs.

Created attachment 30746 [details]
Xorg startup log after reboot with 2.9.0 version of driver, 2.6.31.5 kernel, KMS mode in use

Created attachment 30747 [details]
Xorg startup log after S3 suspend with 2.9.0 version of driver, 2.6.31.5 kernel, KMS mode in use

I tested yesterday Ubuntu 10.04 and Fedora 13 live CDs and there's no output to tv at all. I haven't yet check what is the driver version in those releases, but anyway I cannot upgrade or I lose the tv output totally.

Ok sounds like this is still a problem, there must be something wrong with the configuration we try to restore at resume time...

Can you grab a dmesg with drm.debug=4 from current bits?

I will try to take the debugs this week with those LiveCDs and from the currently installed system (Fedora 11, X Server 1.6.1.901, 2.6.29.6-213.fc11.i586, 2.9.0 driver). Problem with taking the debugs with LiveCDs is that I think I have to do it blind because if I boot with Tv-out attached to mini I cannot get any picture to tv screen. But with current installation it should success without problems.

Created attachment 37889 [details]
Xorg startup log after boot with 2.9.0 version of driver, drm.debug=4

Created attachment 37890 [details]
Xorg startup log after S3 sleep with 2.9.0 version of driver, drm.debug=4

Attached logs from the currently installed system and drm.debug=4 option. Unfortunately I didn't get the logs with later distributions' Live CD as I had limited time and the problems with tv output. Hopefully yet those logs helps a little.

As I have written above, my Mac Mini is now in use by my parents and is located 200km away from my home, so I cannot access that too often. But I still try to test and report the status about this issue. I'm planning to test Fedora 12 live CD next time I visit so I can see whether the tv out is broken already in that. In Fedora 11 it works, but doesn't work with Fedora 13.

Is it still valid with latest Intel graphics stack by a chance?

I haven't tried for a while. I will download and latest Ubuntu and Fedora Betas soon to find out how it is working now.

I tested with Fedora 15 live and Ubuntu 11.10 Beta. Ubuntu didn't seem to even boot properly when tv-out was connected to mac mini. (Worked fine with vga). Fedora 15 booted, but no picture in tv at all. Seems that tv-out is still detected as vga as the sync was clearly wrong.

Kernel 3.3-rc1 has some tv-out fixes, can you please retest with that?

I finally had a change to test latests live CDs', Ubuntu 12.04 with kernel 3.2.0 didn't boot properly when tv-out connected. Apparently tv-out wasn't detected properly and boot failed at some point (cannot say where without picture), with vga out it booted ok.

I had also Fedora 17 with me, but unfortunately there was some problem with media as I didn't get it to boot at all. I need to test that again with new media, but it will take some time (couple of months) as I don't have the access to Mac Mini anymore so often. I will keep this in needinfo status.

Well, testing 3.2 is too old if we want the test result from a newer kernel ...

I'll close this as obsolete, please reopen if this is still an issue on newer kernels/userspace.

I can confirm that this is still happening for me with the following setup on Debian 7.1:

linux-image-686-pae                       3.10+51~bpo70+1
libdrm-intel1:i386                        2.4.40-1~deb7u2
xserver-xorg-video-intel                  2:2.19.0-6

On first boot of X, I get this:

[    24.108] (II) intel(0): Output VGA1 connected
[    24.108] (II) intel(0): Output DVI1 disconnected
[    24.108] (II) intel(0): Output TV1 connected

chris@bayswater:~$ xrandr -display :0
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 1mm x 257mm
   1024x768       60.0* 
   800x600        60.3     56.2  
   848x480        60.0  
   640x480        59.9  
DVI1 disconnected (normal left inverted right x axis y axis)
TV1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   848x480        59.9 +
   640x480        59.9 +
   1024x768       59.9* 
   800x600        59.9  

After S3 sleep the display becomes distorted and the TV1 output isn't recognized:

chris@bayswater:~$ xrandr -display :0
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 1mm x 257mm
   1024x768       60.0* 
   800x600        60.3     56.2  
   848x480        60.0  
   640x480        59.9  
DVI1 disconnected (normal left inverted right x axis y axis)
TV1 disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1024x768 (0x4b)   53.8MHz
        h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   48.0KHz
        v: height  768 start  769 end  800 total  801           clock   59.9Hz

I can then manually disable VGA1, which makes the TV screen black, but I can't seem to force TV1 back on (including by trying a physical disconnect/connect of the cable).

If I restart X, I see this:

[ 69241.532] (II) intel(0): Output VGA1 connected
[ 69241.532] (II) intel(0): Output DVI1 disconnected
[ 69241.532] (II) intel(0): Output TV1 disconnected

Nothing that I can do except a reboot seems to help.

Created attachment 85260 [details]
zork, no faster way to obsolete tons of attachments

Drop all the xorg log files since this is now a bug against the kernel modesetting driver.

Chris can you please test this on the latest drm-intel-nightly builds (just in case it's been magically fixed). Then boot your kernel with drm.debug=0xe, reproduce the problem and attach the complete dmesg to this bug report. You might need to increase the dmesg buffer with log_buf_len (or just stitch it together from the on-disk logfiles), there's _lots_ of debug output with the drm debugging enabled.

Created attachment 85264 [details]
dmesg of issue with drm-intel-nightly

Using 3.11.0-994.201309050442 kernel from drm-intel-nightly in the Ubuntu kernel mainline PPA. No change in behaviour.

Created attachment 85265 [details]
dmesg of issue with drm-intel-nightly

Corrected the mime type

Created attachment 85268 [details]
dmesg of issue with drm-intel-nightly

log_buf_len=32 hadn't set the ringbuffer to be as big as I thought it should so was missing up to 8ish

Created attachment 85490 [details] [review]
clear sense state

Please test the attached patch.

Created attachment 85498 [details]
dmesg output after supplied patch

Same behaviour with the kernel patch. Attached is the dmesg output

To surmise:

[   22.168161] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:SVIDEO-1]
[   22.168170] [drm:intel_get_load_detect_pipe], [CONNECTOR:9:SVIDEO-1], [ENCODER:10:TV-10]
[   22.176043] [drm:intel_tv_detect_type], TV detected: 400c0007, bf0000aa
[   22.176051] [drm:intel_tv_detect_type], Detected Composite TV connection
[   22.192059] [drm:intel_release_load_detect_pipe], [CONNECTOR:9:SVIDEO-1], [ENCODER:10:TV-10]
[   22.192082] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:SVIDEO-1] probed modes :
[   22.192088] [drm:drm_mode_debug_printmodeline], Modeline 33:"848x480" 60 29027 848 849 912 944 480 481 512 513 0x48 0x0
[   22.192098] [drm:drm_mode_debug_printmodeline], Modeline 30:"640x480" 60 22631 640 641 704 736 480 481 512 513 0x48 0x0
[   22.192106] [drm:drm_mode_debug_printmodeline], Modeline 32:"1024x768" 60 53773 1024 1025 1088 1120 768 769 800 801 0x40 0x0
[   22.192115] [drm:drm_mode_debug_printmodeline], Modeline 31:"800x600" 60 33996 800 801 864 896 600 601 632 633 0x40 0x0
[   22.192130] [drm:drm_mode_getconnector], [CONNECTOR:9:?]

becomes

[  131.372083] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:SVIDEO-1]
[  131.372091] [drm:intel_get_load_detect_pipe], [CONNECTOR:9:SVIDEO-1], [ENCODER:10:TV-10]
[  131.380042] [drm:intel_tv_detect_type], TV detected: 400c0007, 7f0000aa
[  131.380049] [drm:intel_tv_detect_type], Unrecognised TV connection
[  131.388026] [drm:intel_release_load_detect_pipe], [CONNECTOR:9:SVIDEO-1], [ENCODER:10:TV-10]
[  131.388030] [drm:drm_helper_probe_single_connector_modes], [CONNECTOR:9:SVIDEO-1] disconnected

The difference being bits 30 and 31 are inverted between the two results. In particular, bit 31 is whether detection was successful and after resume, it no longer reports true.

Can't see anything specific in the bspec that we don't do. So I wonder if one of the other TV control registers is left in a bizarre state after resume. CAn you please grab intel-gpu-tools (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/) and run intel_reg_dumper.

Please run the reg dumper both before and after resume so that we can compare broken and working state.

Created attachment 85514 [details]
intel_reg_dumper before 1

Created attachment 85515 [details]
intel reg dumper after 1

The only difference is the closed-caption control register - that can't be it! But just in case, try doing "intel_reg_write 0x68090 0x00870014" after resume and seeing if the TV is magically redetected on the next xrandr.

No such luck. :-)

It does look like there are a few other differences though (ESR, PORT_HOTPLUG_STAT, DLINE_COMPARE_STATUS, PIPEASTAT, TV_DAC, FENCE 0, FENCE 9, FENCE END 0). Any clues there?

(In reply to comment #121)
> No such luck. :-)
> 
> It does look like there are a few other differences though (ESR,
> PORT_HOTPLUG_STAT, DLINE_COMPARE_STATUS, PIPEASTAT, TV_DAC, FENCE 0, FENCE
> 9, FENCE END 0). Any clues there?

Other differences are either unrelated or in the case of PORT_HOTPLUG_STAT (just a status register) confirm that TV detection doesn't work.

Created attachment 85538 [details] [review]
another shot in the dark

Please test.

Created attachment 85562 [details]
intel_reg_dumper and dmesg before and after pm-suspend, using the latest hack

No change :/

Time to try a brand new kernel.

I think we have to be honest here and admit that it's very unlikely we'll ever fix this. Apparently the firmware does something on boot that we somehow rely on, but it doesn't work later on.

Best change for getting this resolved might be to boot with modesetting disabled with the vesa driver and see whether that works. If so, single step through it. But that's not really something we can do over here.