Bug 10673 - nouveau can't use a Dell 2001FP in 1600x1200 mode
Summary: nouveau can't use a Dell 2001FP in 1600x1200 mode
Status: RESOLVED WONTFIX
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: 7.2 (2007.02)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-18 07:57 UTC by a.freedesktop.5.cmetz
Modified: 2008-01-17 06:02 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description a.freedesktop.5.cmetz 2007-04-18 07:57:00 UTC
I have xorg 1.2.99.905 and drm/nouveau git as of the afternoon of 4/17.
I have a GF6800 and a Dell 2001FP.

With the old nv driver and also with nouveau, the driver insists on detecting the  panel size incorrectly as 1280x1024. Once it does that, it rejects the native 1600x1200 modeline as bigger than the panel. So the open drivers are limited on this device to 1280x1024 output. The NVidia proprietary driver works at 1600x1200 correctly without a peep.

The same display on a Radeon 9500 Pro with the radeon driver works without a peep also.

The long term best solution would be to figure out why this is being misdetected and correct that. A good short term solution would be to implement the "PanelSize" option in nouveau (see the radeon driver) to allow the user to override the detected panel size and force the driver to attempt to continue.

I remember from previous research that there was discussion of NVidia not implementing initialization of the CRTC for resolutions greater than 1280x1024 in the nv driver. So there might be a lot more work to do to get this 1600x1200 native panel to actually work than just convincing X to try to use that resolution.
Comment 1 Stephane Marchesin 2007-05-01 14:38:43 UTC
Reassigning bugs to the list.
Comment 2 Adam Jackson 2007-11-18 08:07:09 UTC
(In reply to comment #0)
> The long term best solution would be to figure out why this is being
> misdetected and correct that. A good short term solution would be to implement
> the "PanelSize" option in nouveau (see the radeon driver) to allow the user to
> override the detected panel size and force the driver to attempt to continue.

I've tried this, it doesn't work.

As far as I can tell, what actually happens with nv and nouveau on digital connections is that the "resolution" we set is really just the size of the framebuffer, which is then fed to an upscaler for scanout.  In other words, your panel is always scanning out whatever the BIOS set it to at init time, which defaults to 1280x1024 because that's nice and conservative.

The nvidia driver, we can assume, just goes ahead and bangs the output registers directly.

Experimentally, using RANDR to resize the screen is subjectively faster on nv than on, say, radeon.  This corroborates the above theory; you're not changing the signalling timings, so the monitor doesn't need to resync.
Comment 3 Maarten Maathuis 2007-11-18 08:15:08 UTC
These sort of issues should not exist in the randr-1.2 codepath (Option "Randr12" in the device section) of the driver.

This should work reasonably (for your generation of card), if not, then you may be asked for a mmio-trace of the nvidia binary, so i can figure out what's wrong.

nv indeed does not change the clocks for flatpanels (at all).

The randr-1.2 codepath of nouveau should detect the largest mode and bring that up.


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.