|
Description
Bob Beck
2005-01-20 09:07:51 UTC
Created attachment 1724 [details]
XOrg.0.log for this machine, from Bob Beck
Created attachment 1725 [details] [review] patch that fixes the suspend/resume issue I'm pretty sure this patch is not the real fix. It probably just hides the real problem. Advice from someone who understands this code better is needed. External output works for me on the X40 -- as for suspend/resume, it looks like it's a VBE mode switch issue (re-POSTing the card, or saving the VBE state and later restoring it around a resume) would help from that, but I just switch to a VT around a switch to S3, which works fine. (In reply to comment #3) > External output works for me on the X40 -- as for suspend/resume, it looks like > it's a VBE mode switch issue (re-POSTing the card, or saving the VBE state and > later restoring it around a resume) would help from that, but I just switch to a > VT around a switch to S3, which works fine. Switching virtual consoles clears the corrupted screen here on OpenBSD too, but that's not the point :) . Matthieu's patch does correct the suspend/resume issue but I share his suspicions. External output is definately hosed on mine, (see my Xorg.0.log which matthieu attached). (Something to note: I'm not running OpenBSD.) The problem here would be that no driver does proper power management, so you really need to do your own power management. We have a neat tool called 'vbetool' (which is Linux-specific, I'm afraid), which will dump and restore the VBE state on command, and also re-POST the graphics chip. One thing about your log is that it doesn't show an external display -- does 'Option "MonitorLayout" "CRT,LFP"' help? (In reply to comment #6) > One thing about your log is that it doesn't show an external display -- does > 'Option "MonitorLayout" "CRT,LFP"' help? Doesn't appear to. Behaviour seems to be the same either way. I *can* get X to appear on the external monitor if I switch to it as the console (text) mode, then start it via an xinit from there (with no display on the LCD). I'm going to follow this with two attachments, The first attachment here is the Xorg.0.log from using 'Option "MonitorLayout" "CRT,LFP"', when starting X on the lcd panel, (then attempting to switch on the external monitor with Fn-F7, and I get the black screen symptom. The second is with the same xorg.conf as above, by logging in on the system console, (with the lcd panel) switching to the extneral monitor with Fn-F7, and then starting X with xinit. The real problem here is taking a laptop with a presentation on the lcd, and then switching over to external to use a projector - I'm not trying to do two heads on a 12" laptop :) -Bob Created attachment 1750 [details]
Xorg.0.log.1, starting on my X40, xinit from the lcd panel.
Created attachment 1751 [details]
Xorg.0.log.2, starting X on my X40, from xinint after switching with fn-F7 to extrenal CRT
Just for your information, I also have the top inch of the screen garbled after I close then open the lid on my X40 with Fedora Core 3 / Xorg 6.8.1. After switching to a text virtual console and back, the display is fine again. Will a fix be included in 6.8.2 you think? Interestingly, doing "xrandr -s 0" also will clear the corruption, if that gives any hints. Alan, could you take a look at this one, please? Bob, from your logs you get this... (WW) I810(0): SetDisplayDevices call failed, writing config directly to SWF0 (WW) I810(0): Failed to switch to configured display devices during lid operation. That's a good place to start on fixing first. Can you check that you have the latest BIOS for the X40 ? Have you tried the current freedesktop.org CVS too ? I've also noticed you are not loading the agpgart module. Can you try to do that and see if it helps ? Oh, scratch that last item about agpgart. I see that OpenBSD doesn't have the right fixes to support ARGB cursor in it's agp module. Having looked at the logs. It's a little suspicious that OpenBSD is really registered for PM events properly. I don't have OpenBSD installed so couldn't comment furthur, but it's certainly worth putting some debug around there. Are we sure that this is a driver problem? Other people have reported similar problems with laptops using other video cards, for example Radeon: https://bugs.freedesktop.org/show_bug.cgi?id=2000 (In reply to comment #13) > Bob, from your logs you get this... > > (WW) I810(0): SetDisplayDevices call failed, writing config directly to SWF0 > (WW) I810(0): Failed to switch to configured display devices during lid > operation. > > That's a good place to start on fixing first. > > Can you check that you have the latest BIOS for the X40 ? > > Have you tried the current freedesktop.org CVS too ? Hi Alan, The Bios on my X40 is the latest and greatest from IBM. I flashed the little bugger before even thinking about starting this :) No, I have not tried the freedesktop.org CVS directly, this is the latest OpenBSD Current import of 6.8.2 by mattheiu, who wanted this reported here so he could get some help. (In reply to comment #18) > (In reply to comment #13) > > Bob, from your logs you get this... > > > > (WW) I810(0): SetDisplayDevices call failed, writing config directly to SWF0 > > (WW) I810(0): Failed to switch to configured display devices during lid This seems to be occuring when I do Fn-F7 to switch the display btw, not when I suspend or resume with the lid. Using a freshly virginal xinit, (build includes matthieu's patch in this bug) when I suspend and resume, all I see is: (II) PM Event received: Normal Resume System Then upon doing three Fn-F7's to attempt to switch the display to the external and then back, I see: (WW) I810(0): Detected possible lid operation, fixing up. (WW) I810(0): Extended BIOS function 0x5f64 failed. (WW) I810(0): SetDisplayDevices call failed, writing config directly to SWF0. (WW) I810(0): Failed to switch to configured display devices during lid operatio n. (II) I810(0): Display plane A is disabled and connected to Pipe A. (II) I810(0): Display plane B is disabled and connected to Pipe B. (II) I810(0): Enabling plane B. (II) I810(0): Display plane A is now disabled and connected to Pipe A. (II) I810(0): Display plane B is now enabled and connected to Pipe B. (II) I810(0): PIPEACONF is 0x80000000 (II) I810(0): PIPEBCONF is 0x80000000 (II) I810(0): Mode bandwidth is 47 Mpixel/s (II) I810(0): maxBandwidth is 1440 Mbyte/s, pipe bandwidths are 126 Mbyte/s, 0 M byte/s (II) I810(0): LFP compensation mode: 0x6 (WW) I810(0): Detected possible lid operation, fixing up. (II) I810(0): Display plane A is disabled and connected to Pipe A. (II) I810(0): Display plane B is enabled and connected to Pipe B. (II) I810(0): Enabling plane B. (II) I810(0): Display plane A is now disabled and connected to Pipe A. (II) I810(0): Display plane B is now enabled and connected to Pipe B. (II) I810(0): PIPEACONF is 0x80000000 (II) I810(0): PIPEBCONF is 0x80000000 (II) I810(0): Mode bandwidth is 47 Mpixel/s (II) I810(0): maxBandwidth is 1440 Mbyte/s, pipe bandwidths are 126 Mbyte/s, 0 M byte/s (II) I810(0): LFP compensation mode: 0x6 Not being too familiar with this code, should that Fn-F7 be a "lid event"? (I haven't touched the lid during that). -Bob Yes, it's a lid event. That's o.k. I've just sent you a driver that I've slightly modified with some debug. Can you check your email and let me know. i get slightly different results with the latest X.org merge on openbsd on my x40. suspend/resume works just fine and redraws the screen normally (although when it first comes up, it does have the scrambled bar across top, but the screen flashes to black and back to the normal display which is drawn correctly without the bar). switching to an external monitor via fn+f7 the first time (so external only, nothing on the x40) draws a proper screen. fn+f7 again (shared screen on the external and x40) draws it correctly on the x40, but the external monitor now has the scrambled bar at the top. i was using the patch which is attached to this bug before and it fixed the external monitor issue, but the build i'm using now has no patches. i will attach my Xorg.conf and Xorg.0.log Created attachment 1840 [details]
Xorg.0.log from joshua stein, suspend working, external monitor not working
Created attachment 1841 [details]
xorg.conf from joshua stein
Created attachment 1858 [details]
Binary driver
Attached is a new binary driver.
Let me know if there's any difference.
with your new driver, suspend/resume, hibernate/resume, and switching to a console and back work. displaying on an external monitor works, and switching back to view only on the internal lcd works, but trying to display on both does not work at all anymore. it just keeps swapping back and forth between the lcd only or the external only, it won't do both. the screen never gets corrupted between switching, though. i tried to upload the new Xorg.0.log but bugzilla kept giving me an application error, something about an error handling a multipart post. i will try again later. Created attachment 1882 [details]
Good known driver
This has been tested by jcs on his hardware and works. Can others test too ?
(In reply to comment #26) > Created an attachment (id=1882) [edit] > Good known driver > > This has been tested by jcs on his hardware and works. Can others test too ? This driver works for me too. Switching displays works. Fn+F4 works without problems whereas using apm(8) to suspend the system leaves the mouse pointer as black 64x64 block until it is moved out of the current window. Now this is a very minor problem. Last and least it seems that Fn+F7 seems to follow no clear rule what the next mode (LCD, CRT or both) is. -- Claudio Claudio - can you post a log ? the driver from attachment 1182 [details] [review] seems to work similar to openbsd's pre X.org driver with the patch from attachment 1725 [details] [review]. however, with the 'good known driver' I cannot use X without a config file (before i've been running without xorg.conf) and it seems that i need to turn off the hw-cursor: Option "SWcursor" "yes" Created attachment 1884 [details] xorg.conf for comment #29 I'm not quite sure what you mean by 'running without xorg.conf' - Didn't the file exist at all before ?? As for the use of swcursor, what happened for you to need to specify this option ? And apart from the swcursor problem, does the driver work for switching displays ? Are you sure you are running the latest BIOS for the X40 ? Oops, forget my last comment, I was testing the wrong driver. The 'good known driver' works fine here. I'm running without a xorg.conf file, so getconfig.pl creates a config file on the fly. Lid close, suspend and switching to the external VGA works. Using both the LCD and the external VGA works, too. Created attachment 1885 [details]
Upload cursor driver
Markus, Claudio,
As both of you suffered cursor problems. Can you try this driver ?
(In reply to comment #32) Oh, o.k. thanks for letting me know. the driver from comment #33 does not fix the cursor problems here. as soon as the cursor shape changes the cursor is ok, but e.g. after Fn-F7 the cursor shows 'random' bits sometimes I've put up my latest test driver at http://www.fairlite.demon.co.uk/intel.html for those who want to test it. Rather than keep adding attachments here. is anyone testing the drivers from comment #37 ? it seems that one of the drivers MD5 (latest2_i810_drv.o) = 457b35a06f2208481f38c3ac6162b941 MD5 (latest_i810_drv.o) = e85dfa7854bf8cf2294707a637ea0496 messed with my machine badly. now i cannot use any of the known working drivers (or the pre-X.org driver) on my machine, even after turning the machine off. I'm running the x40 bios version 1.14. Alan, is a source patch corresponding to your latest driver (or the one in attachement <https://bugs.freedesktop.org/attachment.cgi?id=1882> ?) available? We're approaching code freeze for OpenBSD 3.7, and we'd like to be able to ship an updated i810 driver in this release. Thanks for your help in solving this issue. Matthieu, I'm not convinced things are 100% yet, so I don't want to change things to add more bug reports on this. I'd like to get more feedback first. Can people here test my latest driver and report back. (In reply to comment #40) > Can people here test my latest driver and report back. I recently got an X40 (the new 1.4GHz model if it matters) so I can test now too. The latest driver seem to work almost ok for me. The only remaining problem is that the external VGA is using a mode with a vertical rate of 49.94Hz and a horizontal rate of 40.28kHz. This is too low for most of the video projectors I've seen. I've not been able to find out a way to force this to a 60Hz mode. I'm attaching my xorg.conf and Xorg.0.log files Created attachment 2232 [details]
log file
Created attachment 2233 [details]
xorg.conf from Matthieu Herrb
(In reply to comment #41) Matthieu, I expect you didn't want to do this for your monitorlayout "LFP,CRT+LFP" ??? I suspect you either wanted "CRT,LFP" or "NONE,CRT+LFP". If you wanted the first, then the Clone/CloneRefresh options are required. If you wanted the second then they are not required. I also suspect the reason of the 50Hz mode on your CRT is because that's what the BIOS is driving the LFP at that is also attached to Pipe B. The driver won't override that. So I suspect you really wanted "CRT,LFP" (In reply to comment #44) > (In reply to comment #41) > > Matthieu, > > I expect you didn't want to do this for your monitorlayout "LFP,CRT+LFP" ??? > > I suspect you either wanted "CRT,LFP" or "NONE,CRT+LFP". If you wanted the > first, then the Clone/CloneRefresh options are required. If you wanted the > second then they are not required. > > I also suspect the reason of the 50Hz mode on your CRT is because that's what > the BIOS is driving the LFP at that is also attached to Pipe B. The driver won't > override that. > > So I suspect you really wanted "CRT,LFP" Ok, this driver works with "CRT,LFP" and options "Clone" and "CloneRefresh". I tried an earlier version where this setting was not giving expected results. Now I get a clean 60Hz more on the external VGA. Created attachment 2239 [details]
log file for updated xorg.conf
Created attachment 2240 [details]
Updated xorg.conf from matthieu, for reference
Committed fixes to CVS. |
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.