| Summary: | [852GM] LVDS not detected, with 2.6.99 git | ||
|---|---|---|---|
| Product: | xorg | Reporter: | marijus <mo_kinky> |
| Component: | Driver/intel | Assignee: | Wang Zhenyu <zhenyu.z.wang> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | major | ||
| Priority: | medium | CC: | michael.fu, yakui.zhao |
| Version: | unspecified | Keywords: | regression |
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
marijus
2009-02-20 05:02:02 UTC
Created attachment 23131 [details]
xorg log with erreor
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. (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... Created attachment 23166 [details]
the good xorg log with 2.6.1 and "ModeDebug" "yes"
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
(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? 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
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.
Created attachment 23265 [details]
acpidump output
here is the output of: cat /proc/acpi/button/lid/*/* type: Lid Switch state: closed 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...
Created attachment 23274 [details]
picture of scrambled screen
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. 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... 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 #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... 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?:) Could you paste X log after DSDT fix with debug option on? ping? 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.
though with kernel 2.6.29-rc8 i still get the scrambled screen problem... (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. (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? (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! (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 michael, is it possible there is a mistake in the debug-patch (line 84 until end) which makes it work despite the fw bug? 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? (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. 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? Created attachment 23941 [details]
xorg.log with tiling disabled driver not patched - makes actually everything work
> > also tried the patch from bug# 18385 - makes no difference > sorry... typo... i mean bug# 18358 assign to zhenyu to not to do lid-based detect for 8xx platform - decreasing priority, since the detection failure is fw issue. 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.