[i965] [Hardy] digital output driver (SDVO) sets wrong resolution on GM965

[7oby]

Binary package hint: xserver-xorg-video-intel

The display resolution present on the digital output (DVI, HDMI, SDVO-B) is reduced by 1. E.g. doing

xrandr -s 1920x1200

results in an actual resolution of 1920x1199 sent to the display. This results in stretching of the screen image by the attached display and finally in a blurry display.

. This bug is NOT present if attaching the same display by means of the VGA connector
. This bug is NOT present using other operating systems (= not a bug of the HP w2408 TFT display)
. Any resolution reported by the EDID of the monitor will be reduced by 1: 1600x1199,1024x767, 1280x1023, 800x599, 640x479, ...

lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)

The allocation of the two pipes A/B in the X3100 (GM965) architecture is the same for SDVO-B/TMDS-1 and VGA namely:

(II) intel(0): Output configuration:
(II) intel(0): Pipe A is on
(II) intel(0): Display plane A is now enabled and connected to pipe A.
(II) intel(0): Pipe B is on
(II) intel(0): Display plane B is now enabled and connected to pipe B.
(II) intel(0): Output VGA is connected to pipe none
(II) intel(0): Output LVDS is connected to pipe B
(II) intel(0): Output TMDS-1 is connected to pipe A

Maybe requires reporting upstream.

[Bryce Harrington (bryce)]

This is a Ubuntu bug report I'm forwarding for the reporter:

"Binary package hint: xserver-xorg-video-intel

The display resolution present on the digital output (DVI, HDMI, SDVO-B) is reduced by 1. E.g. doing

xrandr -s 1920x1200

results in an actual resolution of 1920x1199 sent to the display. This results in stretching of the screen image by the attached display and finally in a blurry display.

. This bug is NOT present if attaching the same display by means of the VGA connector
. This bug is NOT present using other operating systems (= not a bug of the HP w2408 TFT display)
. Any resolution reported by the EDID of the monitor will be reduced by 1: 1600x1199,1024x767, 1280x1023, 800x599, 640x479, ...

lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)

The allocation of the two pipes A/B in the X3100 (GM965) architecture is the same for SDVO-B/TMDS-1 and VGA namely:

(II) intel(0): Output configuration:
(II) intel(0): Pipe A is on
(II) intel(0): Display plane A is now enabled and connected to pipe A.
(II) intel(0): Pipe B is on
(II) intel(0): Display plane B is now enabled and connected to pipe B.
(II) intel(0): Output VGA is connected to pipe none
(II) intel(0): Output LVDS is connected to pipe B
(II) intel(0): Output TMDS-1 is connected to pipe A
"

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/212206

xorg.conf: http://launchpadlibrarian.net/13132063/xorg.conf

With Digital (SDVO-B):
Xorg.0.log: http://launchpadlibrarian.net/13131995/Xorg.0.log_SDVOB
xrandr: http://launchpadlibrarian.net/13132023/xrandr.log_sdvob
screenshot: http://launchpadlibrarian.net/13132011/screenshot_dvi_settings.jpg

With VGA:
http://launchpadlibrarian.net/13131999/Xorg.0.log_VGA
http://launchpadlibrarian.net/13132027/xrandr.log_vga

Video Card:
(--) PCI:*(0:2:0) Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 12
(--) PCI: (0:2:1) Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller rev 12
(II) PCI: 00:02:0: chip 8086,2a02 card 1028,0209 rev 0c class 03,00,00 hdr 80
(II) PCI: 00:02:1: chip 8086,2a03 card 1028,0209 rev 0c class 03,80,00 hdr 80

[Bryce Harrington (bryce)]

In comparing the two log files, the things that jump out to me are:

Only in digital mode:
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.

Also, I see that TMDS-1 is disconnected with VGA but connected with digital.

The DPI's are also set to different values on each output.

I'll ask the original reporter to subscribe here.

[Bryce Harrington (bryce)]

Weird, I've never seen a bug like this. Thanks for including ample information for troubleshooting, marking to Triaged.

[Bryce Harrington (bryce)]

In looking at the logs, I notice a few interesting details, but nothing to explain the issue.

This error is only appears in the digital log, and sounds very suspicious (I don't know what it means though):
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.

Also, I see that TMDS-1 is disconnected with VGA but connected with digital; I wouldn't think that would make a difference but it's an interesting data point.

The DPI's are also set to different values on each output - this may be why your display seems fuzzy; perhaps temporarily you can force it by hard-coding your DPI's to 96 or whatever.

There's other differences in warnings for pipe B, drm devices, and so on, but I suspect those are not relevant here.

[Bryce Harrington (bryce)]

7oby, nothing seems obvious to me what's wrong, and you've provided all necessary info that I know of, so I've gone ahead and forwarded the bug upstream. Can you please also subscribe to that bug, in case they wish for more info?

  https://bugs.freedesktop.org/show_bug.cgi?id=15370

One other thing that may be useful would be to test against a newer or older version of the driver, to see if it is either fixed upstream already, or a regression from a past version. Upstream often will ask you to do these tests. I have some Ubuntu debs of newer and older snapshots of the -intel driver from upstream's repository available here if you'd like to go ahead and test them:

  http://people.ubuntu.com/~bryce/bisect/

[7oby (tobias-hain)]

> (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.

This error message is actually also present in other bug reports:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/149430

[Hong-liu (hong-liu)]

Which add2 card are you using? Is it ASUS G35 motherboard?

[7oby (tobias-hain)]

It is a Dell XPS M1330 notebook.

The SDVO chip is the following (probed from Windows driver):

* SDVO Encoder Report *
** Encoder 1 **
Vendor ID: Silicon Image
Device ID: 174
Device Revision: 0
Major Version: 1
Minor Version: 2

The M1330 features three output devices:
. internal LVDS 1280 x 800
. external VGA connector
. external HDMI connector (using the above SDVO encoder)

The error message Bryce mentioned, is also present in other bug reports, which have a dedicated ADD2 PCIe card:
> (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/149430

I also recognized the Dell XPS M1330 has been added to the i830_quirk_list of i830_quirks.c due to "Dell XPS M1330 has no TV out":
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=f3d92ab474de11babe507b0e3c15aca146b6cb66

Telling from IEGD 8.0 user guide page 17
http://download.intel.com/design/intarch/manuals/27404113.pdf
TV out is attached to DVO port. And I was wondering whether this TV out quirk is in some relation to the (EE) message in X.log or this entire bugreport.

[Bryce Harrington (bryce)]

7oby, upstream is asking,

"Which add2 card are you using? Is it ASUS G35 motherboard?"

[Erik-slagter (erik-slagter)]

*** Bug 15438 has been marked as a duplicate of this bug. ***

[Erik-slagter (erik-slagter)]

I have almost exactly the same phenomenon, also on a Dell XPS M1330 notebook. VGA is connected, HDMI is connected (using converter cable to a DVI monitor) on TMDS-1 using SVDO.

The difference is that my resolution is TWO pixel lines off instead of one. I have installed the latest "intel" xorg driver + xorg server from fedora testing (= xorg-x11-drv-i810-2.2.1-20.fc9), no difference (but it did fix the virtual console problem :-))

I also have assured that the problem is not in the monitor, I used to use this same setup with another laptop and it worked ok.

BTW the laptop has NO (analogue) TV OUT at all. HDMI only.

In the xrandr output below, three suitable 1600x1200 modes are specified. I'd guess and try them all, you never know, but I didn't find a way to select a mode from several with the same name.

Screen 0: minimum 320 x 200, current 2880 x 1200, maximum 2880 x 1200
VGA connected 1280x1024+1600+0 (normal left inverted right x axis y axis) 338mm x 270mm
   1280x1024 60.0*+ 75.0 60.0 60.0*
   1920x1080 59.9
   1680x1050 59.9
   1600x1024 60.2
   1400x1050 60.0
   1440x900 59.9
   1280x960 60.0
   1360x768 59.8 60.0
   1152x864 75.0 75.0 75.0 70.0 60.0
   1024x768 75.1 75.0 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 72.8 75.0 66.7 60.0 59.9
   720x400 70.1
LVDS connected (normal left inverted right x axis y axis)
   1280x800 60.0 +
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TMDS-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0*+ 60.0* 60.0
   1920x1200 60.0
   1920x1080 59.9
   1680x1050 60.0 59.9
   1600x1024 60.2
   1400x1050 74.8 70.0 60.0
   1280x1024 75.0 60.0 60.0
   1440x900 59.9
   1280x960 60.0 60.0
   1360x768 59.8 60.0
   1152x864 75.0 75.0 75.0 70.0 60.0
   1024x768 75.1 75.0 72.0 70.1 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 72.8 75.0 66.7 60.0 59.9
   720x400 70.1

[7oby (tobias-hain)]

It seems to me that having one or two pixel off is the lucky case. In general a TFT/LCD doesn't tune to any frequency or resolution like a CRT does.

I attached a Panasonic PT-AE500E video beamer by means of HDMI. This one simply stays black (= no image):

Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 3200 x 3000
VGA disconnected (normal left inverted right x axis y axis)
LVDS connected (normal left inverted right x axis y axis)
   1280x800 60.0 + 60.0
   1280x768 60.0
   1024x768 60.0
   800x600 60.3
   640x480 59.9
TMDS-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1280x1024 59.9*
   1280x800 60.0
   1280x768 60.0 62.5
   1280x720 59.9
   1024x768 60.0 59.9
   1072x603 59.8
   800x600 60.3 59.9
   856x481 59.6
   640x480 60.0 59.9

[Erik-slagter (erik-slagter)]

> It seems to me that having one or two pixel off is the lucky case. In general a
> TFT/LCD doesn't tune to any frequency or resolution like a CRT does.

> I attached a Panasonic PT-AE500E video beamer by means of HDMI. This one simply
> stays black (= no image):

Newer LCD's have smarter control than they used to in the past, all my LCD's can even display resolutions way larger than their native resolution, scaling down.

Also they don't have a problem with non-standard resolutions.

Back to the topic:

Although my monitor says the signal is two pixels off, it actually is one, so I have the same problem as the others here.

I also found a workaround to at least be able to have a sharp picture on your monitor using xrandr.

1. find out using xrandr -q what resolution/params your monitor likes most
2. use xrandr --verbose to see the modeline parameters associated with this mode
3. then using xrandr --newmode make a new modeline which is one pixel (vertical) larger than the original, you can probably do this without too much hassle, just take care that the vsync length is at least the vertical size + 1. It probably doesn't hurt if you add a few more. Leave the others alone.
4. use xrandr --addmode <output> <yourmodename>
5. use xrandr --output <output> --mode <yourmodename>

Works for me :-)

Example:

$ xrandr -q
TMDS-1 connected 1600x1201+0+0 (normal left inverted right x axis y axis) 408mm x 306mm
   1600x1200 60.0*+ 60.0 60.0
   1920x1200 60.0
   1920x1080 59.9
[ ... ]

$ xrandr --verbose
TMDS-1 connected 1600x1201+0+0 (0xa7) normal (normal left inverted right x axis y axis) 408mm x 306mm
        Identifier: 0x3d
        Timestamp: 1247967
        Subpixel: horizontal rgb
        Clones:
        CRTC: 0
        CRTCs: 0 1
        EDID_DATA:
                00ffffffffffff003438d9071e000000
                0511010380291f782eee95a3544c9926
                0f5054bfef00310a614c714f8180a940
                814001010101483f403062b0324040c0
                130098321100001e0000000000000000
                00000000000000000000000000fd0038
                4b1f5311000a202020202020000000fc
                00423230383053320a2020202020004c
  1600x1200 (0x5f) 162.0MHz +HSync +VSync
        h: width 1600 start 1664 end 1856 total 2160 skew 0 clock 75.0KHz
        v: height 1200 start 1201 end 1204 total 1250 clock 60.0Hz
  1920x1200 (0x60) 154.0MHz +HSync -VSync
        h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.0KHz
        v: height 1200 start 1203 end 1209 total 1235 clock 60.0Hz
[ ... ]

$ xrandr --newmode 1600x1200my 162 1600 1664 1856 2160 1201 1202 1210 1250
$ xrandr --addmode TMDS-1 1600x1200my
$ xrandr --output TMDS-1 1600x1200my

[7oby (tobias-hain)]

The workaround posted by Erik Slagter also works for me.

[Hong-liu (hong-liu)]

Thanks for the finding.
It seems a problem with SDVO-HDMI (which is not supported by our driver now), our driver treats SDVO-HDMI as SDVO-DVI, it works on some platforms but fails on other ones. Currently we are not sure what needed to be done to correctly SDVO-HDMI.

[Hong-liu (hong-liu)]

Created an attachment (id=15896)
set DVI encode mode for sdvo-hdmi

Please try this patch to see if there is any help.

[Tomasz-potega (tomasz-potega)]

The patch does not seem to make a difference - still getting 1680x1049 (Asus MW221U display driven by Asus P5E-V HDMI).

And yes, the workaround works for me, too.

[Hein-PietervanBraam (hp)]

I am not entirely sure if this is related or not, but on my ASUS P5E-V HDMI motherboard the HDMI head is not functioning at all. I have tested 2.2.1 and 2.3.0.

While xrandr --output TMDS-1 --off does turn off the monitor (led turns orange) and --auto turns it on, there is no display output.

I get the same error as reported below
(EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
If this is not related to the discussed bug, please let me know so I can file a proper (new) bugreport. I will subscribe to this bug.

[Hein-PietervanBraam (hp)]

I have also tried the workaround, this just got my second screen to display 'out of range'

[Allison Karlitskaya (desrt)]

This bug is possibly very much related to bug 13968. The only difference between the two bugs may be that our monitors tollerate being driven in weird modes differently (ie: stretching vs. acting 'out of range').

That said, I tried the patch in comment 10 and the workaround in comment 7 with my P5E-VM and got no love from either.

[code_n_coffee (christian-cthiessen)]

On my configuration

Fujitsu-Siemens Amilo Si 2636
debian testing
xserver-xorg-video-intel 2.3.1-1
Intel 965GM
1280x800 laptop display, 1680x1050 TFT connected via HDMI->DVI-D

nearly the same thing happened - but I even lost 2 lines so my monitor was running at 1680x1048 and also appeared blurry. This started a few weeks ago with some updates from the testing repo. I'm quite sure it's version 2.2.1 where it started. Now with 2.3.1 the bug still persists, but at least it fixed some other issues I had before :)
I have then created a 1680x1052 modeline which leads to the correct resolution, but a real fix in some future driver version would certainly be better.
If you need any more information please feel free to ask.

[scananza (scananza)]

code_n_coffee: hi, I have the same laptop as you but cannot figure out how to get the video-output to my LCD-TV on dvi...

if I try to switch with Fn+F10 it just hangs everything... I'm using ubuntu hardy, btw...

[code_n_coffee (christian-cthiessen)]

scananza: I know this Fn+F10 issue, it appeared in kernel 2.6.20 or 2.6.22. it's not a big problem as the monitor config can be controlled using the xrandr tool. just use a recent intel driver (see above), write a xorg.conf like the one attached and multihead should work perfectly.
The only case when I have to call xrandr manually is when I booted without a second screen and then attach it later. by reading "man xrandr" and asking google for keywords like "xrandr multihead" you will find everything you need.

[Hong-liu (hong-liu)]

Can you try the git tip of intel driver?
commit beb72ae5aa053303f5cc419e9c9d7c6db964f160 may fix your problems.

Thanks,
Hong

[Erik-slagter (erik-slagter)]

I read an article about DVI and HDMI the other day, in there it was suggested that HDMI (and DVI as well, if used this way!) encapsulates digital audio into the "video"- (which then of course becomes a "media"-) stream.

I wonder if perhaps this would explain why one line of video is missing on the monitor, couldn't it be that the last line is encoded as audio (either explicitly or implicitly) and the monitor discards the line?

[Erik-slagter (erik-slagter)]

Can someone supply me with a binary of the "intel" module, so I don't need to setup the whole circus for xorg (again)?

[franzb (franz-burgmann)]

(In reply to comment #15)
> Can you try the git tip of intel driver?
> commit beb72ae5aa053303f5cc419e9c9d7c6db964f160 may fix your problems.
>
> Thanks,
> Hong
>

The new driver from git works marvellously. I have been experiencing the same issues than others, output through HDMI => DVI blurry or none at all. Now I have as sharp a picture as you can wish for. Recommended! (Ubuntu 8.04, Asus P5E-V with Intel G35)

Sincerely,

Franz

[7oby (tobias-hain)]

> commit beb72ae5aa053303f5cc419e9c9d7c6db964f160 may fix your problems.

I did pull this one from git as well and it works! Having now 1920 x 1200 with no quirks!

I didn't go back revisions to find out whether this particular checkin or any before did fix the problem though.

Distribution: Ubuntu 8.04
System: Dell XPS-M1330, GM965 using HDMI connector

Have dropped this build here:
http://rs217.rapidshare.com/files/120972929/intel_drv.so.bz2

If you want to hotfix your Ubuntu 8.04 system make a backup of this file first and replace:
/usr/lib/xorg/modules/drivers/intel_drv.so

Don't be suprised it says module version 2.2.0, whilst Ubuntu 8.04 has 2.2.1. Master tag of git repository holds 2.2.0 version.

[7oby (tobias-hain)]

Meanwhile I checked the commit preceeding beb72a... which is c7fee208fd46e143965ea173984d284e1eec2a9b. And this preceeding build still has the bug.

[7oby (tobias-hain)]

Seems to be fixed upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=15370#c19

However fix is included in 2.2.0 branch. And Ubuntu 8.04 holds 2.2.1 of intel-driver.

"code_n_coffee" posted here that his problems started with 2.2.1. I never tested whether downgrading to some Ubuntu/Debian 2.2.0 fixed it as well. All I did is pulled uptodate git version now and it fixed the problem.

[Hong-liu (hong-liu)]

(In reply to comment #16)
> I read an article about DVI and HDMI the other day, in there it was suggested
> that HDMI (and DVI as well, if used this way!) encapsulates digital audio into
> the "video"- (which then of course becomes a "media"-) stream.
>
> I wonder if perhaps this would explain why one line of video is missing on the
> monitor, couldn't it be that the last line is encoded as audio (either
> explicitly or implicitly) and the monitor discards the line?
>

Yes, HDMI carries video and audio data together on the HDMI link, but the audio data is encapsulated in the HBlank and VBlank period. So video data should not be impacted.

[Hong-liu (hong-liu)]

(In reply to comment #20)
> Meanwhile I checked the commit preceeding beb72a... which is
> c7fee208fd46e143965ea173984d284e1eec2a9b. And this preceeding build still has
> the bug.
>

Thanks for the test. So I will mark this bug as fixed.

Thanks,
Hong

[7oby (tobias-hain)]

fix has been pulled to current development branch (from 2.2.0 branch):
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commit;h=85308ab8aaf58b6620a41621128eba0b7e1ffb44

and finally entered 2.3.2 release:
http://lists.freedesktop.org/archives/xorg-announce/2008-June/000589.html
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=shortlog;h=xf86-video-intel-2.3.2

[7oby (tobias-hain)]

Ubuntu 8.10 alpha (intrepid) currently contains version 2.4.2 of the intel driver which is >= 2.3.2. Therefore it is fixed in Ubuntu 8.10:
http://packages.ubuntu.com/intrepid/xserver-xorg-video-intel

[7oby (tobias-hain)]

Bug is a regression in 11.04 Natty.

Waiting for upstream fix:
https://bugs.freedesktop.org/show_bug.cgi?id=15370#c23

[7oby (tobias-hain)]

This bug is still a regression in 11.04 Natty as well as 11.10 Oneiric.

The current upstream bugreport is this one:
https://bugs.freedesktop.org/show_bug.cgi?id=38934

Meanwhile a fix has been released:
http://lists.freedesktop.org/archives/intel-gfx/2012-January/014257.html

And this fix made it into the mainline kernel 3.0.19 "drm/i915/sdvo: always set positive sync polarity":
http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.19

The "Oneiric update to 3.0.19 stable release" has been posted. Please consider the patch
"drm/i915/sdvo: always set positive sync polarity"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/926309

for inclusion into next ubuntu Oneiric stable kernel.