Bug 21204 - [945GM] i915/KMS enables TV although no TV is connected
Summary: [945GM] i915/KMS enables TV although no TV is connected
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: MaLing
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2009-04-15 10:34 UTC by Thomas Bächler
Modified: 2017-07-24 23:10 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
please try the kms tv detection patch on your machine, thanks. (1.30 KB, application/octet-stream)
2009-05-25 18:45 UTC, MaLing
no flags Details
dmesg output (31.13 KB, text/plain)
2009-05-27 01:41 UTC, Thomas Bächler
no flags Details
dmesg output booting with 2.6.30 (31.73 KB, application/octet-stream)
2009-06-11 15:12 UTC, Thomas Bächler
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Bächler 2009-04-15 10:34:06 UTC
This is my system configuration:

Lenovo 3000 N100 FRG (Core 2 Duo CPU, 945GM graphics)
Linux drm-intel-next (+ some PAT fixes)
mesa 7.4
xorg-server 1.6.0
libdrm 2.4.9
xf86-video-intel git master

When I boot, these messages appear in the kernel log:

[drm] TV-13: set mode NTSC 480i 0
allocated 1280x800 fb: 0x007df000, bo ffff8800791920c0
Console: switching to colour frame buffer device 160x50
[drm] LVDS-8: set mode 1280x800 15
fb0: inteldrmfb frame buffer device
registered panic notifier
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[drm] TV-13: set mode 1024x768 1d
[drm] DAC-6: set mode  28

As you can see here, the TV is enabled although nothing is connected to it. When I run xrandr in X, it says

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2048 x 2048
VGA1 disconnected (normal left inverted right x axis y axis)        
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.1*+                                                             
TV1 disconnected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm   
  1024x768 (0x3f)   26.9MHz                                                          
        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    

I cannot enable the VGA until I say "xrandr --output TV1 --off" explicitly, after which xrandr reports:

Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2048 x 2048
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.1*+
TV1 disconnected (normal left inverted right x axis y axis)
Comment 1 Thomas Bächler 2009-05-19 22:30:55 UTC
This is partially fixed. xrandr now shows the TV output as disabled when I start X, however, I still get these in dmesg (several times):

[drm] TV-13: set mode NTSC 480i 0
Comment 2 MaLing 2009-05-25 18:45:08 UTC
Created attachment 26212 [details]
please try the kms tv detection patch on your machine, thanks.
Comment 3 Thomas Bächler 2009-05-27 01:39:04 UTC
I updated to the latest Linus tree (cd86a536c81e9300d984327517548ca0652eebf9) and applied the patch posted above. The situation is unchanged from my last comment. xrandr shows everything correctly:

$ xrandr
Screen 0: minimum 320 x 200, current 1280 x 800, maximum 2048 x 2048
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       60.1*+
TV1 disconnected (normal left inverted right x axis y axis)

The unappropriate messages still appear in dmesg (I am attaching it).
Comment 4 Thomas Bächler 2009-05-27 01:41:00 UTC
Created attachment 26238 [details]
dmesg output
Comment 5 Thomas Bächler 2009-05-27 01:50:58 UTC
Also, the "[drm] TV-13: set mode NTSC 480i 0" message repeats twice every time I run "xrandr".
Comment 6 MaLing 2009-05-30 05:58:08 UTC
It is great! 

Thanks for your help, which prove we resolved the issue :-)

Ma Ling
Comment 7 ykzhao 2009-06-08 20:18:19 UTC
Hi, Ling
    How about close this bug if the issue can be fixed by your patch?
    Thanks.
Comment 8 MaLing 2009-06-08 22:32:38 UTC
the patch has been merged into our latest driver in KMS, so close it now.

commit cb66c692d1ae257f32dc7f6085cf9cb9f2f6bab8
Author: Ma Ling <ling.ma@intel.com>
Date:   Sun May 31 16:58:32 2009 +0800


Thanks
Ma Ling
Comment 9 Thomas Bächler 2009-06-11 15:11:53 UTC
Okay, now I switched from my self-built 2.6.30-rc7-00080-gcc82102 to our brand-new 2.6.30 distribution kernel on Arch Linux. Configuration is of course slightly different, you can find it here: http://repos.archlinux.org/viewvc.cgi/kernel26/trunk/config.x86_64?revision=42144&view=markup

I still enable kms with the modeset=1 module option on i915.ko. I now have a similar bug: althought TV is disabled on X by default, it is enabled on the console:

[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
[drm] TV-13: set mode 1024x768 18
[drm] LVDS-8: set mode 1280x800 15
fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

The result is that I have a 1280x800 framebuffer, but the console only shows on the 1024x768 upper left corner. I am attaching the complete dmesg again.
Comment 10 Thomas Bächler 2009-06-11 15:12:30 UTC
Created attachment 26696 [details]
dmesg output booting with 2.6.30
Comment 11 Michael Fu 2009-06-11 18:11:38 UTC
(In reply to comment #9)
> 
> I still enable kms with the modeset=1 module option on i915.ko. I now have a
> similar bug: althought TV is disabled on X by default, it is enabled on the
> console:
> 

Thomas, do you mean in X everything works fine ( the screen is 1280x800 ), and only happen after you switch to console?

Does your self-built 2.6.30-rc7-00080-gcc82102 have this problem? If not, would you be able to help us do bi-sect? the diff should be small as they are very close..
Comment 12 Michael Fu 2009-06-11 18:29:40 UTC
(In reply to comment #8)
> the patch has been merged into our latest driver in KMS, so close it now.
> 
> commit cb66c692d1ae257f32dc7f6085cf9cb9f2f6bab8
> Author: Ma Ling <ling.ma@intel.com>
> Date:   Sun May 31 16:58:32 2009 +0800
> 
> 
> Thanks
> Ma Ling
> 

ok, looks like .30 doesn't include this patch...Thomas, could you double check?
Comment 13 Thomas Bächler 2009-06-12 00:14:02 UTC
First of all, the bug never manifested in this way before. I will first use my old configuration to build a 2.6.30 kernel (to rule out this is just a problem with Arch's configuration) and then bisect the problem.

The physical resolution is 1280x800 in both X and the console. And X is fine, TV output is disabled there. Only on the console, the problem is that only the upper left 1024x768 rectangle is used to display anything (corresponding to the 1024x768 from the TV output message in dmesg).

Just a tiny problem:

$ git bisect start cd86a536c81e9300d984327517548ca0652eebf9 v2.6.30
Some good revs are not ancestor of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistake good and bad revs?

What do I do in this case? I don't really understand it.
Comment 14 Michael Fu 2009-06-12 00:31:58 UTC
Thomas, if you confirm your self-built 2.6.30-rc7-00080-gcc82102 with the patch in comment# 8 applied works, this bug should marked as closed. We target drm development repository, may have some latency to hit stable kernel.. and we don't want to mix various bugs into on for clear tracking.. :) thanks.
Comment 15 Thomas Bächler 2009-06-12 00:40:22 UTC
Some more random info which only confuses me.

$ pwd
/sys/devices/pci0000:00/0000:00:02.0/graphics/fb0
$ cat mode
$ cat modes
U:1024x768p-0
$ cat virtual_size
1280,800

Shouldn't mode comtain something? Why is there 1024x768 in modes?
Comment 16 Thomas Bächler 2009-06-12 00:44:31 UTC
All my old self-built kernels worked without any extra patches. This problem only appeared when switching to 2.6.30. I can however, try the patch you mentioned on top of it and see what happens.


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.