Bug 29852

Can you attach your xorg log, dmesg output, and the output of xrandr --verbose?  Does turning off the monitor between connections help?  e.g.,
xrandr --output VGA-0 --off
xrandr --output VGA-0 --auto

Created attachment 38301 [details]
dmesg output

Created attachment 38302 [details]
Xorg log

Created attachment 38303 [details]
xrandr output

Created attachment 38304 [details]
xsession-errors

Here are log files from the transition home->work with my Lucid install. In this case, I used the KDE configuration panel, which gave as an option the full resolution of my work monitor, but it failed to turn on the display. I then tried:
$ xrandr --auto
xrandr: cannot find crtc for output DVI-0

I should say with my Lucid install, I had to turn off KMS (due to horrible graphical glitches triggered by switching monitors). This seems not to be necessary with Maverick---thanks for the progress! If you need me to try with a newer kernel or Xorg, I can try the Maverick alpha live CD. But since you haven't (yet) asked for a specific version I tried what is easiest :-).

The next time I try the transition between home and work, I will test turning off the monitor first as you suggested. This time I wanted you to have the full error 
log.

Are the issues with KMS or UMS or both?  The files you attached are for UMS.  Also what versions exhibit which issues?

Like I said in my message, for Lucid I had to turn off KMS because it yielded such awful graphical glitches that I couldn't even interact with the computer. Should I try the Maverick live CD, where KMS seems to work better?

I should have also said: the answers to some of your questions were in my previous messages. To summarize:
Under Lucid (2.6.32 kernel, Xorg 7.5): with KMS, glitches are too serious to use. Under UMS, need to restart X when switching monitors.
Under Maverick live CD (2.6.35 kernel? I'm not booted into the live CD now so I am not sure, but that seems to be what it is): awful glitches gone when using KMS, but the bug I'm reporting here remains

Are you using VGA in one place and DVI in another?  Looks like DVI is currently connected in the xrandr output, but that VGA was connected previously.  The following will turn off VGA and free up the crtc for use with DVI:
xrandr --output VGA-0 -off
xrandr --output DVI-0 --auto

(In reply to comment #10)
> Are you using VGA in one place and DVI in another?  Looks like DVI is currently
> connected in the xrandr output, but that VGA was connected previously.  The
> following will turn off VGA and free up the crtc for use with DVI:
> xrandr --output VGA-0 -off
> xrandr --output DVI-0 --auto

typo, should be:
xrandr --output VGA-0 --off
xrandr --output DVI-0 --auto

(In reply to comment #11)
Your suggestion worked just handily, except that an additional call
$ xrandr --output LVDS --auto
was sometimes needed in order to get my laptop display resolution set properly. I will be using this in the future---thanks!

Let me ask: what should be done with this information? It seems that users should not have to manually turn off & on VGA/DVI at the command line. Is this something that needs a bug fix in xrandr? (I would think xrandr --auto should handle all of this automatically, though perhaps there are reasons that would not be a good idea.)

Or is it more of an issue for, e.g., the KDE and Gnome configuration GUIs? In my testing of different Maverick alpha CDs, neither of these desktop environments handled this switch correctly. I am happy to report a bug elsewhere if you can suggest the proper place to implement the fix.

For the record, this is not a driver bug, but part of the general common randr behavior.  When you unplug a monitor, randr doesn't turn it off unless you explicitly tell it to turn it off since you might have disconnected the the monitor temporarily to adjust a cable or maybe the projector came loose, etc. and you don't constantly want your desktop resizing or whatever when a cable comes loose.  Some logic could probably be put into the xrandr cli tool or the gui tools to explicitly disable monitors when a new monitor is connected to another output and an old monitor disappears and you only have a limited number of crtcs.

(In reply to comment #13)
> For the record, this is not a driver bug, but part of the general common randr
> behavior.  When you unplug a monitor, randr doesn't turn it off unless you
> explicitly tell it to turn it off since you might have disconnected the the
> monitor temporarily to adjust a cable or maybe the projector came loose, etc.
> and you don't constantly want your desktop resizing or whatever when a cable
> comes loose.

Thanks for the explanation, it helps me understand why this isn't done entirely automatically. However, because this issue has bitten me and several others I know, it seems like something more should be done than just me personally learning the properly cli incantations; for the sake of the larger community I'd like to see this resolved. So, can we discuss options?

1. Automatic handling: one scenario in which it seems like randr could safely turn a monitor off is if one disappears AND a new one appears, and there isn't a free crtc. (What sets the # of crtcs? Is that a hardware thing?) In that case you are going to have to pick one or the other anyway, because there aren't enough crtcs to drive all the displays, and so you might as well go with the one that is connected. So to a naive person like me, automation does not really seem to be such a hard problem, as long as it's done only with the right alignment of conditions.

2. If you think instead that the logic should go in the xrandr cli tool, to whom should I report that? By talking to you, am I already reporting to the right person? :-)

3. Finally, if it gets built into the xrandr cli tool, will that automatically cover KDE/Gnome, or do they need to work on their own implementations? I can go visit their bugzillas and make a report, but that would be silly if the real work needs to be done elsewhere anyway. Sorry to ask your help here, but I'm pretty naive about the architecture, and so would probably generate a lot of useless churn without some good guidance. Thanks for your help.

(In reply to comment #14)
> Thanks for the explanation, it helps me understand why this isn't done entirely
> automatically. However, because this issue has bitten me and several others I
> know, it seems like something more should be done than just me personally
> learning the properly cli incantations; for the sake of the larger community
> I'd like to see this resolved. So, can we discuss options?
> 
> 1. Automatic handling: one scenario in which it seems like randr could safely
> turn a monitor off is if one disappears AND a new one appears, and there isn't
> a free crtc. (What sets the # of crtcs? Is that a hardware thing?) In that case
> you are going to have to pick one or the other anyway, because there aren't
> enough crtcs to drive all the displays, and so you might as well go with the
> one that is connected. So to a naive person like me, automation does not really
> seem to be such a hard problem, as long as it's done only with the right
> alignment of conditions.

The number of crtcs (display controllers) is a hardware limit.  Picking the right conditions is the hard part :)

> 
> 2. If you think instead that the logic should go in the xrandr cli tool, to
> whom should I report that? By talking to you, am I already reporting to the
> right person? :-)
> 

File a bug under Product: xorg Component: App/xrandr.

> 3. Finally, if it gets built into the xrandr cli tool, will that automatically
> cover KDE/Gnome, or do they need to work on their own implementations? I can go
> visit their bugzillas and make a report, but that would be silly if the real
> work needs to be done elsewhere anyway. Sorry to ask your help here, but I'm
> pretty naive about the architecture, and so would probably generate a lot of
> useless churn without some good guidance. Thanks for your help.

Depends on the app.  I think most use libxrandr directly, so they would probably need similar logic.

Sorry to reopen this, but when I was testing your suggestions yesterday, I was switching between my work monitor (the HP) and a projector with maximum resolution of only 1024x768. Once I went home, and manually turned off DVI-0 with xrandr --output DVI-0 --off, then a new problem surfaced: the Dell's maximum resolution is not recognized. 
$ xrandr
Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1600 x 1600
VGA-0 connected (normal left inverted right x axis y axis)
   1280x1024      75.0     60.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   640x480        75.0     59.9  
   720x400        70.1  
LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 285mm x 214mm
   1400x1050      60.0*+   50.0  
   1280x1024      59.9     60.0  
   1280x960       59.9  
   1280x854       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1152x768       59.8  
   1024x768       60.0     59.9  
   800x600        60.3     59.9  
   640x480        59.9     59.4  
DVI-0 disconnected (normal left inverted right x axis y axis)
tim@diva:~/bin$ xrandr --output VGA-0 --mode 1920x1080
xrandr: cannot find mode 1920x1080

After some experimentation, I tried fixing it like this:
$ xrandr --newmode 1920x1080 $(cvt 1920 1080 | grep Modeline | tr -s ' ' | cut -d ' ' -f 3-13)
which changed the output of xrandr to:
Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1600 x 1600
VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 531mm x 298mm
   1280x1024      75.0*    60.0  
   1152x864       75.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   640x480        75.0     59.9  
   720x400        70.1  
LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 285mm x 214mm
   1400x1050      60.0*+   50.0  
   1280x1024      59.9     60.0  
   1280x960       59.9  
   1280x854       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1152x768       59.8  
   1024x768       60.0     59.9  
   800x600        60.3     59.9  
   640x480        59.9     59.4  
DVI-0 disconnected (normal left inverted right x axis y axis)
  1920x1080 (0xb51)  173.0MHz
        h: width  1920 start 2048 end 2248 total 2576 skew    0 clock   67.2KHz
        v: height 1080 start 1083 end 1088 total 1120           clock   60.0Hz

But then
$ xrandr --addmode VGA-0 1920x1080
$ $ xrandr --output VGA-0 --mode 1920x1080
xrandr: screen cannot be larger than 1600x1600 (desired size 1920x1080)

When I try to fix this, I get:
$ xrandr --fb 1920x1080
xrandr: screen cannot be larger than 1600x1600 (desired size 1920x1080)

However, a fresh X restart (which I'm about to do now :-) ) can drive this monitor at its native resolution.

This is a limitation of UMS.  Because there is no unified memory manager, you have to pre-allocate a large enough framebuffer for the maximum monitor you want to use when X starts.  So you either need to add a virtual line to the screen section of your xorg.conf to pre-allocate a larger framebuffer, or start X with the larger monitor attached, or use KMS.

Thanks again. Now that I am better-informed, I will re-test using the Maverick live CD where KMS works; if problems persist I will submit bug reports to the targets you suggested.

Filed bug reports:
https://bugs.freedesktop.org/show_bug.cgi?id=29929
https://bugs.kde.org/show_bug.cgi?id=249636