Bug 709036

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.