Bug 487356

Summary: Could not switch monitor configuration (virtual size too small)
Product: [Fedora] Fedora Reporter: Felix Kaechele <felix>
Component: xorg-x11-drv-nouveauAssignee: Ben Skeggs <bskeggs>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: airlied, ajax, arxs, awilliam, bnocera, bskeggs, david, gene-redhat, gnomeuser, itamar, jforbes, matt, ondrejj, pbrobinson, pvtpuddin, rstrode, sander, thuforuk, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-17 03:13:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
xorg.log
none
jforbes xorg.conf with virtual set none

Description Felix Kaechele 2009-02-25 11:31:30 EST
Description of problem:
When cycling through the output modes (Fn+F7) on my ThinkPad T61p it gives me the message 

Could not switch the monitor configuration
required virtual size does not fit available size:
requested=(3200, 1200), minimum=(320, 200),
maximum=(1920, 1920)

whenever I reach the point at which the computer tries to enable the extension of the Desktop to the other screen. (Xinerama or whatever it's called nowadays)

Version-Release number of selected component (if applicable):
gnome-settings-daemon-2.25.90-2.fc11.x86_64
xorg-x11-drv-nouveau-0.0.12-5.20090224gitd91fc78.fc11.x86_64

How reproducible:
Always. Just cycle through output modes with Fn+F7.

Steps to Reproduce:
1. Cycle through output modes with Fn+F7 for about 4 times
2. Get the error message
  
Actual results:
Integrated screen stays at 1920x1200, external monitor stays off.

Expected results:
Both monitors are on and running at their native resolution.

Additional info:
1 internal LVDS Laptop Screen 1920x1200
1 external VGA TFT 1280x1024
Lenovo ThinkPad T61p with NVIDIA Quadro FX 570M and latest nouveau driver
Comment 1 Matěj Cepl 2009-03-02 05:49:00 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 David Nielsen 2009-03-02 16:35:52 EST
*** Bug 488084 has been marked as a duplicate of this bug. ***
Comment 3 David Nielsen 2009-03-02 16:38:58 EST
Created attachment 333789 [details]
xorg.log

I am seeing the same problem, attached is my xorg.log
Comment 4 Ben Skeggs 2009-03-02 16:50:11 EST
The driver doesn't currently support resizing the framebuffer, at startup enough space is allocated to cover the displays the X says are to be immediately activated and it's impossible to change afterwards.  This is being worked on, but unfortunately not ready yet.

Either adding an xorg.conf describing the display layout you desire, or adding a Virtual line large enough to cover the maximum size you want to use will allow you to resolve the problem in the meantime.  This link will help: http://wiki.debian.org/XStrikeForce/HowToRandR12
Comment 5 Ben Skeggs 2009-03-25 21:16:32 EDT
*** Bug 492176 has been marked as a duplicate of this bug. ***
Comment 6 Ben Skeggs 2009-03-26 18:39:52 EDT
*** Bug 492175 has been marked as a duplicate of this bug. ***
Comment 7 Ben Skeggs 2009-04-01 21:12:43 EDT
*** Bug 493504 has been marked as a duplicate of this bug. ***
Comment 8 Matthew Truch 2009-04-04 20:42:26 EDT
(In reply to comment #4)
> The driver doesn't currently support resizing the framebuffer, at startup
> enough space is allocated to cover the displays the X says are to be
> immediately activated and it's impossible to change afterwards.  This is being
> worked on, but unfortunately not ready yet.

Is there an estimated timeframe for this fix?  Or patches/packages that need beta-testing?
Comment 9 Justin M. Forbes 2009-04-05 22:44:55 EDT
After working with this a bit last week, I have noticed that nouveau also ignores the virtual line in xorg.conf, so this is not a valid workaround.  From my xorg.conf

Virtual    3360 1050

Though trying to unmirror two monitors gives the error:

required virtual size does not fit available size:
requested=(3360, 1050), minimum=(320, 200),
maximum=(1680, 1680)

Tested both with and without KMS enabled.
Comment 10 Itamar Reis Peixoto 2009-04-06 11:23:20 EDT
*** Bug 468265 has been marked as a duplicate of this bug. ***
Comment 11 Adam Williamson 2009-04-06 16:58:34 EDT
justin: can you attach your xorg.conf just so we can make sure it's set up right? though you may well be right, I've been suggesting this fix 'blind' (I can't test it as nouveau doesn't work on my hardware) and I don't know if Ben has actually confirmed that it does the job.
Comment 12 Justin M. Forbes 2009-04-06 17:12:29 EDT
Created attachment 338399 [details]
jforbes xorg.conf with virtual set

xorg.conf is attached.  I went back and forth with ajax on this earlier this week and we couldn't figure it out.  Of course changing the driver to nv makes this work, so the virtual line is correct, nouveau just seems to ignore it.  If you change the format to say virtual 3360x1050, it does choke, so it is at least reading the line as valid and simply ignoring the instruction.
Comment 13 Ben Skeggs 2009-04-06 18:01:56 EDT
Try moving the Virtual line into the Display subsection for depth 24 :)
Comment 14 Peter Robinson 2009-04-08 05:44:34 EDT
I'm seeing this as well. Use to work nicely without the Virtual line with the nv driver.
Comment 15 Sander Hoentjen 2009-04-08 07:12:02 EDT
(In reply to comment #13)
> Try moving the Virtual line into the Display subsection for depth 24 :)  

I have this same bug, and I can confirm having the Virtual line in the Display subsection is a good workaround.
Comment 16 Adam Williamson 2009-04-08 18:03:05 EDT
"I'm seeing this as well. Use to work nicely without the Virtual line with the
nv driver."

This I don't understand. AFAIK, nv was just a plain old RandR 1.1 driver - to get any real multihead action you'd need a custom config in xorg.conf. Ben, can you shed any light?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Ben Skeggs 2009-04-17 03:13:39 EDT
(In reply to comment #16)
> "I'm seeing this as well. Use to work nicely without the Virtual line with the
> nv driver."
> 
> This I don't understand. AFAIK, nv was just a plain old RandR 1.1 driver - to
> get any real multihead action you'd need a custom config in xorg.conf. Ben, can
> you shed any light?
nv's G80 support is randr 1.2, and there's a very crude framebuffer resize implemented which looks like it could very easily fail (and leave you with a corrupted screen if it does).

Anyhow, framebuffer resize is now implemented in nouveau as of xorg-x11-drv-nouveau-0.0.12-29.20090417gitfa2f111.fc11.
Comment 18 Bastien Nocera 2009-04-17 05:58:22 EDT
*** Bug 496123 has been marked as a duplicate of this bug. ***
Comment 19 Adam Williamson 2009-04-17 12:56:20 EDT
quick note, Ben - CURRENTRELEASE isn't a valid resolution for Fedora, in fact. use ERRATA for bugs fixed by updates to stable releases, and RAWHIDE for bugs fixed in Rawhide. Not a big deal :)

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers