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)
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
Created attachment 26212 [details] please try the kms tv detection patch on your machine, thanks.
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).
Created attachment 26238 [details] dmesg output
Also, the "[drm] TV-13: set mode NTSC 480i 0" message repeats twice every time I run "xrandr".
It is great! Thanks for your help, which prove we resolved the issue :-) Ma Ling
Hi, Ling How about close this bug if the issue can be fixed by your patch? Thanks.
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
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.
Created attachment 26696 [details] dmesg output booting with 2.6.30
(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..
(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?
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.
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.
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?
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.
The new issue from comment #9 is fixed with this commit: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commitdiff;h=03d6069912babc07a3da20e715dd6a5dc8f0f867;hp=2939e1f5331455d17a4a704dd6210e1474002545
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.