Bug 16236

Created attachment 26817 [details]
print screen + logs (bug marked)

I marked this as a regression.

Kernels with bug 2.6.32, 2.6.33, 2.6.34, 35-rc2 (including standard Ubuntu Lucid
kernel)

Can you attach or paste the output of xrandr --verbose when you see the bug?  It looks like X could be detecting a non-existent output and creating an extended desktop config for you, which would cause this issue.

Created attachment 27228 [details]
xrandr --verbose

Thank you Jesse Barnes, I have added an attachment

Best regards,

Otto Meijer

It's easier if you just attach the text files directly so I don't have to untar and such.

They look ok too, both indicate only LVDS1 is connected and has a mode on it.  The only real difference I see is the default fitting mode, but that should be irrelevant since you're running a native mode.

So it's possible this is an X configuration issue of some kind, have you tried the Xorg edgers repo for Ubuntu?

Thank you again, I tried xorg edgers, either it does not help (more stable drivers) or it locks my computer. (breaks X). I think it could be a kernel issue as kernel 2.6.31.x works fine. 

Kind regards,

Otto Meijer

(In reply to comment #8)
> Thank you again, I tried xorg edgers, either it does not help (more stable
> drivers) or it locks my computer. (breaks X).

Sorry, I am failing to parse that sentence. If it breaks, can you grab the debug information (dmesg, Xorg.0.log and i915_error_state) and upload it here as that may give more clues as to what is happening on your system.

Created attachment 27282 [details]
screenshot of bug scaled x0.5

Dear developers.
I attached again a screen shot. I cannot see gnome-terminal in the left right image. I see the left image only. Is it indeed not possible that X detects a non-existent output (comment 4). Executing xrandr --verbose cures the display. As kernel 2.6.31 works fine, I believed it is a kernel bug.

What can I do to track down the cause of the bug, and help to have it resolved.

Best regards,
Otto Meijer

http://intellinuxgraphics.org/how_to_report_bug.html is the guide on how to gather the information we need.

What appears to be the problem here is that the initial probe is returning an incorrect layout. So we need the debug logs for that, preferably the boot dmesg with drm.debug=0x6 and Xorg.0.log.

Created attachment 27288 [details]
output dmesg

Created attachment 27289 [details]
xorg.0.log

Created attachment 27290 [details]
output of lspci -vv

CHVT 7 - CHVT1 - CHVT7 (Crtl F7, Crtl F1, Crtl F7) introduced the bug now, the attachments of comment 13, 14, 15 were created after this.

Please lat me know if the information is insufficient or if you need further information.

Otto Meijer

Ho hum, another instance of a spurious TV detection:

[   32.064283] [drm:drm_helper_probe_single_connector_modes], SVIDEO-1
[   32.112203] [drm:intel_tv_detect_type], Detected S-Video TV connection
[   32.112221] [drm:drm_helper_probe_single_connector_modes], Probed modes for SVIDEO-1
[   32.112226] [drm:drm_mode_debug_printmodeline], Modeline 45:"848x480" 30 14513 848 849 912 944 480 481 512 513 0x48 0x0
[   32.112234] [drm:drm_mode_debug_printmodeline], Modeline 42:"640x480" 30 11315 640 641 704 736 480 481 512 513 0x48 0x0
[   32.112242] [drm:drm_mode_debug_printmodeline], Modeline 44:"1024x768" 30 26886 1024 1025 1088 1120 768 769 800 801 0x40 0x0
[   32.112250] [drm:drm_mode_debug_printmodeline], Modeline 43:"800x600" 30 16998 800 801 864 896 600 601 632 633 0x40 0x0
[   32.112275] [drm:drm_mode_getconnector], connector id 19:

The Xorg.log doesn't explain why it allocates the framebuffer it does. Something else to fix.

the bug is not fixed with kernel 2.6.35

Created attachment 27455 [details]
patch tested on 2.6.33.7 en 2.6.24.4

Dear developers,

I found this patch. It has never been included in the kernel but fixes the bug. I did not find any side effects. I hope that it can be included in the kernel soon. Please let me know if you need further information or testing.

Kind regards,

otto meijer

Dear developers,

The bug is still not solved with kernel 2.6.27-rc2. How can I help to get this bug fixed?

The patch of commend 21 (tested on 2.6.35 and 2.6.26) fixes the issue. Please let me know if you need further information or testing.


Best regards,

Otto Meijer

2.6.27-rc2 = 2.6.37-rc2

Any news on this bug? Any chance the patch will be merged soon? The bug has been bugging a few people at Arch, too: https://bugs.archlinux.org/task/19234

I reported the same bug here: https://bugs.freedesktop.org//show_bug.cgi?id=27169
2.6.38 and drm-intel-fixes are still bugged.

Dear developers,

Tested with kernels 3.6.35, 3.6.38 rc5

I found a simple workaround without patching the kernel. Odd, but adding "video=SVIDEO-1:d" as boot parameter in grub fixes the issue. Very strange as my laptop computer has no s-video connection.

I hope that the real cause of the bug can be tracked down and fixed.

Best regards,

Otto Meijer

There is already a fix (https://bugs.freedesktop.org//show_bug.cgi?id=27169#c19) but for some reasons Eric Anholt told it was bad.

We've merged quite a few patches to fix up the TV detection logic. Please retest with 3.3 and if this problem still exist, reopen the bug.

3.3 does not solve the problem, please merge the working fix (https://bugs.freedesktop.org//attachment.cgi?id=42814) before 3.4 window closes.

P.S.
I'm sorry but I don't know how to reopen the bug.

Up! Daniel schedule this patch for -next and it should land on 3.5.
After more than two years we will finally put an end to the gm45 nightmare :)

*** This bug has been marked as a duplicate of bug 14792 ***

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit d42c9e2c24f7e7897405b85816bdf4ac924881c0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Mar 25 22:56:14 2012 +0200

    drm/i915: reinstate GM45 TV detection fix