Bug 17342

Summary: [945GM MacMini] TV out not detected after sleep (S3)
Product: DRI Reporter: Tero Siironen <izero79>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED WONTFIX QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: low CC: ben, chris, christopher, daniel, izero79, jbarnes, michael.fu
Version: unspecifiedKeywords: NEEDINFO
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
X.org logs, xrandr output, xorg.conf and pspci -vvvv output
none
lspci -vvvv output
none
My xorg.conf file
none
xrandr output after boot
none
xrandr output after sleep
none
Xorg startup log after boot
none
Xorg startup log after sleep
none
xrandr output with tv detect hack
none
xrandr output with tv and crt detect hacks
none
Xorg startup log with both hacks
none
Xorg startup log after boot with 2.5.0 version of driver
none
Xorg startup log after sleep with 2.5.0 version of driver
none
xrandr output after boot with 2.5.0 version of driver
none
xrandr output after boot with 2.5.0 version of driver
none
Xorg startup log after boot with yesterday's git version
none
Xorg startup log after sleep with yesterday's git version
none
xrandr output after boot with yesterday's git version
none
xrandr output after sleep with yesterday's git version
none
Xorg startup log after boot with 20081122 git version
none
Xorg startup log after sleep with 20081122 git version
none
xrandr output after boot with 20081122 git version
none
xrandr output after sleep with 20081122 git version
none
Xorg startup log after boot with 2.6.0 version of driver
none
Xorg startup log after sleep with 2.6.0 version of driver
none
xrandr output after boot with 2.6.0 version of driver
none
xrandr output after sleep with 2.6.0 version of driver
none
Xorg startup log after boot with 2.6.0 version of driver with debug patch
none
Xorg startup log after sleep with 2.6.0 version of driver with debug patch
none
xrandr output after boot with 2.6.0 version of driver with debug patch
none
xrandr output after sleep with 2.6.0 version of driver with debug patch
none
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches
none
Xorg startup log after sleep with 2.6.0 version of driver with SVDO patches
none
xrandr output after boot with 2.6.0 version of driver with SDVO patches
none
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches + TV detect hack
none
Xorg startup log after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack
none
xrandr output after boot with 2.6.0 version of driver with SDVO patches + TV detect hack
none
xrandr output after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack
none
please try the debug patch against latest driver in UMS mode, thanks.
none
Xorg startup log after boot with tv_detection.patch
none
Xorg startup log after suspend with tv_detection.patch
none
My current xorg.conf file
none
Xorg startup log after boot with 2.8.0 version of driver, with nomodeset option
none
Xorg startup log after S3 with 2.8.0 version of driver, with nomodeset option
none
Xorg startup log after boot with 2.8.0 version of driver
none
Xorg startup log after S3 with 2.8.0 version of driver
none
xrandr output after boot with 2.8.0 version of driver, with nomodeset option
none
xrandr output after boot with 2.8.0 version of driver
none
xrandr output after S3 with 2.8.0 version of driver
none
Xorg startup log after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
none
Xorg startup log after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
none
xrandr output after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
none
xrandr output after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
none
My current xorg.conf file
none
Xorg startup log after reboot with 2.9.0 version of driver, 2.6.31.5 kernel, KMS mode in use
none
Xorg startup log after S3 suspend with 2.9.0 version of driver, 2.6.31.5 kernel, KMS mode in use
none
Xorg startup log after boot with 2.9.0 version of driver, drm.debug=4
none
Xorg startup log after S3 sleep with 2.9.0 version of driver, drm.debug=4
none
zork, no faster way to obsolete tons of attachments
none
dmesg of issue with drm-intel-nightly
none
dmesg of issue with drm-intel-nightly
none
dmesg of issue with drm-intel-nightly
none
clear sense state
none
dmesg output after supplied patch
none
intel_reg_dumper before 1
none
intel reg dumper after 1
none
another shot in the dark
none
intel_reg_dumper and dmesg before and after pm-suspend, using the latest hack none

Description Tero Siironen 2008-08-28 12:20:35 UTC
Created attachment 18557 [details]
X.org logs, xrandr output, xorg.conf and pspci -vvvv output

I'm using Fedora 9 on Mac Mini (1,66GHz Core Duo) connected to PAL TV. When I put the system to S3 sleep and wake it up the output is garbage and I have to reboot the system to get the output work again. You can see from the xrandr output that TV out adapter is not detected anymore after the sleep. I've tried pretty much every option with xrandr but I cannot enable TV (and disable VGA). I tried Ubuntu 8.04 LiveCD and it had the same problem.

I also compiled xf86-video-intel 2.4.0 release and tried that but the results are the same.

Attached in the zip-file are X.org logs and xrandr output before and after sleep state and my xorg.conf, and lspci -vvvv output.

I noticed that there's a similar bug for Radeon: #12170
Comment 1 Gordon Jin 2008-09-05 07:17:53 UTC
Could you upload attachments one by one, instead of the zip file? Thanks.
Comment 2 Tero Siironen 2008-09-07 01:05:25 UTC
Created attachment 18713 [details]
lspci -vvvv output
Comment 3 Tero Siironen 2008-09-07 01:07:13 UTC
Created attachment 18714 [details]
My xorg.conf file
Comment 4 Tero Siironen 2008-09-07 01:07:45 UTC
Created attachment 18715 [details]
xrandr output after boot
Comment 5 Tero Siironen 2008-09-07 01:08:07 UTC
Created attachment 18716 [details]
xrandr output after sleep
Comment 6 Tero Siironen 2008-09-07 01:09:04 UTC
Created attachment 18717 [details]
Xorg startup log after boot
Comment 7 Tero Siironen 2008-09-07 01:09:39 UTC
Created attachment 18718 [details]
Xorg startup log after sleep
Comment 8 Gordon Jin 2008-09-09 19:37:52 UTC
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?
Comment 9 Gordon Jin 2008-09-09 19:58:43 UTC
This seems dup with bug#17178
Comment 10 Tero Siironen 2008-09-09 23:37:43 UTC
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.
Comment 11 Tero Siironen 2008-09-09 23:41:35 UTC
Forgot to answer to X question. I currently start X manually after boot and before sleep I kill it.
Comment 12 Gordon Jin 2008-09-09 23:45:27 UTC
(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? 

Comment 13 Tero Siironen 2008-09-10 09:53:57 UTC
(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.
Comment 14 Tero Siironen 2008-09-10 09:58:24 UTC
Created attachment 18808 [details]
xrandr output with tv detect hack
Comment 15 Tero Siironen 2008-09-10 09:59:17 UTC
Created attachment 18809 [details]
xrandr output with tv and crt detect hacks
Comment 16 Tero Siironen 2008-09-10 10:00:00 UTC
Created attachment 18810 [details]
Xorg startup log with both hacks
Comment 17 Tero Siironen 2008-09-11 08:23:39 UTC
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.
Comment 18 Tero Siironen 2008-09-23 08:21:28 UTC
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.
Comment 19 liuhaien 2008-10-09 20:36:59 UTC
I can not reproduce this issue on our gm965(Mini).
Comment 20 Tero Siironen 2008-10-13 08:05:04 UTC
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.
Comment 21 Tero Siironen 2008-11-06 13:09:38 UTC
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.
Comment 22 Tero Siironen 2008-11-10 07:55:14 UTC
Created attachment 20180 [details]
Xorg startup log after boot with 2.5.0 version of driver
Comment 23 Tero Siironen 2008-11-10 07:55:46 UTC
Created attachment 20181 [details]
Xorg startup log after sleep with 2.5.0 version of driver
Comment 24 Tero Siironen 2008-11-10 07:56:47 UTC
Created attachment 20182 [details]
xrandr output after boot with 2.5.0 version of driver
Comment 25 Tero Siironen 2008-11-10 07:57:07 UTC
Created attachment 20183 [details]
xrandr output after boot with 2.5.0 version of driver
Comment 26 Tero Siironen 2008-11-10 07:58:11 UTC
Created attachment 20184 [details]
Xorg startup log after boot with yesterday's git version
Comment 27 Tero Siironen 2008-11-10 07:59:28 UTC
Created attachment 20185 [details]
Xorg startup log after sleep with yesterday's git version
Comment 28 Tero Siironen 2008-11-10 07:59:52 UTC
Created attachment 20186 [details]
xrandr output after boot with yesterday's git version
Comment 29 Tero Siironen 2008-11-10 08:00:25 UTC
Created attachment 20187 [details]
xrandr output after sleep with yesterday's git version
Comment 30 Tero Siironen 2008-11-10 08:07:02 UTC
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).
Comment 31 Wang Zhenyu 2008-11-20 22:56:43 UTC
Can you enable ModeDebug option and attach log with current git again? thanks.
Comment 32 Tero Siironen 2008-11-22 01:38:34 UTC
Created attachment 20502 [details]
Xorg startup log after boot with 20081122 git version
Comment 33 Tero Siironen 2008-11-22 01:39:14 UTC
Created attachment 20503 [details]
Xorg startup log after sleep with 20081122 git version
Comment 34 Tero Siironen 2008-11-22 01:39:48 UTC
Created attachment 20504 [details]
xrandr output after boot with 20081122 git version
Comment 35 Tero Siironen 2008-11-22 01:40:12 UTC
Created attachment 20505 [details]
xrandr output after sleep with 20081122 git version
Comment 36 Tero Siironen 2008-11-22 01:42:39 UTC
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.
Comment 37 Wang Zhenyu 2008-11-23 17:25:20 UTC
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?
Comment 38 Tero Siironen 2008-11-24 00:14:27 UTC
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.
Comment 39 Tero Siironen 2008-11-24 09:59:44 UTC
I tried the suspend from X, no difference in functionality compared to suspend made from shell.
Comment 40 Tero Siironen 2009-01-13 12:15:14 UTC
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.
Comment 41 Tero Siironen 2009-01-19 09:59:32 UTC
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.
Comment 42 Tero Siironen 2009-01-19 10:01:32 UTC
Created attachment 22095 [details]
Xorg startup log after boot with 2.6.0 version of driver
Comment 43 Tero Siironen 2009-01-19 10:02:07 UTC
Created attachment 22096 [details]
Xorg startup log after sleep with 2.6.0 version of driver
Comment 44 Tero Siironen 2009-01-19 10:02:49 UTC
Created attachment 22097 [details]
xrandr output after boot with 2.6.0 version of driver
Comment 45 Tero Siironen 2009-01-19 10:03:50 UTC
Created attachment 22098 [details]
xrandr output after sleep with 2.6.0 version of driver
Comment 46 Wang Zhenyu 2009-02-08 19:09:47 UTC
Could you test my debug patch at bug #11211?
Comment 47 Tero Siironen 2009-02-09 07:03:30 UTC
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.
Comment 48 Tero Siironen 2009-02-09 07:04:34 UTC
Created attachment 22713 [details]
Xorg startup log after boot with 2.6.0 version of driver with debug patch
Comment 49 Tero Siironen 2009-02-09 07:05:00 UTC
Created attachment 22714 [details]
Xorg startup log after sleep with 2.6.0 version of driver with debug patch
Comment 50 Tero Siironen 2009-02-09 07:05:56 UTC
Created attachment 22715 [details]
xrandr output after boot with 2.6.0 version of driver with debug patch
Comment 51 Tero Siironen 2009-02-09 07:06:27 UTC
Created attachment 22716 [details]
xrandr output after sleep with 2.6.0 version of driver with debug patch
Comment 52 Tero Siironen 2009-02-09 07:07:15 UTC
Created attachment 22717 [details]
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches
Comment 53 Tero Siironen 2009-02-09 07:07:37 UTC
Created attachment 22718 [details]
Xorg startup log after sleep with 2.6.0 version of driver with SVDO patches
Comment 54 Tero Siironen 2009-02-09 07:08:13 UTC
Created attachment 22719 [details]
xrandr output after boot with 2.6.0 version of driver with SDVO patches
Comment 55 Tero Siironen 2009-02-09 07:08:58 UTC
Created attachment 22720 [details]
Xorg startup log after boot with 2.6.0 version of driver with SVDO patches + TV detect hack
Comment 56 Tero Siironen 2009-02-09 07:09:26 UTC
Created attachment 22721 [details]
Xorg startup log after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack
Comment 57 Tero Siironen 2009-02-09 07:09:58 UTC
Created attachment 22722 [details]
xrandr output after boot with 2.6.0 version of driver with SDVO patches + TV detect hack
Comment 58 Tero Siironen 2009-02-09 07:10:23 UTC
Created attachment 22723 [details]
xrandr output after sleep with 2.6.0 version of driver with SDVO patches + TV detect hack
Comment 59 Tero Siironen 2009-02-23 11:06:51 UTC
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.
Comment 60 Michael Fu 2009-06-16 22:56:51 UTC
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.
Comment 61 MaLing 2009-06-17 05:57:28 UTC
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
Comment 62 Tero Siironen 2009-06-18 00:09:12 UTC
(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.
Comment 63 MaLing 2009-07-01 04:45:32 UTC
(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 ~
Comment 64 Tero Siironen 2009-07-01 08:19:32 UTC
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.
Comment 65 Tero Siironen 2009-07-01 08:21:55 UTC
Created attachment 27298 [details]
Xorg startup log after boot with tv_detection.patch
Comment 66 Tero Siironen 2009-07-01 08:22:35 UTC
Created attachment 27299 [details]
Xorg startup log after suspend with tv_detection.patch
Comment 67 Tero Siironen 2009-07-01 08:51:34 UTC
I forgot to tell that I had to add 'nomodeset' to kernel options in grub to get anything to really work.
Comment 68 MaLing 2009-07-19 23:55:40 UTC
(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
Comment 69 Tero Siironen 2009-07-20 11:20:33 UTC
(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
Comment 70 MaLing 2009-07-21 05:26:39 UTC
> 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
Comment 71 Tero Siironen 2009-07-22 02:31:49 UTC
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.
Comment 72 Tero Siironen 2009-07-22 02:32:38 UTC
Created attachment 27902 [details]
My current xorg.conf file
Comment 73 Tero Siironen 2009-07-22 02:33:45 UTC
Created attachment 27903 [details]
Xorg startup log after boot with 2.8.0 version of driver, with nomodeset option
Comment 74 Tero Siironen 2009-07-22 02:34:11 UTC
Created attachment 27904 [details]
Xorg startup log after S3 with 2.8.0 version of driver, with nomodeset option
Comment 75 Tero Siironen 2009-07-22 02:34:47 UTC
Created attachment 27905 [details]
Xorg startup log after boot with 2.8.0 version of driver
Comment 76 Tero Siironen 2009-07-22 02:35:10 UTC
Created attachment 27906 [details]
Xorg startup log after S3 with 2.8.0 version of driver
Comment 77 Tero Siironen 2009-07-22 02:36:18 UTC
Created attachment 27907 [details]
xrandr output after boot with 2.8.0 version of driver, with nomodeset option
Comment 78 Tero Siironen 2009-07-22 02:36:45 UTC
Created attachment 27908 [details]
xrandr output after boot with 2.8.0 version of driver
Comment 79 Tero Siironen 2009-07-22 02:37:16 UTC
Created attachment 27909 [details]
xrandr output after S3 with 2.8.0 version of driver
Comment 80 MaLing 2009-07-23 19:20:30 UTC
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
Comment 81 MaLing 2009-07-26 21:28:13 UTC
(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
Comment 82 Tero Siironen 2009-07-29 03:49:52 UTC
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?
Comment 83 Tero Siironen 2009-07-29 03:50:57 UTC
Created attachment 28148 [details]
Xorg startup log after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
Comment 84 Tero Siironen 2009-07-29 03:51:22 UTC
Created attachment 28149 [details]
Xorg startup log after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
Comment 85 Tero Siironen 2009-07-29 03:51:58 UTC
Created attachment 28150 [details]
xrandr output after boot with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
Comment 86 Tero Siironen 2009-07-29 03:52:22 UTC
Created attachment 28151 [details]
xrandr output after S3 with 2.8.0 version of driver, 2.6.31-rc2 kernel, KMS mode
Comment 87 Tero Siironen 2009-07-29 04:03:51 UTC
Created attachment 28152 [details]
My current xorg.conf file
Comment 88 Michael Fu 2009-07-29 05:15:15 UTC
(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
Comment 89 Tero Siironen 2009-07-29 05:34:05 UTC
(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
Comment 90 Michael Fu 2009-07-29 06:06:46 UTC
(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...
Comment 91 ykzhao 2009-08-16 19:29:55 UTC
(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.
> 



Comment 92 Tero Siironen 2009-08-19 07:35:20 UTC
(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.
Comment 93 Tero Siironen 2009-10-27 08:10:18 UTC
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.
Comment 94 Tero Siironen 2009-10-27 08:11:21 UTC
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
Comment 95 Tero Siironen 2009-10-27 08:11:52 UTC
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
Comment 96 Tero Siironen 2010-06-20 11:03:00 UTC
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.
Comment 97 Jesse Barnes 2010-07-15 11:20:38 UTC
Ok sounds like this is still a problem, there must be something wrong with the configuration we try to restore at resume time...
Comment 98 Chris Wilson 2010-07-24 03:38:14 UTC
Can you grab a dmesg with drm.debug=4 from current bits?
Comment 99 Tero Siironen 2010-08-09 03:18:22 UTC
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.
Comment 100 Tero Siironen 2010-08-15 11:44:26 UTC
Created attachment 37889 [details]
Xorg startup log after boot with 2.9.0 version of driver, drm.debug=4
Comment 101 Tero Siironen 2010-08-15 11:44:59 UTC
Created attachment 37890 [details]
Xorg startup log after S3 sleep with 2.9.0 version of driver, drm.debug=4
Comment 102 Tero Siironen 2010-08-15 11:53:14 UTC
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.
Comment 103 Eugeni Dodonov 2011-08-23 12:43:55 UTC
Is it still valid with latest Intel graphics stack by a chance?
Comment 104 Tero Siironen 2011-09-04 05:09:01 UTC
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.
Comment 105 Tero Siironen 2011-09-29 22:34:36 UTC
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.
Comment 106 Daniel Vetter 2012-02-08 10:30:15 UTC
Kernel 3.3-rc1 has some tv-out fixes, can you please retest with that?
Comment 107 Tero Siironen 2012-07-04 08:50:33 UTC
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.
Comment 108 Daniel Vetter 2012-08-22 10:49:31 UTC
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.
Comment 109 Chris Amin 2013-09-05 13:28:07 UTC
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.
Comment 110 Daniel Vetter 2013-09-05 14:40:14 UTC
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.
Comment 111 Chris Amin 2013-09-05 15:31:38 UTC
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.
Comment 112 Chris Amin 2013-09-05 15:33:38 UTC
Created attachment 85265 [details]
dmesg of issue with drm-intel-nightly

Corrected the mime type
Comment 113 Chris Amin 2013-09-05 16:02:46 UTC
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
Comment 114 Daniel Vetter 2013-09-09 08:54:33 UTC
Created attachment 85490 [details] [review]
clear sense state

Please test the attached patch.
Comment 115 Chris Amin 2013-09-09 16:36:39 UTC
Created attachment 85498 [details]
dmesg output after supplied patch

Same behaviour with the kernel patch. Attached is the dmesg output
Comment 116 Chris Wilson 2013-09-09 18:10:20 UTC
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.
Comment 117 Daniel Vetter 2013-09-09 19:14:24 UTC
Please run the reg dumper both before and after resume so that we can compare broken and working state.
Comment 118 Chris Amin 2013-09-09 21:19:14 UTC
Created attachment 85514 [details]
intel_reg_dumper before 1
Comment 119 Chris Amin 2013-09-09 21:19:39 UTC
Created attachment 85515 [details]
intel reg dumper after 1
Comment 120 Chris Wilson 2013-09-09 23:37:44 UTC
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.
Comment 121 Chris Amin 2013-09-10 06:33:08 UTC
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?
Comment 122 Daniel Vetter 2013-09-10 07:56:16 UTC
(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.
Comment 123 Daniel Vetter 2013-09-10 07:56:55 UTC
Created attachment 85538 [details] [review]
another shot in the dark

Please test.
Comment 124 Chris Amin 2013-09-10 12:34:02 UTC
Created attachment 85562 [details]
intel_reg_dumper and dmesg before and after pm-suspend, using the latest hack

No change :/
Comment 125 Jani Nikula 2014-08-26 13:01:14 UTC
Time to try a brand new kernel.
Comment 126 Daniel Vetter 2014-11-04 15:04:35 UTC
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.

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.