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.
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.
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.
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.
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.
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.
This might be this upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=36082
(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.
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.
*** Bug 709028 has been marked as a duplicate of this bug. ***
Try a single command with a sequence of multiple --output options instead of multiple calls. This is encouraged and examplified in the man page. Whether it is appropriate for multiple xrandr calls to restore some hidden defaults (or turns some outputs back on) is a philosophical question. It just does it and you see some strange behavior. A single command does not have this problem neither philosophically nor practically. Re: bug 699024
FWIW, I have the exact same problem. I have a Thinkpad T510. However, unlike Bill I had the exact same problem with F14 also, undocking/docking in F14 failed just as badly for me as it does in F15. That was part of the reason I upgraded, unfortunately it didn't help :) Bill, since my hardware might be close enough to yours for your workaround to work for me, could you post it? (Or email it to me?)
Jeff Weiss, just try editing the attached scripts. I recommend first tuning the settings in the docking script to work with your monitors. Start off with you laptop docked. You can then invoke the script with the commandline options "add" and "remove" simulate docking and undocking respectively. For the udev trigger, I think the USB device I am triggering on, is the USB HUB built into one of my DELL monitors. Although, it could be a hub built into the docking station. I'm not certain. Unless you have the exact same hardware, you'll probably need to use the steps I describe in comment 4 to find an appropriate device to trigger on and adjust the trigger. At some point I will probably take the time to generalize the solution. The thinkpad_acpi driver is dropping the key events on the floor, once that is fixed then the docking/undocking could be run from an /etc/acpi event, bypassing the need to authorize root and the udev trigger. After that to generalize it further there really just need to be a way of restoring a previous xorg configuration with xrandr and there would be no need to hard code monitor configurations into the script.
Created attachment 504101 [details] example docking script For some reason the docking script stopped working correctly. Adding in sleep statements between some of the commands fixed it.
Still trying any silly trick in the book? Pause huh? Anything but the correct SINGLE xrandr call with MULTIPLE --outputs?
(In reply to comment #14) > Still trying any silly trick in the book? Pause huh? > > Anything but the correct SINGLE xrandr call with MULTIPLE --outputs? I never tried that. It isn't documented... I surprised even the xrandr developers didn't suggest that idea. Unfortunately it does not work as expected... e.g. My display was set to HDMI3 and VGA1. I issued the following command: xrandr --output HDMI3 --off --output LVDS1 --primary --output VGA1 --off The result is all displays went black. Likewise if my display is set to just LVDS1, the the following also fails: xrandr --output HDMI3 --primary --output LVDS1 --off --addmode VGA1 "1280x1024_75.00" --output VGA1 --mode "1280x1024_75.00" In this later case, HDMI3 and LVDS1 go black, and VGA1 is scrambled with strange artefacts as it flashes on and off. The reason is probably an issue of timing. xrandr does not seem to wait the --off options to take effect, so I temporarily end-up with Xorg trying to use more than two heads at once.
Quoting from the xrandr man page: "Multiple outputs may be modified at the same time by passing multiple --output options followed immediately by their corresponding modifying options." In fact the page never suggests splitting them up (unlike with --addmode). It could be a driver bug actually but definitely not xrandr. You should probably complain to the driver folks.
(In reply to comment #16) > Quoting from the xrandr man page: > > "Multiple outputs may be modified at the same time by passing multiple > --output > options followed immediately by their corresponding modifying options." > > In fact the page never suggests splitting them up (unlike with --addmode). > > It could be a driver bug actually but definitely not xrandr. > You should probably complain to the driver folks. You are right. It is in the manual page, and there is even a single example. Too bad it does not actually work. Since I have never seen the documentation for the calls xrandr it would be outside my scope to say if the bug is in xrandr or deeper. If the bug is deeper then it is probably best to clone a new bug that blocks this one, so once the underlying problem is solved it can then be verified that xrandr works correctly with the fix. For now is the fact is there is no layer that is checking how many heads are in use, so I really do not see a way to simplify the following logic with multiple outputs. 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 1072 -hsync +vsync xrandr --addmode VGA1 "1280x1024_75.00" xrandr --output VGA1 --mode "1280x1024_75.00" fi The first line is needed just to see if HDMI3 can be activated. Adding the primary line there seems to cause problems as the laptop display is at a different resolution and it seems to need to need time to settle on how to deal with the logical mapping before changing the primary. The next two line might be able to be combined... The newmode line also is acting as a delay to allow the LVDS1 to finish deactivating, so if I change the order there, it also does not work as expected. Even something simple like combining the last two lines does not work consistently: xrandr --addmode VGA1 "1280x1024_75.00" --output VGA1 --mode "1280x1024_75.00" Sometimes I get the correct display, sometimes my monitor pops up a message saying it does not support the mode being used. But if I do two separate lines it always works. This is actually the same results if I do the addmode line without the output line: xrandr --addmode VGA1 "1280x1024_75.00" I would think either somewhere some locking is needed to prevent race conditions, the application needs to poll for results, or there is an event it needs to wait for. But as I said, without looking at the API specifications and what the code actually does, it would be impossible for me to say which component either not implemented correctly, or has a flawed design.
Looks like there have been a fix upstream. While I still need customization to dock my laptop, I suspect my customizations can be greatly simplified.
This works fine for me in F-16 with a Dell Latitude e6410 and associated dock
For F-16, it sometimes works sometimes doesn't. My previous scripts that I wrote for F-15 are completely useless. Bill
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping