Bug 9325

Summary: screen remains black w. xf86-video-intel-modesetting branch driver on 965G chipset
Product: xorg Reporter: Jens Stroebel <dr-xorg>
Component: Driver/intelAssignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: high    
Version: git   
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log w. modesetting driver
none
Xorg.log (w. modesetting commit 3fe802453a85183a69c36a098639895f49b17df1 )
none
Xorg.log working (modesetting, commit 60411bc4d0b3c53850c73b7246d5f7ed5c2d4084 ) none

Description Jens Stroebel 2006-12-13 03:27:45 UTC
I'm using a git-checked out Xorg tree (2006-12-08 15.42 CET).
On our boxen w. "ATI RV370 5B60 [Radeon X300 (PCIE)]", everything is fine.

On those with "Intel 82G965 graphics controller", the server is unable
to start up, complaining
############ master #################
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method.
(EE) I810(0): Set VBE Mode failed!
#####################################
(Motherboard ASUS P5B-vm, chipset 965G)

Last commit in my git log for the modesetting-checkout is
commit fde52de870c84821ab457e17634c334a10cf71ab

modesetting branch starts up the server, but screen remains dark except for
monitor message
##############################
Freq ungültig (Freq invalid)
HF: 22.76kHz
VF: 24.24Hz
##############################
After terminating the xserver, the screen remains unusable(dark) instead of
switching back to console.
Comment 1 Jens Stroebel 2006-12-13 03:28:39 UTC
Created attachment 8086 [details]
Xorg log w. modesetting driver
Comment 2 Keith Packard 2006-12-13 09:12:40 UTC
I think this should have been fixed by commit
9776f6c68b3cdd5585e58e677c1b1318d9aedaf4. You might try the current modesetting
tip and see if that helps at all. I note that the TV output is also enabled,
which I presume you don't have connected. I'll try to figure out why we are
mis-detecting the TV output.
Comment 3 Jens Stroebel 2006-12-13 09:51:34 UTC
(In reply to comment #2)
> I think this should have been fixed by commit
> 9776f6c68b3cdd5585e58e677c1b1318d9aedaf4. You might try the current modesetting
> tip and see if that helps at all. I note that the TV output is also enabled,
> which I presume you don't have connected. I'll try to figure out why we are
> mis-detecting the TV output.

1.) Unfortunately, the fresh checkout of modesetting shows the same behaviour...
2.) as mentioned in xorg-list 
    msg-id: <20061211173706.GA7750@lunaslave.lunalounge.net>
the problem (or a problem) also occurs when using the vesa driver, so I am not
completely sure what to make of it (..VideoBIOS peculiarity..?)
Comment 4 Jens Stroebel 2006-12-14 08:30:26 UTC
After my latest check-out
(last commit:
3fe802453a85183a69c36a098639895f49b17df1 )
the problem w. regards to
###
Frequenz ungültig (Frequency invalid)
###
persist; the display is sane and usable after terminating the xserver, though
(switches back to console sanely)
Additionally, I think the mis-detection of TV disappeared.
Comment 5 Jens Stroebel 2006-12-14 08:34:03 UTC
Created attachment 8103 [details]
Xorg.log (w. modesetting commit 3fe802453a85183a69c36a098639895f49b17df1 )
Comment 6 Jens Stroebel 2006-12-15 09:51:24 UTC
The latest checkout of ours (last commit:
60411bc4d0b3c53850c73b7246d5f7ed5c2d4084 ) solves the described bug.
Xserver runs fine, terminates cleanly.
It still resists tries to enable DRI ("Cannot support frame buffer stride > 8K >
 DRI"), though.

Nevertheless, a usable xserver; fine, fine, fine :)
Comment 7 Jens Stroebel 2006-12-15 09:54:41 UTC
Created attachment 8130 [details]
Xorg.log working (modesetting, commit 60411bc4d0b3c53850c73b7246d5f7ed5c2d4084 )

Xorg log - working Xserver, working i810 (modesetting), still refuses to DRI
Comment 8 Eric Anholt 2006-12-19 16:09:01 UTC
Submitter reported problem fixed.  (secondary problem also fixed today)

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.