In the process of configuring my scripts for initialization and docking of my T510 laptop into my series 3 docking station under Fedora 15, I have discovered that xrandr 1.3.4 does not manage the number of graphics heads in use at all. Unlike previous versions which seemed to honour obvious restrictions. In particular, my laptop only has two graphics heads, so only two outputs (monitors) may be active at any given time. In addition at least one output must remain active. In the discussion below you can see the hoops I had to jump through to get my laptop to initialize correctly when plugged into my docking station with dual monitors connected, and to dock and undock correctly. With X server and xrandr version, I only need to issue commands to set the VGA monitor's resolution. All this extra juggling of what was active and what was inactive seemed to happen automatically. e.g. If both of my monitors display was active my laptop display was never active. When I undocked my laptop, but the monitors when to inactive right away. (Now there seems to be enough of a delay that sometimes all three are active at once, which freezes the X server on a black screen.) Chances are the gnome 3 desktop is responding to the events generated by activating and deactivating monitors differently, which is probably part of the problem. But I cannot blame gnome for the complete problem, as even a simple command like adding a mode to my VGA1 output will freeze X if I don't fist swap my primary output to HDMI3 and set LVDS1 to off first. Just adding the mode should not even be activating the output... Having something like a '--only' option to xrandr would probably allow much easier workaround to the problem. In that then I could simply do something like: xrandr --output LVDS1 --auto --only to restore to an undocked state, and : xrandr --output HDMI3 --mode 1280x1024 --only xrandr --output VGA1 --right-of HDMI3 --mode 1280x1024_75 to restore to a docked state. Of course there would need to be an appropriate delay to make sure the hardware was done initializing before xrandr returns, or I would have to add in a sleep statement between commands. +++ This bug was initially created as a clone of Bug #708530 +++ Description of problem: With Fedora-13, I could dock and undock my laptop into my dual monitor setup without problems. With Fedora-14 I had to customize the gdm init a bit, but for the most part it worked. With Fedora-15 whenever I try docking or undocking my monitors, all of the screens go blank. The only thing I can do at that point is use CTRL+ALT+F2 to login to a console window, drop to init 3 and then back to init 5. That kills my login session, but at least it re-initializes my monitors. Even this trick did not work out of the box. In fact when I first started my computer after upgrading only one monitor worked (not the one with the login window) so I had to login blind folded. I will include the details of what it took to get the initialization to work... Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. Plug a Thinkpad T510 into a docking station connected to one DVI monitor and one VGA monitor 2. Unplug the thinkpad from the same setup... 3. Actual results: All screens go blank. Expected results: The two monitors come to life when the laptop is plugged in, and the laptop display comes to life when unplugged. Additional info: With Fedora-14 I had the following as part of my /etc/gdm/Init/Default file to allow the monitors to be properly configured. These commands were not required for docking to work, only for me to get the correct resolution from the VGA monitor, and make my primary monitor the left monitor instead of the right: xrandr --newmode "1280x1024_75" 138.75 1280 1368 1504 1728 1024 1027 1034 1 072 -hsync +vsync xrandr --addmode VGA1 "1280x1024" xrandr --addmode VGA1 "1280x1024_75" xrandr --output HDMI3 --primary With Fedora-15 the same sequence of command simply does not work. If I enter them one at a time the VGA monitor will go into an auto-adjust loop and never allow me to finish. However, the following set of commands do work: if ( xrandr --output HDMI3 --mode "1280x1024" ) then xrandr --output HDMI3 --primary xrandr --output LVDS1 --off xrandr --newmode "1280x1024_75.00" 138.75 1280 1368 1504 1728 1024 1027 1034 1 072 -hsync +vsync xrandr --addmode VGA1 "1280x1024_75.00" xrandr --output VGA1 --mode "1280x1024_75.00" fi It seems one of the limitations with the hardware is only two displays can be active at a given time. Fedora-14 somehow knew that. With Fedora-15 I have to make sure I have to manually manage that. Meaning I need to set the DVI monitor to primary, and then disable the laptop display before I can even begin to configure the VGA1 display. Likewise, if I were to manually try and undock I would need to manually disable VGA1, then enable LVDS1, and then switch the primary to LVDS1. I could then disable HDMI3. However, this procedure only works if I run them before physically undocking the laptop... I remember somewhere there is the ability to script undock and dock options. If you can provide the names of those scripts, I can try manually coding a workaround that works for me. But really, this should just work. There shouldn't be a bunch of manually coding needed to dock and undock a laptop. --- Additional comment from briemers on 2011-05-28 20:17:13 EDT --- BTW. I'm not really sure if this is the correct component to report this bug against. I have been researching a solution, and it seams the kernel driver needs to be updated to send the correct events. Also, it seems an xrandr or xorg problem that it tries activating more than two graphics heads on hardware that does not have more than two. About the only reason this might be a gnome issue is that it worked with gnome in the past. Despite the lack of a docking event, it still works with GNOME if there is only one monitor connected to the docking station. So it appears like GNOME may have a workaround that nolonger works. If that is not the case, then please reassign this bug to the appropriate component. BTW. As a workaround, when I plug in laptop into the docking station I get udev event for the USB keyboard and mouse connected to the docking station. Presumably if I find a set of xrandr commands that work consistently I could use that event to trigger it. The problem is right now with a workaround is I don't have a xrandr sequence that does not sometimes leave all the displays black and un-responsive to even switching to a virtual console. --- Additional comment from briemers on 2011-05-29 16:43:57 EDT --- Created attachment 501654 [details] example docking script I have a work-around. The actual workaround is rather complicated, and very particular to my hardware setup. So it is probably just better to first summarize lessoned learned before presenting a workaround. First it seems if at anytime an attempt is made to have fewer than 1 active displays, then Xorg may freeze. If at any time there is more than 2 displays active, again it may freeze on T510 Series 3 docking station, since the there are only two graphics heads available in the T510. To meet this criteria in the thinkpad-dock.sh script (which I will attach) first I run a loop that disables all outputs except HDMI3 and LVDS1. (As I always have one of these two active.) Next I enable LVDS1, as I can always do this safely if I have disconnected everything else except my HDMI3 monitor. Finally I disable all outputs except LVDS1. This puts me into my standard undocked state. From this known state I can then go into a docked state by enabling HDMI3. Disabling LVDS1, and setting up the output and activating my second monitor VGA1. I can then manually invoke the thinkpad-dock.sh script with the command line argument "remove" to undock, and "add" to dock. --- Additional comment from briemers on 2011-05-29 16:47:54 EDT --- Created attachment 501657 [details] script to authorize root to connect to the X server The next step to automating this is to add a gnome start-up script that allows root to connect to the display. I used gnome-session-properties to add the thinkpad-dock-auth.sh script to my gnome 3 start-up. --- Additional comment from briemers on 2011-05-29 16:54:16 EDT --- Created attachment 501658 [details] udev script to dock and undock The final step is to add a udev rule that activates the script for docking and undocking. What I did was 'udevadm monitor' to find a device that appears everytime I dock. Then I used 'udevadm info --path=... --attributes' to determine the relevant arguments to use in the rule. Of course the device found is going to depend on the exact hardware in use, so it is unlikely my rule will work without modification for anyone else. Once the rule is in place with relevant values, the 'udevadm control' call can be used to reload the rules. At that point the laptop should be able to dock and undock correctly to the respective docking station. --- Additional comment from uraeus on 2011-05-30 05:32:24 EDT --- Not sure this is the same bug, but after doing a yum upgrade this weekend my monitors go black once I try to plug my lenovo laptop into its docking station. If I just use console they keep working, but X seems completely unable to deal with the situation now. It used to work perfectly with FC14, and it worked with some manual configuration tweaking in FC15 until now. My laptop is a Lenovo x201i with built in Intel graphics. --- Additional comment from fhimpe on 2011-05-30 08:01:02 EDT --- This might be this upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=36082 --- Additional comment from briemers on 2011-05-30 08:10:00 EDT --- (In reply to comment #6) > This might be this upstream bug: > https://bugs.freedesktop.org/show_bug.cgi?id=36082 I haven't had problems suspending/resuming. But then as a matter of practice I don't do that very often, as pretty much any previous Fedora release has given me occasional failures resuming. --- Additional comment from briemers on 2011-05-30 08:12:55 EDT --- It seems timing is very important. If you examine my script you'll see there is a typo in the regular expression, so that it turns off outputs that are disconnected as well as those connected. When I tried correcting that the script did not work as well. About the only thing I can think of is that turning off the output for disconnected outputs adds enough delay so that the previous commands have time to take effect and at no time is more than 2 displays active.
Bill, I am sorry, but I am probably too dumb to get this. Could you please rewrite the issue in simple form: 1) what did you do? 2) what did you expect? 3) what should happen? I am sorry for asking for one more needinfo, but I got really lost while reading your story. Thank you
OK. There are multiple scenarios. Lets start with a fairly simple one: Scenario A: (HDMI3 is off, LVDS1 is primary, VGA1 is off) 1) what did you do xrandr --newmode "1280x1024_75" 138.75 1280 1368 1504 1728 1024 1027 1034 1 072 -hsync +vsync xrandr --addmode VGA1 "1280x1024_75" xrandr --output HDMI3 --primary 2) what did you expect to happen I expected the same results as he previous version of Xrandr. LVDS1 is off, VGA1 is secondary, HDMI3 is primary. 3) what should happen Perhaps neither the old or he current behavoir is correct. Probably what should happen is the final command in this sequence xrandr --output HDM3 --primary should return an error that all graphics heads are in use, and LVDS1 should continue as primary. 4) what did happen Displays LVDS1 and HDMI3 both went black. Display VGA1 continued to display but was non-responsive. e.g. I could not move a mouse cursor into the screen or such. In the case where these commands were in the GNOME default init, I had a gdm login on the blank display. I was able to enter my password and login, desplite the blank display. Scenario B: (LVDS1 is primary, VGA1 is off, HDMI3 is off) 1) What did you do? xrandr --output HDMI3 --mode "1280x1024" xrandr --output LVDS1 --off 2) what did you expect to happen My laptop display LVDS1 to be off, and my HDMI3 display to be on. 3) what should happen Exactly what I describe. 4) what did happen The command xrandr --output LVDS1 --off failed. Apparently the primary display cannot be disabled without first assigning a new primary display. Scenario C: (HDMI3 is primary, VGA1 is secondary, LVDS1 is off) 1) what did you do? xrandr --output VGA1 --off;xrandr --output LVDS1 --primary 2) what did you expect to happen Display VGA1 disabled, display LVDS1 enabled as primary. Display HDMI3 still displaying as well. 3) what should happen Good question. I would expect what I described, or perhaps an error message if I am overlooking something. 4) what did happen Display VGA1 disabled. Display LVDS1 remained disabled. Display HDMI3 was still primary. There are of course many more scenarios. Ultimately, the net result is the only way to use the current version of xrandr is to completely micromanage. To know exactly what your hardware is capable of. (e.g. How many graphics heads.) Be aware of the current state before assigning a new one... And to put sleep statements or other delays to allow the state to settle, so commands never execute during the "adjustment" period, which can result in using too many graphics heads being used at once.
OK, I will pass the bug to developers, but I guess /var/log/Xorg.0.log and /var/log/messages after these exercises would help us to understand what's going on. Thank you.
It's always safest to use ALL --output instructions together with a SINGLE xrandr call. This is the only way that is demonstrated in the man page for multiple --output's. You want xrandr to read your mind, remember your last command, and even guess what xrandr call will be next. This ain't ever gonna work. Use a single xrandr call! For example: xrandr --output HDMI3 --mode "1280x1024" --output LVDS1 --off This is only a bug if this does not work. I'm sure it will.
Thank you Alexei, good point. Reporter, can you retest this command, please?
Alexei, no combining the commands does not work. The result of this particular combination is that all displays go black and remain that way.
There seems to need to be a modest time delay between commands.
Hi Bill, just wanted to say thanks for following up on this bug. I have to admit that I thought it was dead and forgotten already. Haven't been using my docking station monitor ever since I upgraded to Fedora 15, so this issue is frustrating me a lot.
Sorry, it has been a while since I tried these scenarios. My last yum update pulled in approximately 400 updated packages, including xrandr alternatives. I tried all the above scenarios again, both with them combined on one line as you suggested, and in the original multiline format I reported, and they all work!!! The only scenarios that still are not working is when I have two displays active. e.g. If I have VGA1 active, LVDS1 active, and HDMI3 inactive then I get the following: $ xrandr --output HDMI3 --mode "1280x1024" --output LVDS1 --off xrandr: cannot find crtc for output HDMI3 This error message seems new, and is a big improvement over the prior behaviour where it left my display in a valid state. The following does work in that scenario: $ xrandr --output LVDS1 --off; xrandr --output HDMI3 --mode "1280x1024" Again, this is improvement, as previously this would not work without an additional delay like: $ xrandr --output LVDS1 --off; sleep 0.5; xrandr --output HDMI3 --mode "1280x1024"
> This error message seems new, and is a big improvement over the prior behaviour where it left my display in a valid state. This should have read: This error message seems new, and is a big improvement over the prior behaviour where it left my display in a invalid state. While it would be nice to be able to do the scenario I described that returns an error message, I do not consider that in anyway essential. Since all the scenarios I originally reported have been fixed, I would not mind if this ticket is close this as fixed upstream.
Thank you for letting us know.