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.

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

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.

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

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  

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  

> 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

The workaround posted by Erik Slagter also works for me.

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.

Created attachment 15896 [details] [review]
set DVI encode mode for sdvo-hdmi

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

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.

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.

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

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.

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

Thanks,
Hong

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?

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

(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

> 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.

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

(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.

(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

Reopening. Regression. Affects Ubuntu 11.04.

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.

Tested on same platform as in first posting. 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.

Yep confirmed, regressed in 2.6.38.2.

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.

(In reply to comment #23)
> Reopening. Regression. Affects Ubuntu 11.04.

Please don't reuse this bug tracker. Please file a new bug. Thanks.