Created attachment 5645 [details]
Xorg log.

I should mention that I was hitting:

https://bugs.freedesktop.org/show_bug.cgi?id=5443

.. and so my xorg-x11-server-Xorg has the call to ValidatePCI(); commented out.

This is a very fun log.  This is the first LVDS I've seen that does DDC -- the
fact that we DDC successfully makes me happy.  At first glance, we also appear
to be grabbing valid BIOS timing data out (it's got a shorter hblank, but I
don't expect this to be a problem).  These things make me happy.

What I'm guessing we're seeing here is that I'm botching the DPLL settings for
your high pixel clock.  I've seen this on my CRT on my desktop as well, and need
to track it down.

Eric,

Can you have a look at the information here

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198062

It appears to be DDC modeset issues in the i810 driver

Any update on this?  It's more serious (for me) now that the modesetting branch
is shipping in FC6; I don't have a workaround for working graphics other than
making sure to keep a pre-modesetting driver around.

Ah, the 1920x1200 panels are above the limits for a single LVDS channel.  This
will require a bit of experimenting to fix, probably.

I have the same problem on a 945GM laptop. I'd be glad to help if there is
anything I can do to speed up fixing this bug like testing experimental patches,
providing more information or anything like that.

I just pushed a fix (d51555fba4e57c059fd184c1e54822d7e5b62a2f) that may or may
not help.  Please update to the latest modesetting branch and try again.

If the latest modesetting branch has the same behavior, I think we'll need to
put an i830DumpRegs at the start of EnterVT so we can see what the BIOS is
setting these registers to to trigger dual-channel mode.  Even better might be
testing master (if it works for your panel) with airlied and mjg59's BIOS
tracer.  Hopefully we won't have to go there, though.

Created attachment 7738 [details]
Xorg log with current modesetting branch

I've just tried the current modesetting branch with xorg-server 1.1.1. While
the log looks a bit different, it still shows the same phenomena, i.e. just a
black screen. This is with a 945GM chipset and a 1920x1200 display.

Will add i830DumpRegs right now.

Created attachment 7739 [details]
Xorg log with regdump in EnterVT

Attached the log with regdump when switching from VESA framebuffer 1280x1024
mode to X - I don't know how to get higher resolutions with the VESA
framebuffer.

I have a i915GM card on a Toshiba with wxga lcd (1400x1050). This has worked fine using the i810 driver and 915resolution program. Lately I've gained access to a couple of external LCD's (1680x1050), one at home, one at work, and would like to set this up for dual head, preferably a X desktop or session on each (but this can wait).

First thing I tried was xinerama (as I hadn't read what it actually did). With a MonitorLayout of "CRT,LFP" it was able to set up both monitors with the correct resolution, but I got artifacts and missing area (as they weren't equally large).

I then dropped the xinerama, and ended up with 800x600 on the external monitor. Then I modded 915resolution to also put in 1680x1050, and now I got 1280x1024 on the external monitor (!). Searching the web, I found references to this modesetting branch, and decided to test it out.

Upon just replacing the driver in xorg.conf, I got not enough memory for framebuffer error. So I added a VideoRAM 65536 to both device sections, and now X started. The result was no image whatsoever on the primary laptop display (1400x1050), and a 1680x1050 KDM display on the external monitor. When I logged in, this immediately switched to 1280x1024. I tried to restart and fully disconnect the external, but I still couldn't get any picture on the laptop. Neither was I able to see any output from xorg, as I couldn't switch to any of the other tty's.

I will attach the xorg.conf used for these results, and the framebuffer messages. I wouldn't know what else to provide (or how to get it), so if you want more information, please tell me what to do :) Thanks!

Created attachment 8635 [details]
Showing too little videoram message

Created attachment 8636 [details]
the xorg.conf resulting in above results

Lars: your issues don't appear to be related to the original bug.  Please file a separate bug for your modesetting branch issues.

Jürg Billeter: Your bug seems to be unrelated to this one, since in your case the output is off.  If you're still experiencing your bug, please open a separate report.

Chris: Still wondering if I can get a log.  Just the current modesetting branch driver should be enough for debugging, with no code changes necessary.

(In reply to comment #15)
> Chris: Still wondering if I can get a log.  Just the current modesetting branch
> driver should be enough for debugging, with no code changes necessary.

Just tried with the latest Fedora Rawhide "intel" driver, which I believe tracks modesetting, and all works beautifully, coming up at the EDID resolution of 1920x1200.  My section of this bug can be marked closed.

I do see something weird but unrelated to this bug, which is:
(II) INTEL(0): Setting screen physical size to 650 x 406

This doesn't cause any problems until I try to run compiz, at which point my windows shrink and everything looks very strange.  So!  If the physical size problem is being looked at somewhere else, I think this bug can be closed.  If not, let me know and I'll file a new bug for it with complete logs.

Thanks!

Great!  I'm happy to have this noisy bug closed.  For the physical size issue, if you attach a new Xorg.0.log to a new bug with an actual measurement of your screen's physical size, we should be able to fix that up.

Created attachment 8885 [details]
log of X session that involved suspend/resume

Sorry to disappoint.  :)  Starting up X still works, but I just tried suspend/resume, and I see the strobing screen on resume.  Does the attached log help?

Thanks!

The bug priority was upgraded (P2->high) with the bugzilla configuration change.
I'm Changing the priority back to the normal one.
Sorry for the spam.

Can you try booting your system with the 'acpi_sleep=s3_bios' argument to see if that helps your suspend/resume case?

Chris, suspend/resume is another issue (actually it happens on many systems). Please open a seperate bug if you still have problem. I'm closing this bug.