Bug 20230 - [852GM] LVDS not detected, with 2.6.99 git
Summary: [852GM] LVDS not detected, with 2.6.99 git
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2009-02-20 05:02 UTC by marijus
Modified: 2009-03-19 01:47 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
xorg log with erreor (13.00 KB, text/plain)
2009-02-20 05:06 UTC, marijus
no flags Details
the good xorg log with 2.6.1 and "ModeDebug" "yes" (65.40 KB, text/plain)
2009-02-21 13:18 UTC, marijus
no flags Details
please try the patch on your machine, thanks. (2.91 KB, text/plain)
2009-02-21 18:56 UTC, MaLing
no flags Details
xorg log with applied patch and "ModeDebug" "yes" 2.6.99 - git (125.15 KB, text/x-log)
2009-02-22 04:45 UTC, marijus
no flags Details
acpidump output (94.74 KB, text/plain)
2009-02-24 09:00 UTC, marijus
no flags Details
xorg log with driver 2.6.2 (79.42 KB, text/plain)
2009-02-24 15:30 UTC, marijus
no flags Details
picture of scrambled screen (343.78 KB, image/jpeg)
2009-02-24 16:01 UTC, marijus
no flags Details
try the custom DSDT (179.55 KB, patch)
2009-02-25 00:05 UTC, ykzhao
no flags Details | Splinter Review
Xorg.log (105.83 KB, text/plain)
2009-03-16 04:06 UTC, marijus
no flags Details
xorg.log with ssc for i85x patch (tiling not set) (85.25 KB, text/plain)
2009-03-16 17:41 UTC, marijus
no flags Details
xorg.log with tiling disabled driver not patched - makes actually everything work (103.32 KB, text/plain)
2009-03-16 17:43 UTC, marijus
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description marijus 2009-02-20 05:02:02 UTC
hello,

im getting this error with intel driver 2.6.99 git...
no problems with 2.6.0 or 2.6.1

im using ubuntu jaunty uptodate

regards!
marijus
Comment 1 marijus 2009-02-20 05:06:09 UTC
Created attachment 23131 [details]
xorg log with erreor
Comment 2 Gordon Jin 2009-02-21 03:38:01 UTC
This is a laptop with a local panel screen, right?

Could you attache the "good" log with 2.6.1? Please set "ModeDebug yes" in xorg.conf, according to http://intellinuxgraphics.org/how_to_report_bug.html.
Comment 3 marijus 2009-02-21 13:17:23 UTC
(In reply to comment #2)
> This is a laptop with a local panel screen, right?

yes 

> Could you attache the "good" log with 2.6.1? Please set "ModeDebug yes" in
> xorg.conf, according to http://intellinuxgraphics.org/how_to_report_bug.html.

the good xorg log with 2.6.1 and "ModeDebug yes" is attached...
Comment 4 marijus 2009-02-21 13:18:57 UTC
Created attachment 23166 [details]
the good xorg log with 2.6.1 and "ModeDebug" "yes"
Comment 5 MaLing 2009-02-21 18:56:59 UTC
Created attachment 23172 [details]
please try the patch on your machine, thanks.

hi marijus,
root cause is from detecting failure.
This is a debug patch, which can help us to narrow down the probelm, please try it on your machine.
After runing that, please upload the Xorg log file with Modedebug option on.

Thanks
Ma Ling
Comment 6 Michael Fu 2009-02-21 22:54:17 UTC
(In reply to comment #4)
> Created an attachment (id=23166) [details]
> the good xorg log with 2.6.1 and "ModeDebug" "yes"
> 

where is the xorg log for the bad case, with the modedebug turns on?
Comment 7 marijus 2009-02-22 04:45:58 UTC
Created attachment 23174 [details]
xorg log with applied patch and "ModeDebug" "yes" 2.6.99 - git

it is better now... i could log in and everything seems to work... 
just the screen looks like "scrambled eggs" and is not usable.

note: i also updated to libdrm 2.4.5
Comment 8 ykzhao 2009-02-24 01:11:59 UTC
Hi, Marijus
    Will you please attach the output of acpidump?
    It will be great if you can attach the output of /proc/acpi/button/lid/*/*
    The latest acpidump tool can be found in 
    http://www.lesswatts.org/projects/acpi/utilities.php

    Thanks.
Comment 9 marijus 2009-02-24 09:00:29 UTC
Created attachment 23265 [details]
acpidump output
Comment 10 marijus 2009-02-24 09:29:07 UTC
here is the output of: cat /proc/acpi/button/lid/*/*

type:                    Lid Switch
state:      closed
Comment 11 marijus 2009-02-24 15:30:04 UTC
Created attachment 23273 [details]
xorg log with driver 2.6.2

the 2.6.2 driver now produces the same scrambled screen as 2.6.99 git.
i tried to make a screenshot of it but to my surprise the screenshot looked like the good screen...
Comment 12 marijus 2009-02-24 16:01:53 UTC
Created attachment 23274 [details]
picture of scrambled screen
Comment 13 ykzhao 2009-02-25 00:05:08 UTC
Created attachment 23278 [details] [review]
try the custom DSDT

Hi, Marijus
    thanks for the acpidump.
    From the acpidump it seems that the initial LID state is incorrect. From the acpidump we know that the LID state will be updated by EC after close/open the LID. But the initial LID state is obtained from the NVS memory region.
    In such case the LVDS will be skipped.
     
    Will you please try the custom DSDT and see whether the problem still exists?
    How to use the custom DSDT can be found in 
     http://www.lesswatts.org/projects/acpi/faq.php

    Thanks.
Comment 14 Michael Fu 2009-02-25 05:15:57 UTC
marijus,

I think all effort so far will only address the issue why your LVDS screen not detected between the good and bad cases, but won't likely be helpful to the "screen scrambled" issue.

As you said it works in 2.6.0/1, I'm wonderring if you could help do a bi-sect using git? it'll help us to narrow down the reason why screen scrambled in short time...
Comment 15 marijus 2009-02-25 05:19:10 UTC
hi, tried the custom DSDT... didnt help the video problem...

here is the output of: cat /proc/acpi/button/lid/*/* with custom dsdt

type:                    Lid Switch
state:      open
Comment 16 marijus 2009-02-25 15:13:11 UTC
(In reply to comment #15)
> hi, tried the custom DSDT... didnt help the video problem...
> 
> here is the output of: cat /proc/acpi/button/lid/*/* with custom dsdt
> 
> type:                    Lid Switch
> state:      open
> 

(In reply to comment #14)
> marijus,
> 
> I think all effort so far will only address the issue why your LVDS screen not
> detected between the good and bad cases, but won't likely be helpful to the
> "screen scrambled" issue.
> 
> As you said it works in 2.6.0/1, I'm wonderring if you could help do a bi-sect
> using git? it'll help us to narrow down the reason why screen scrambled in
> short time...
> 

im afraid i dont know how to do that...
Comment 17 Michael Fu 2009-02-27 05:17:46 UTC
you could try 'man git-bisect' or google git bisect. It'll return some article of HOWTo and Tutorial... would you mind having a try?:)
Comment 18 Wang Zhenyu 2009-03-01 18:26:18 UTC
Could  you paste X log after DSDT fix with debug option on?
Comment 19 Wang Zhenyu 2009-03-12 09:01:22 UTC
ping?
Comment 20 marijus 2009-03-16 04:06:55 UTC
Created attachment 23908 [details]
Xorg.log

sorry for beeing absent so long time...

now... using uptodate libdrm-git and xf86-video-intel-git with the debug-patch applied everything works ok again...

without the debug-patch still no modes detected...

this is without the custom dsdt.
Comment 21 marijus 2009-03-16 05:35:10 UTC
though with kernel 2.6.29-rc8 i still get the scrambled screen problem...

Comment 22 Michael Fu 2009-03-16 06:04:34 UTC
(In reply to comment #20)
> Created an attachment (id=23908) [details]
> Xorg.log
> 
> sorry for beeing absent so long time...
> 
> now... using uptodate libdrm-git and xf86-video-intel-git with the debug-patch
> applied everything works ok again...
> 
> without the debug-patch still no modes detected...
> 
> this is without the custom dsdt.
> 

sigh, pretty much we are clear this is a fw bug, thus yakui work out a DSDT for you to try. DSDT will override part of your FW settings ( don't panic, won't flash your FW, but update the copy loaded into memory )....

the debug patch won't help at all to resolve your issue. I think scrambled screen goes away isn't really fixed. The patch in bug# 18358 comment# 22 is the real fix..

I don't see any valuable thing we can take away from this bug.
Comment 23 Michael Fu 2009-03-16 06:05:03 UTC
(In reply to comment #21)
> though with kernel 2.6.29-rc8 i still get the scrambled screen problem...
> 

are you using Kernel Mode Setting in the 29-rc8 kernel?
Comment 24 marijus 2009-03-16 06:52:44 UTC
(In reply to comment #23)
> (In reply to comment #21)
> > though with kernel 2.6.29-rc8 i still get the scrambled screen problem...
> > 
> 
> are you using Kernel Mode Setting in the 29-rc8 kernel?
> 

no kms!
Comment 25 marijus 2009-03-16 07:38:06 UTC
(In reply to comment #22)
> (In reply to comment #20)
> > Created an attachment (id=23908) [details] [details]
> > Xorg.log
> > 
> > sorry for beeing absent so long time...
> > 
> > now... using uptodate libdrm-git and xf86-video-intel-git with the debug-patch
> > applied everything works ok again...
> > 
> > without the debug-patch still no modes detected...
> > 
> > this is without the custom dsdt.
> > 
> 
> sigh, pretty much we are clear this is a fw bug, thus yakui work out a DSDT for
> you to try. DSDT will override part of your FW settings ( don't panic, won't
> flash your FW, but update the copy loaded into memory )....
> 
> the debug patch won't help at all to resolve your issue. I think scrambled
> screen goes away isn't really fixed. The patch in bug# 18358 comment# 22 is the
> real fix..
> 
> I don't see any valuable thing we can take away from this bug.
> 

well... i dont know what is going on... if

1. i build the driver from git: xorg.log error no valid modes found

2. i build the driver from git with the patch in bug# 18358 comment# 22: xorg.log error no valid modes found

3. i build the driver from git with the debug-patch: it works (with 2.6.28-9 kernel)

regarding the custom dsdt: i tried it and it with a custom build 2.6.29-rc and it didnt make any difference regarding the no valid modes found error
Comment 26 marijus 2009-03-16 09:22:22 UTC
michael,
is it possible there is a mistake in the debug-patch (line 84 until end) which makes it work despite the fw bug?
Comment 27 marijus 2009-03-16 14:20:17 UTC
ok... now i understand... sorry for beeing so slow...

the fw is reporting the wrong status of the lid open/close state. that's why the screen is not beeing recognized.

what i just found out is: if i trigger the lid-switch once, it starts to report the right open/close state. means if i close and open the lid before the xserver starts everything works well with 2.6.28 kernel.

cant build new kernel with custom DSDT atm because patch always freezes my system atm :( 


p.s.
should i open a new bug regarding the scrambled screen with 2.6.29 without kms?
Comment 28 Michael Fu 2009-03-16 15:56:30 UTC
(In reply to comment #27)
> ok... now i understand... sorry for beeing so slow...
> 
> the fw is reporting the wrong status of the lid open/close state. that's why
> the screen is not beeing recognized.
> 
> what i just found out is: if i trigger the lid-switch once, it starts to report
> the right open/close state. means if i close and open the lid before the
> xserver starts everything works well with 2.6.28 kernel.
> 

This sounds like a pretty often ACPI fw bug...

> cant build new kernel with custom DSDT atm because patch always freezes my
> system atm :( 
> 
> 
> p.s.
> should i open a new bug regarding the scrambled screen with 2.6.29 without kms?
> 

what if you applied the patch bug# in 18358 comment# 22, then close/open the lid before X start ( to make sure we can detect the screen )? pls attach the xorg.log.

If this doesn't work, pls open a new bug and we will close this one.. thanks.
Comment 29 marijus 2009-03-16 17:41:03 UTC
Created attachment 23940 [details]
xorg.log with ssc for i85x patch (tiling not set)

with 2.6.29-rc8 (no kms) now i found out if i set option "tiling" "no" in xorg.conf the screen becomes normal... with 2.6.99-git no patches applied...
with no option tiling set it is distorted (scrambled) like you can see in the picture...

also tried the patch from bug# 18385 - makes no difference

i dont think this two bugs are related because the distortion in my case is static... i guess if it would have something to do with refreshrate it would be flickering... right?

anyway... where do i report the acpi fw bug? so i dont have to close/open the lid on every boot?
Comment 30 marijus 2009-03-16 17:43:55 UTC
Created attachment 23941 [details]
xorg.log with tiling disabled driver not patched - makes actually everything work
Comment 31 marijus 2009-03-16 17:59:02 UTC
> 
> also tried the patch from bug# 18385 - makes no difference
> 

sorry... typo... i mean bug# 18358
Comment 32 Michael Fu 2009-03-16 20:28:04 UTC
assign to zhenyu to not to do lid-based detect for 8xx platform - 
Comment 33 Gordon Jin 2009-03-16 20:37:09 UTC
decreasing priority, since the detection failure is fw issue.
Comment 34 Wang Zhenyu 2009-03-19 01:47:16 UTC
Close this, as lid detect issue with your ACPI fw has been fixed. 


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.