Bug 14611

Summary: X fails to start without display attached
Product: xorg Reporter: Sebastian Dyroff <bug>
Component: Server/GeneralAssignee: Jesse Barnes <jbarnes>
Status: VERIFIED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: enhancement    
Priority: medium CC: alexdeucher, andreas.8aer, billymacdonald, charles.bovy, keithp, rbu, simon.farnsworth, vortigher0
Version: unspecified   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log without monitor attached
none
Xorg log with monitor attached
none
dmesg output
none
xrandr --verbose
none
Patch against git master to always enable enabled outputs, even if they're disconnected from the PoV of hardware none

Description Sebastian Dyroff 2008-02-21 16:39:03 UTC
Created attachment 14489 [details]
Xorg log without monitor attached

My system:

-- chipset: G33
-- system architecture: 64-bit
-- xf86-video-intel: 2.1.1
-- xserver: 1.3.0.0-r4
-- mesa: 6.5.2-r1
-- drm: 2.3.0
-- kernel: 2.6.23-gentoo-r3
-- Linux distribution: Gentoo
-- Machine or mobo model: MSI G31M2


I've connected a LCD tv to the dvi port with a hdmi adapter.


steps to reproduce:

disconnect monitor before starting X (or switch it off)


expected behaviour:

use modeline for monitor provided in xorg.conf and respect the "DevicePresence" option.
Comment 1 Sebastian Dyroff 2008-02-21 16:40:01 UTC
Created attachment 14490 [details]
Xorg log with monitor attached
Comment 2 Sebastian Dyroff 2008-02-21 16:42:12 UTC
Created attachment 14491 [details]
dmesg output
Comment 3 Sebastian Dyroff 2008-02-21 16:42:43 UTC
Created attachment 14492 [details]
xrandr --verbose
Comment 4 Hong Liu 2008-02-22 01:05:29 UTC
This is expected with the current code logic.

We can't find an active output, then X server quits.
Comment 5 Robert Buchholz 2008-02-25 01:36:49 UTC
Being the expected result from the code logic does not make it the expected result from a user perspective.

Is there a technical reason X cannot be started if the modelines are hard coded?
Comment 6 Hong Liu 2008-02-25 16:50:57 UTC
(In reply to comment #5)
> Being the expected result from the code logic does not make it the expected
> result from a user perspective.
> 
> Is there a technical reason X cannot be started if the modelines are hard
> coded?
> 

X can start with hardcoded mode, but X needs some display to be connected and be detected. Then X will assign the hardcoded modeline to the display.

If there is no display connected on any output port, X will quit.
Comment 7 Robert Buchholz 2008-02-25 17:21:58 UTC
Can we reopen this bug as a feature request then, because having an Option to not have X quit, but the ability to hardcode which output a display should be assumed attached (even if not detected) has advantages. I can think of some use cases where this is relevant to me, personally:
 (1) I can switch on the LCD after the PC.
 (2) I can use X forwarding techniques that operate on a running X server.
 (3) I can replay video on a machine remotely via ssh, even if the display is
     off (maybe all I need is the audio output, or I am debugging).
 (4) I can prioritize DVI output over VGA, even if no DVI is connected,
     but VGA is (similar to (1)).

Again, if it is possible to start an X with static modes, and it can be useful, why forbid it?
Comment 8 Michael Fu 2008-03-18 16:54:52 UTC
*** Bug 15106 has been marked as a duplicate of this bug. ***
Comment 9 Gordon Jin 2008-04-16 00:07:58 UTC
Reopening for not to forget this feature request.
Comment 10 Hong Liu 2008-04-16 20:53:20 UTC
This patch will enable X server starting when you manually enable the output (by the enable option).

1. you need to associate a monitor section with your output (f.e. VGA)
add Option "monitor-VGA" "VGA" to the device section
2. enable the output by add option enable to the monitor section
Section "Monitor"
    Identifier "VGA"
    Option "enable" "true"
EndSection

With this patch applied, the output will be assigned to some basic modes.
So if you want to hotplug some big monitor later, you need to enlarge the virtual size also in xorg.conf.


diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 8c2b247..771523e 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -1342,7 +1342,8 @@ xf86ProbeOutputModes (ScrnInfoPtr scrn, int maxX, int maxY)
         */
        output->status = (*output->funcs->detect)(output);

-       if (output->status == XF86OutputStatusDisconnected)
+       if (output->status == XF86OutputStatusDisconnected &&
+           !xf86ReturnOptValBool(output->options, OPTION_ENABLE, FALSE))
        {
            xf86OutputSetEDID (output, NULL);
            continue;

Comment 11 Michael Fu 2008-07-10 00:10:19 UTC
*** Bug 15432 has been marked as a duplicate of this bug. ***
Comment 12 Jesse Barnes 2008-08-04 11:46:29 UTC
Reassign Hong's bugs back to the default for triage.
Comment 13 Gordon Jin 2008-08-04 19:36:44 UTC
Zhenyu, could you follow up with this issue?
Comment 14 Jesse Barnes 2008-12-18 13:20:26 UTC
I think this got fixed in the server recently...
Comment 15 Gordon Jin 2008-12-18 19:19:43 UTC
This still exists with server-1.6 branch.
Comment 16 Simon Farnsworth 2009-04-24 09:18:16 UTC
Created attachment 25110 [details] [review]
Patch against git master to always enable enabled outputs, even if they're disconnected from the PoV of hardware

I've taken Hong Liu's suggestion from comment #10, and turned it into a git patch against master. Any chance of having this applied?
Comment 17 Rafael Diniz 2009-05-19 12:36:42 UTC
I tested the patch in some machines, and it works fine.
Can anyone apply this patch, or fix this wrong X behavior?
At least for me, the fix we are talking here is a important bugfix, as it's very important for production machines, especially those used in a broadcast environment, where the machines are usually rack-mounted, w/ 99% of the time without a monitor attached.


Comment 18 Gordon Jin 2009-06-12 11:19:19 UTC
*** Bug 22254 has been marked as a duplicate of this bug. ***
Comment 19 Neil Alldrin 2009-07-11 16:20:07 UTC
I also confirm that the patch works on one of my machines. I need it for a media computer connected through HDMI to an AV receiver. If the receiver's HDMI input isn't set to the PC then it looks like the monitor is disconnected.
Comment 20 Andreas Baer 2009-08-20 05:17:56 UTC
I tried it for one of my machines and it did NOT work, maybe I'm doing something wrong?

My system:
- chipset: intel 82Q963/Q965
- architecture: i686
- xf86-video-intel: 2.2.0
- kernel: 2.6.23.17
- x-server: 1.4.0

x-server log w/ monitor:
(==) Using config file: "/etc/X11/xorg.conf"
(EE) Failed to load module "glx" (module does not exist, 0)
(II) Module "ddc" already built-in
(II) Module "i2c" already built-in
(II) Module "ramdac" already built-in
(EE) intel(0): [dri] I830CheckDRIAvailable failed: glx not loaded
(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000)
Could not init font path element /usr/share/fonts/TTF/, removing from list!
Could not init font path element /usr/share/fonts/OTF, removing from list!

x-server log w/o monitor:
(==) Using config file: "/etc/X11/xorg.conf"
(EE) Failed to load module "glx" (module does not exist, 0)
(II) Module "ddc" already built-in
(II) Module "i2c" already built-in
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found

x-server log w/o monitor and patched driver/xorg.conf:
(==) Using config file: "/root/xorg.conf"
(EE) Failed to load module "glx" (module does not exist, 0)
(II) Module "ddc" already built-in
(II) Module "i2c" already built-in
(EE) intel(0): Output VGA enabled but has no modes
(EE) intel(0): No valid modes.
(EE) Screen(s) found, but none have a usable configuration.
Fatal server error:
no screens found

abstract from my xorg.conf:
Section "Monitor"
        Identifier     "VGA"
        VendorName     "Monitor Vendor"
        ModelName      "Monitor Model"
        Option         "enable" "true"
        Option         "DPMS"
EndSection

Section "Device"
        Identifier     "Card0"
        VendorName     "Intel Corporation"
        BoardName      "82Q963/Q965 Integrated Graphics Controller"
        BusID          "PCI:0:2:0"
        Driver         "intel"
        Option         "NoDDC" "yes"
        Option         "monitor-VGA" "VGA"
EndSection

Section "Screen"
        Identifier     "Screen0"
        Device         "Card0"
        Monitor        "VGA"
        DefaultDepth   16
        SubSection "Display"
                Depth      16
                Modes      "1024x768"
                Viewport   0 0
        EndSubSection
EndSection
Comment 21 Robert Buchholz 2010-02-18 11:19:10 UTC
i can confirm the patch by Simon Farnsworth and the xorg.conf option fixes the problem reported in this bug. This is with X.Org X Server 1.6.5 and xf86-video-intel 2.9.1.

Can any of the intel/X developers comment on the process of merging this patch into the git HEAD?
Comment 22 Alex Deucher 2010-02-18 15:41:35 UTC
Pauli Nieminen sent the patch to the xorg-devel list.  I put my Reviewed-by on it, but so far it hasn't been merged.
Comment 23 Jesse Barnes 2010-02-22 13:46:11 UTC
Keith pushed this today.

commit 93ff1bc5884cdfca1132af7fbc06c48e06f218c8
Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Date:   Mon Feb 15 14:18:00 2010 +0200

    Always enable outputs that have been forced on in the configuration file
Comment 24 Gordon Jin 2010-02-25 23:04:53 UTC
With this xserver fix and explicitly enabling VGA in xorg.conf (as said in comment#10), now I can start X without monitor connected. 

But there's exception: 
if I disconnect monitor AFTER kernel booting, the kernel still stores EDID
info (buggy), and when start X, it considers EDID available so not accepting default modes, resulting no valid modes available and still fail to start. I'm filing bug#26743 to track this kernel issue.

I guess comment#20 from Andreas fall into this case?
Comment 25 Julien Cristau 2010-03-15 13:53:26 UTC
*** Bug 27091 has been marked as a duplicate of this bug. ***

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.