4010 - dock event for series 3 docking stations 4011 - undocking event for series 3 docking stations e.g. messages-20110530:May 30 07:56:35 docbill-think kernel: [14997.231617] thinkpad_acpi: unhandled HKEY event 0x4010 messages-20110530:May 30 07:56:35 docbill-think kernel: [14997.231620] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel.net messages-20110530:May 30 07:45:21 docbill-think kernel: [14324.758970] thinkpad_acpi: unhandled HKEY event 0x4011 messages-20110530:May 30 07:45:21 docbill-think kernel: [14324.758976] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel.net It would be really nice to have the events added, so the /etc/acpi/events could be used to control the display when docking and undocking my laptop. My current workaround is a udev trigger on a usb device. However, for that to work I had to first manually find a device to trigger on, and I had to modify my gnome 3 start-up to grant root permission to connect to the X server. Even then this still would not work properly if I were to use more than one display. +++ 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. --- Additional comment from briemers on 2011-05-30 09:06:12 EDT --- *** Bug 709028 has been marked as a duplicate of this bug. ***
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