To my knowledge it's currently not possible to enable/disable monitors at runtime (like changing the active ServerLayout, or setting something not defined in xorg.conf) PS: the nvidia provides a way to do so at driver level presetting everything in the config with modes, but that's not the way to go! What I would suggest is to have Xorg start, and in case of trouble default to a running solution, the best one Xorg can find in a reasonable time (e.g. framebuffer or vesa/vga). This is very useful for machines with no LinuxConsole enabled in the kernel, as those hosts are unuable if X fails (maybe they could be administered via network, if appropriate network services are running, but that would probably require someone with root rights) When running and changing settings, if something fails, fall back to previous settings. Things that one should be able to do are: - Enable/Disable screens - Attach/detach outputs (CRT,LFP,DFP,...) to screens - Alternate between single-head, clone and dual-head - Attach input devices (mouse, keyboard) to screens (all, first, second, none) I don't know if it's possible, when running X in dual-head mode but without xinerama, to run e.g. KDE on display :0,0 and Gnome on display :0,1 without any conflict. (Can't test yet as I'm working with Alan to get dual-head working on my i855) If it's not, then this should be added as well! One might want to run a complete desktop-environment on one display, but just a single fullscreen on the other display, or run different desktop environments concurrently. In relation to this, the input devices should be assignable to either all displays, or individual displays, like touchpad for screen on LFP, USB mouse for the second screen. (=> 1 computer for two independent people) Any comments, extensions and discussions welcome!
*** Bug 2512 has been marked as a duplicate of this bug. ***
*** Bug 4473 has been marked as a duplicate of this bug. ***
*** Bug 5464 has been marked as a duplicate of this bug. ***
*** Bug 4827 has been marked as a duplicate of this bug. ***
*** Bug 5886 has been marked as a duplicate of this bug. ***
*** Bug 6039 has been marked as a duplicate of this bug. ***
*** Bug 6194 has been marked as a duplicate of this bug. ***
*** Bug 4504 has been marked as a duplicate of this bug. ***
*** Bug 2519 has been marked as a duplicate of this bug. ***
*** Bug 4567 has been marked as a duplicate of this bug. ***
The current X.org has one problem, when compared to other systems, such as Windows XP. More specifically: It does exactly as wrote in it's configuration file(s). The feature, I would like to request, is not of a value to you, X-experts, but it's _very_ valueable to average Joe Sixpack. I want to ask adding auto-fallback in case of X-Server failure. Today, X-Server might fail to start for many reasons, including: 1. incorrect X configuration by user 2. incorrect X configuration by OS (Linux distro) 3. replacement of video card 4. buggy drivers In all those cases, Linux user will find the problem, and fix it, while Joe Sixpack/Windows user will return to Windows, after unsuccessfully trying Linux. I want to prevent this, by suggesting you to add a new feature to X-Window: Automatic Fallback to VGA Safemode. In case X would fail to run from it's configuratiuon it _must_ automatically run itself in stable mode, using generic, non-accelerated drivers. (either fbdev, VESA or VGA) This single feature will increase Linux (and other Free OSes) popularity among Windows users dramatically. I'm not an X-exprert, so I have a few question to you: 1) what do you recommend me as a most stable way to run X ? I want a generic driver that will run on any video card, with at least 1MB of VRAM & VGA standards. Should I use VGA/vesa/fbdev or some other Generic X driver? 2) What's the difference between the generic drivers? 3) When Windows XP fails to run a driver, to what state it fails ? ------------------ Xorg should automatically revert to standard vga mode in case the correct video driver is unstable or not found or in case when Xorg config-file is damaged. This functionality, like Windows XP, will ensure that X always loads no matter what, thus making it much more user friendly.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Between randr 1.2 and input hotplug, this should be done in 1.5.
a LOT has been done since that bug opened, much has been fixed and redesigned in better way but i not yet agree that all original issues has been addressed yet: 0) "What I would suggest is to have Xorg start, and in case of trouble default to a running solution, the best one Xorg can find in a reasonable time (e.g. framebuffer or vesa/vga)." Not done. Still X fail (with output stuck on empty VT7 or whatever) if configured driver fails, for example - xf86-video-ati was not linked well and could not load but xf86-video-fbdev was not engaged (maybe it can't work with kms/drmfb yet but it makes no difference). though it could have been my fault for not installing xf86-video-vesa also. 1) "Enable/Disable screens" There is no dynamic screen management. they say, there is no official multi-screen support either these days ! 2) "Attach/detach outputs (CRT,LFP,DFP,...) to screens" No dynamic output management for multi-screen, only for one randr/xinerama screen (no, screen-parts are not screens. even xrandr do not say they are). 3) "Alternate between single-head, clone and dual-head" "{single,dual}-head" are too ambiguous terms to judge - they do not specify relations of outputs, screen\s and X. it is possible only to attach whatever-the-hell-you-want outputs to one screen to expand it or clone the picture from it. 4) "Attach input devices (mouse, keyboard) to screens (all, first, second, none)" that is Possibly done. (while you can't say "screens" but "X instances" since several users can not share X instance or its screen\s, they must get their own. and there is no use for attaching different inputs for different screens in multi-screen setup of same user/X instance, is it ? or maybe there actually is, like mouse+keyboard/IR+gamepad split... then it is Not Done) i'm not sure if you could dynamically manage inputs for multi-seat setup though (attach and drop inputs between users/X instances dynamically without shutting them down). 5) >> "I don't know if it's possible, when running X in dual-head mode but without xinerama, to run e.g. KDE on display :0,0 and Gnome on display :0,1 without any conflict." "running X in dual-head mode but without xinerama" = multi-head/multi-screen configuration ("zaphod mode") - Not maintained or officially supported at all, they say ! i'm also not sure it it possible to run one DE on one screen and another on... another for yourself [ on radeon/nvidia drivers that still somehow provide multi-screen]. something tends me to say that it's not possible and both will go apeshit but it needs to be checked out better. but submitter probably meant multi-seat there anyway - and you can run any DEs inside separate X's (not :0.0 and :0.1 screens though but :0.0 and :1.0). 5) "One might want to run a complete desktop-environment on one display, but just a single fullscreen on the other display..." multi-head/multi-screen again - not supported/partial deprecated support. "...or run different desktop environments concurrently" multi-seat again - vaguely supported. 6) "In relation to this, the input devices should be assignable to either all displays, or individual displays, like touchpad for screen on LFP, USB mouse for the second screen. (=> 1 computer for two independent people)" #4 again - possible with statical configuration for multi-seat setup, dynamic configuration is uncertain, not possible for multi-seat. ____________________ "Between randr 1.2 and input hotplug, this should be done in 1.5" randr 1.X and enhanced input hotplug support are great stuff for single-screen setup, with single or multiple outputs, and was done excellently but they not address any issues of multi-screen or multi-seat setups. i heard about some pending enhancements for multi-seat but right now its support is still questionable and hacky. multi-screen support is dying off completely and current developers state two reasons: 1) "too few" people want it 2) current developers do not want, use or interested in it for themselves. so, if even there is multi-screen support, it is in even more questionable and hacky state. overall - Xorg configuration still suck. i suggest marking this bug as dependent upon bug 28779 and any other similar one or Closing it with WONTFIX PS: >> "This functionality, like Windows XP, will ensure that X always loads no matter what, thus making it much more user friendly." Windows(tm) suck beyond imagination, it likes to completely self-destruct on video driver failures and may operate with certainty on generic drivers only when any other ones are not present or explicitly blocked. they did, however, added functionality to reset failed driver in never versions but not without a lot of pain for driver developers... and it still finds ways to kill itself with them occasionally. it's no good to mimic it but idea of falling back between drivers is good, especially if they are not kernel ones.
(In reply to comment #14) > they say, there is no official multi-screen support either these days ! They would be lying to you then. > "running X in dual-head mode but without xinerama" = multi-head/multi-screen > configuration ("zaphod mode") - Not maintained or officially supported at all, > they say ! Again they are wrong, or you are misunderstanding them. Nothing has changed in the X server regarding support for multiple independent screens from separate devices. Perhaps you're confusing this with the oft-discussed issues the ATI driver had with offering multiple screens from a single device (their "Zaphod" mode of multi-head handling) - that was a driver issue with that driver for exposing the capabilities of a single device.
maybe, it's all very confusing. i referring to this -> http://www.mail-archive.com/xorg@lists.freedesktop.org/msg10649.html "Alex Deucher: For the 50th time, Xorg didn't drop it support for zaphod mode, it's just not commonly used, so it doesn't get as much testing as randr. If it did, we won't be having this discussion now. Intel dropped support in their driver, and the radeon support tends to succumb to bit-rot since it's not tested too often. The problem is, zaphod mode (as it is currently implemented) is hard to support. It was something of a hack to begin with and it does not fit well with the way hardware is designed. The driver loads twice (!) on the same hardware and each instance has to keep synchronized with the each other and not step on the other's feet. Ideally someone would write some common xserver code to implement zaphod mode without needing driver support, but so far no one has done that." Xorg maybe "didn't drop it support" but if it non-existent on even 1 driver then it's incomplete and if it not maintained - it tends to be dropped at some moment. besides - using several driver instances for same card is not good (for several cards - fine, but to "drive" one card - no good. you don't use two drivers to drive a car). looks like it more of a driver thing than server (i.e. you don't need to break server to break it) and a way it done is ugly even if all drivers will implement it (i.e. issue still stands).
wait... are you implying that there is kinda exist a "usual way" to get multi-screen, non-multi-seat setup and it requires separate device for that and doing it on single device is considered as "unusual" and that's what being dropped by Intel ? :\ if that correct then it also not very good. you would not want to imagine what unspeakable things i did with X, video cards, drivers and monitors for past few years (you can see in pictures in bug 28779) but i never even thought to use separate card to add screen for same X session. when i pictured that in last picture i thought: "this is maybe too much - one card have more that enough means to provide that but hell, why not ?", but if this was "proper" way all along - i must be even more confused.
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.