Bug 6942

Summary: modesetting branch fails on i915GM.
Product: xorg Reporter: Chris Ball <chris-fdbugs>
Component: Driver/intelAssignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: j, jens.knutson, kdekorte, larsivar
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log.
none
Xorg log with current modesetting branch
none
Xorg log with regdump in EnterVT
none
Showing too little videoram message
none
the xorg.conf resulting in above results
none
log of X session that involved suspend/resume none

Description Chris Ball 2006-05-17 04:13:43 UTC
I see a strobing greyscale screen.  i810 driver works, intel driver doesn't.

Will attach log now.
Comment 1 Chris Ball 2006-05-17 04:19:50 UTC
Created attachment 5645 [details]
Xorg log.
Comment 2 Chris Ball 2006-05-17 04:22:36 UTC
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.
Comment 3 Eric Anholt 2006-05-17 04:32:39 UTC
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.
Comment 4 Kevin DeKorte 2006-07-21 09:39:08 UTC
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
Comment 5 Chris Ball 2006-07-25 22:56:59 UTC
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.
Comment 6 Eric Anholt 2006-10-24 11:51:15 UTC
Ah, the 1920x1200 panels are above the limits for a single LVDS channel.  This
will require a bit of experimenting to fix, probably.
Comment 7 Jürg Billeter 2006-10-24 12:28:17 UTC
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.
Comment 8 Eric Anholt 2006-11-10 14:48:00 UTC
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.
Comment 9 Jürg Billeter 2006-11-10 23:52:43 UTC
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.
Comment 10 Jürg Billeter 2006-11-11 00:08:02 UTC
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.
Comment 11 Lars Ivar Igesund 2007-02-08 09:11:32 UTC
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!
Comment 12 Lars Ivar Igesund 2007-02-08 09:12:28 UTC
Created attachment 8635 [details]
Showing too little videoram message
Comment 13 Lars Ivar Igesund 2007-02-08 09:13:17 UTC
Created attachment 8636 [details]
the xorg.conf resulting in above results
Comment 14 Eric Anholt 2007-02-09 10:42:47 UTC
Lars: your issues don't appear to be related to the original bug.  Please file a separate bug for your modesetting branch issues.
Comment 15 Eric Anholt 2007-02-26 16:30:03 UTC
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.
Comment 16 Chris Ball 2007-02-26 21:51:19 UTC
(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!
Comment 17 Eric Anholt 2007-02-27 00:19:29 UTC
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.
Comment 18 Chris Ball 2007-02-27 07:45:18 UTC
Created attachment 8885 [details]
log of X session that involved suspend/resume
Comment 19 Chris Ball 2007-02-27 07:45:46 UTC
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!
Comment 20 Gordon Jin 2007-03-14 19:25:56 UTC
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.
Comment 21 Jesse Barnes 2007-08-02 18:47:02 UTC
Can you try booting your system with the 'acpi_sleep=s3_bios' argument to see if that helps your suspend/resume case?
Comment 22 Gordon Jin 2007-08-07 02:19:27 UTC
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.

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.