Created attachment 91091 [details]
Using SuSE-Linux, my HP EliteBook 8730w does not manage to produce output on
its HDMI plug. The VGA plug works. HDMI works when booting MS-Windows 7 Pro
on this machine, which I tested with a 1920x1024 HDMI TV and a 1280x1024 DVI
monitor. I can plug the HDMI cable into a Raspberry Pi and it works. So the
cables or monitors should not be at fault.
The graphics card is NVidia Quadro FX 2700M, reporting itself as NV94
(NV50 according to http://nouveau.freedesktop.org/wiki/CodeNames/).
Initially I observed this issue in SuSE-Linux 11.4. In the hope for a fix, I
upgraded to SuSE-Linux 13.1 yesterday, but it persists.
xrandr always[*] reports two disconnected DVI-D plugs:
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192
LVDS-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 367mm x 230mm
DVI-D-1 disconnected (normal left inverted right x axis y axis)
DVI-D-2 disconnected (normal left inverted right x axis y axis)
VGA-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm
Xorg.0.log (attached) always contains:
(II) NOUVEAU(0): EDID for output DVI-D-1
(II) NOUVEAU(0): EDID for output DVI-D-2
(II) NOUVEAU(0): EDID for output VGA-1
I don't know why it reports DVI-D instead of HDMI, or why there appear to be 2
DVI-D devices -- perhaps it's a dual-link HDMI connector?
I have tried:
- Configuring HDMI via xrandr (see below)
- Booting with and without HDMI cable connected
- Hotplugging HDMI
I've not tried installing the binary NVidia driver.
[*] When I tried the monitor the first time, both DVI-D plugs where
reported as connected once and only once, yet with no mode information. I've
not seen that happen a second time.
Reading some net.wisdom https://bbs.archlinux.org/viewtopic.php?pid=975209
I tried manual activation as follows:
$ xrandr --addmode DVI-D-2 1280x1024
$ xrandr --verbose --output DVI-D-2 --mode 1280x1024
crtc 1: 1280x1024 59.9 +0+0 "DVI-D-2"
xrandr: Configure crtc 1 failed
crtc 0: disable
crtc 1: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
Some user mentions a perhaps similar issue with SuSE Linux on a HP machine,
however his is a hybrid Intel + NVidia graphics machine, mine isn't:
Bug #54512 is different too, there the drm module got some EDID response.
Attached logs are from SuSE 13.1, which I installed by removing 11.4. (This
time I booted into safe mode for an unrelated reason).
Linux machine 3.11.6-4-desktop #1 SMP PREEMPT Wed Oct 30 18:04:56 UTC 2013 (e6d4a27) x86_64 x86_64 x86_64 GNU/Linux
Created attachment 91095 [details]
dmesg.log when booting with drm.debug=4
I believe the core part is:
[drm:drm_helper_probe_single_connector_modes], [CONNECTOR:17:DVI-D-1] disconnected
without any error message.
Each time I plug or unplug the HDMI cable, I get this log:
[drm:drm_helper_hpd_irq_event], [CONNECTOR:17:DVI-D-1] status updated from disconnected to disconnected
[drm:drm_helper_hpd_irq_event], [CONNECTOR:19:DVI-D-2] status updated from disconnected to disconnected
Created attachment 91099 [details]
xrandr --verbose output with 1280x1024 external monitor
Something crazy: I put the machine into suspend mode, then resumed.
Voilà, both DVI-D-1+2 are reported connected.
xrandr --output DVI-D-1 --auto
causes the laptop's screen to turn black with still no signal on the HDMI plug. From there, all I could to was switch the machine off.
Turning VGA-1 on or using variations such as
xrandr --verbose --output DVI-D-1 --same-as LVDS-1
xrandr --verbose --output DVI-D-1 --auto
xrandr: cannot find crtc for output DVI-D-1
xrandr --verbose --output DVI-D-2 --auto
xrandr: cannot find crtc for output DVI-D-2
avoided the black screen but never got a signal out of HDMI.
Yesterday, I had avoided suspend mode, because the colors went wrong after resume. However, they turned normal after Ctrl-Alt-F1 -> F7.
Created attachment 91105 [details]
dmesg.log when booting with drm.debug=4, incl. suspend/resume cycle
Perhaps a dmesg.log including a suspend/resume cycle is more revealing?
I'm not sure whether I was entirely clear. I never observed a HDMI signal on the monitor, but the weird behaviour at resume proves that at least the EDID signals transit through the cable, some time. Perhaps that's 2 bugs?
- No immediate EDID at boot time;
- no HDMI out, even past resume where EDID happened
No HDMI either when booting Ubuntu 13.04 on the same machine from a live DVD.
Alas, using the live DVD, I couldn't check the behaviour described in comment #2 past a suspend&resume cycle, because the machine hung shortly after resume.
I think this issue might be the same one as bug #60680. Can you try the patch at https://bugs.freedesktop.org/attachment.cgi?id=92319 and see if it helps? If it doesn't, can you upload your vbios (/sys/kernel/debug/dri/0/vbios.rom) as well as a dmesg booting with nouveau.debug=VBIOS=trace,PDISP=debug -- that might show some clues.
Erm, sorry, that patch link was wrong. Can you give drm-next a shot? (Or try 3.14-rc1 when that comes out?)
I'm sure you meant attachment #92185 [details] [review] not the log file, but I'm sorry I've never recompiled a kernel or driver yet, despite decades of UNIX. One thing that worked well in the past with the Intel driver was when Keith put an intel_drv.so online for us users to try out. Is your nouveau_drv.so online (for SuSE 13.1/64) somewhere?
(In reply to comment #7)
> I'm sure you meant attachment #92185 [details] [review] [review] not the log file,
Indeed. Although a different approach was finally merged, that the original bug reporter (and several others with the same issue) confirmed also fixed the problem.
> but I'm sorry I've never recompiled a kernel or driver yet, despite decades
> of UNIX. One thing that worked well in the past with the Intel driver was
> when Keith put an intel_drv.so online for us users to try out. Is your
> nouveau_drv.so online (for SuSE 13.1/64) somewhere?
Unfortunately this is for a kernel module. If I were really clever, I could figure out exactly how your kernel was built (and exactly what version), which compiler, which settings, etc, and build a module that worked for you. But I'm not that clever, or perhaps too lazy -- take your pick. Here's a guide for building your own kernel on SUSE:
I have no clue whether these instructions are in the least valid. You can also just wait for 3.14-rc1 to come out and perhaps a fresh kernel will be installable from
(These are all things I found with a quick Google search -- I have no knowledge of SUSE beyond the fact that its auto-configurer tool... YaST iirc... that overwrote all of my careful config modifications wildly annoyed me back in ~1999 or so and I decided to never touch it again.)