Bug 16357 - Load detection-related "Option Enable" override nonfunctional
Summary: Load detection-related "Option Enable" override nonfunctional
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-15 03:01 UTC by salj@triplefusion.net
Modified: 2018-06-12 19:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
HTPC Xorg config file for radeon (79.53 KB, text/plain)
2008-06-15 03:01 UTC, salj@triplefusion.net
no flags Details

Description salj@triplefusion.net 2008-06-15 03:01:47 UTC
Created attachment 17118 [details]
HTPC Xorg config file for radeon

Expected behaviour: VGA-0 always enabled when "Option Enable" is set.
Observed behaviour: appears to do nothing.

See attached config + logs, they ended up too large for the comment field.

This is running on my HTPC, with a RV350 R9600 Mobility. In all circumstances that Xorg gets up and running, the other monitor can be successfully manipulated with xrandr.

Dualhead isn't my goal, though, if anything I'm looking for a reliable way to force VGA-0 to be the only enabled output, and stay so whether or not the X server thinks it's electrically connected to anything. This is a laptop running with its lid closed as a HTPC with a CRT TV connected via RGB-SCART as its only output, an output which is frequently disconnected during startup via a physical switch. Load detection is at best highly undesirable. I have managed to disable it The Hard Way by patching it out of the driver, but obviously this is not ideal.
Comment 1 Alex Deucher 2008-12-03 01:50:25 UTC
you can disable load detection with xrandr:
xrandr --output VGA-0 --set load_detection 0
Comment 2 salj@triplefusion.net 2008-12-23 10:09:17 UTC
Fabulous suggestion, too bad I can't actually do that because Xorg decides to NOT START AT ALL in the configuration I desire. Bit hard to run xrandr to runtime-reconfigure a non-running X server.

If I have the display connected to the VGA port, everything works fine, but if it isn't (because the display is connected to another input via a hardware switch that provides no dummy load) load detection decides the output should just be disabled, period, and then the server dies because hey, it has no outputs.

(II) RADEON(0): Port0:
 Monitor   -- AUTO
 Connector -- VGA
 DAC Type  -- Primary
 TMDS Type -- None
 DDC Type  -- 0x60
[...]
(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0
finished output detect: 0
[...]
(EE) RADEON(0): No connected devices found!
finished all detect
before xf86InitialConfiguration
(II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0
(II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
(II) RADEON(0): Output: LVDS, Detected Monitor Type: 0
(EE) RADEON(0): Using LVDS default
in RADEONProbeOutputModes
(II) RADEON(0): Added native panel mode: 1024x768
(II) RADEON(0): Adding Screen mode: 1024x576
(II) RADEON(0): Total number of valid Screen mode(s) added: 1
(II) RADEON(0): Output: S-video, Detected Monitor Type: 0
(II) RADEON(0): Output VGA-0 enabled by config file
(II) RADEON(0): Output DVI-0 disconnected
(II) RADEON(0): Output LVDS disabled by config file
(II) RADEON(0): Output S-video disconnected
(EE) RADEON(0): Output VGA-0 enabled but has no modes
(EE) RADEON(0): No valid modes.
(II) Unloading /usr/lib/xorg/modules//libint10.so
(II) Unloading /usr/lib/xorg/modules//libvgahw.so
(EE) Screen(s) found, but none have a usable configuration.

Fatal server error:
no screens found
giving up.
xinit:  Connection reset by peer (errno 104):  unable to connect to X server
Comment 3 Adam Jackson 2018-06-12 19:10:21 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


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.