Here is my current configuration: Laptop: Thinkpad T60, with a 1400x1050 screen (4:3), ATI X1400 videocard Home external monitor: Dell S2409W with 1920x1080 resolution (16:9) Work external monitor: HP LP2065 with a 1600x1200 resolution (4:3) Summary: If I start in one location (say, work) using the external monitor, and then come home and try to connect to the other external monitor, it generally requires an X restart. The data below was collected using Kubuntu Lucid, but this problem first started with Karmic and is still present (in some form or another) in the Maverick daily live CD as of 2010-08-26 containing X version 7.5. Suppose I start X with my work monitor connected, and then come home. Then $ xrandr --auto causes the home monitor to become activated (under Lucid; this appears to be an improvement over Karmic, see the Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/476357). However, the resolutions are all wrong: $ xrandr 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) If I try this: $ xrandr --auto --output VGA-0 --mode 1920x1080 xrandr: cannot find mode 1920x1080 Note the physical size of VGA-0 appears correct, it just doesn't get the full set of modes. I'm pretty certain that trying this with the Maverick alpha live CD (X version 7.5) in the opposite direction (home->work) yielded the following error: xrandr: cannot find crtc for output DVI-0 and the monitor did not even activate. I'm happy to submit whatever logs you require, please specify what files you need and which version you want me to run under (e.g., my harddrive-installed Lucid or from a live CD). Note that the Ubuntu bug report I linked to above contains some logs dating back to the version of X in Karmic. Also please understand I can test this only at times when I'm transitioning from home to work or vice versa.
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.