Bug 38934 - Resolution off by one (1920x1199) with digital output (HDMI, SDVO-B), but correct in VGA [GM965/GL960/G35]
Summary: Resolution off by one (1920x1199) with digital output (HDMI, SDVO-B), but cor...
Status: RESOLVED DUPLICATE of bug 30888
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.6 (2010.12)
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-03 11:40 UTC by Tobias Hain
Modified: 2012-02-04 04:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Tobias Hain 2011-07-03 11:40:47 UTC 
Regression. Affects Ubuntu 11.04.

X.Org X Server 1.10.1
xf86-video-intel 2.14.0
libdrm-2.4.23
kernel 2.6.38
(All from corresponding Ubuntu packages)

This bug is present in the current intel kernel drm modules (2.6.38.4) and has
already been bisected to a particular commit last summer:

        81a14b46846fea0741902e8d8dfcc6c6c78154c8
        drm/i915/sdvo: Set sync polarity based on actual mode

http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg09038.html

Bug shows up, when connecting a DVI screen to a mainboard/notebook with HDMI
output. May not show up when connecting a HDMI device to HDMI output.

Tested on same platform as in first posting of bug 15370.. Actually only tested
Ubuntu 11.04 kernel 2.6.38-8-generic which is rebased to vanilla 2.6.38.2. And
regarding intel i915 drm module and

drivers / gpu / drm / i915 / intel_sdvo.c

is the same as 2.6.38.4. Also ickle branch doesn't see to contain fixes for
this issue.

However this bug seems to be specific to some last generation chipsets.

I tested the exact same display as in first posting (HP w2408 with DVI input)
on a current Sandy Bridge Notebook (MSI A6400-Ci507S with HDMI connector) with
Kubuntu 11.04. And the bug does NOT show up.

That's interesting since the KMS drm driver is the same:
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

Maybe the code path for HDMI output is different in more recent chipsets.

It's a regression of bug 15370. Confirmations by other users can be found over there.
Comment 1 Tobias Hain 2011-07-03 11:41:56 UTC 
Known and working walkaround:

#!/bin/sh
xrandr --newmode 1920x1201my 154 1920 1968 2000 2080 1201 1204 1210 1235
xrandr --addmode HDMI1 1920x1201my
xrandr --output HDMI1 --mode 1920x1201my

will result in real 1920x1200 output.
Comment 2 Chris Wilson 2011-07-03 11:45:32 UTC 
Can you at least try alternating the sync polarity?
Comment 3 Tobias Hain 2011-07-03 13:31:41 UTC 
The modeline that is probed in Xorg.0.log is:

(II) intel(0): Modeline "1920x1200"x60.0  154.00  1920 1968 2000 2080  1200 1203 1209 1235 +hsync -vsync (74.0 kHz)

I created four modelines with all combinations of sync polarity:

-hsync -vsync
-hsync +vsync
+hsync -vsync
+hsync +vsync

And interestingly those with +vsync fix the bug, while those with -vsync send 1 pixel less in vertical resolution over the wire than in the modeline specified.

That means a better/alternative walkaround for this bug is:

#!/bin/sh
xrandr --newmode 1920x1200fix 154 1920 1968 2000 2080 1200 1203 1209 1235 +hsync +vsync
xrandr --addmode HDMI1 1920x1200fix
xrandr --output HDMI1 --mode 1920x1200fix

I hope that helps finding the buggy code path.
Comment 4 Chris Wilson 2011-07-06 00:20:46 UTC 
As far as I can tell, having read the code against the spec for the umpteenth time, is that the code is interpreting the EDID and setting the appropriate bits in the SDVO controller register appropriately.

You can verify this for yourself by intel_reg_read 0x61140 and checking against the documentation at intellinuxgraphics.org (bits 3 and 4 are H/V sync).

The conclusion is therefore one of the specs, hardware or the EDID is incorrect.
Comment 5 Chris Wilson 2011-07-06 11:08:44 UTC 

*** This bug has been marked as a duplicate of bug 30888 ***
Comment 6 Tobias Hain 2012-02-04 04:24:59 UTC 
I can confirm that

drm/i915/sdvo: always set positive sync polarity
commit ba68e086223a5f149f37bf8692c8cdbf1b0ba3ef

http://lists.freedesktop.org/archives/intel-gfx/2012-January/014257.html

fixes this bug. And indeed this fix is a revert of the commit mentioned in this bugreport first comment.

This fix so far has made it into the following upstream mainline kernels:

kernel 3.0.19
kernel 3.3-rc2

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.