Older Intel chipsets are not well supported by -intel. In the case of i830M and i845 as examples, X starts but has a corrupt display. This is preventing Ubuntu from being able to fully deprecate the -i810 driver, because while these chipsets are old, they're still in use by many users we wish to support. Original bug report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/114331 == i830M == "When attempting to use the new xserver-xorg-video-intel on a Fujitsu Stylistic 4110P with i830 graphics, I receive screen corruption (blank screen with vertical or horizontal banding which corresponds roughly to currently displayed screen in brightness). The X server does not crash and appears to continue working whilst it fails to display correctly (in other words, it appears to be attempting to display the log-in prompt). xserver-xorg-video-i810 works correctly but I am trying to change over because it appears impossible to configure it to use more than 8m video memory and to support dual displays." xorg.conf: http://launchpadlibrarian.net/7613684/xorg.conf.20070512234640 Xorg.0.log: http://launchpadlibrarian.net/7613688/Xorg.0.log.old
Can you try with current driver git tip or xf86-video-intel-2.2-branch?
need hong's comments anything wrong from the log file...
Please try a newer driver version and attach the xorg log with option modedebug in the Device section of your xorg.conf turned on. Thanks, Hong
Bryce, would you please help bring the original bug reporter here for interaction with us? Or we will have to reject this bug...
That is disappointing. As you can see from https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/114331, I requested the original test current driver git tip on the 22nd when you asked, however I have not heard from Dirk in 3 months.
originally had this on bug 14066, moving to this thread as requested since i have the i830, not the 845 chipset, So, anyway, I have the i830 chipset on my laptop. With xorg-server version 1.4.0.90, I was getting visual corruption in Xorg. If I would restart Xorg, I would get a black screen with only the mouse pointer visible. Lastly, if I resumed with Tuxonice, the insides of windows would not render. Anyway, when I manually patched xorg-server 1.4.0.90 with the patch that was attached by Hong Liu to bug 14065, two out of three of my problems appear to be solved! The visual corruption appears to be less, but I have seen two things for the most part happen in general. Sometimes, there is a little corruption at the top of the screen (for top 3 or 4 rows of pixels evenly spaced whitish rectangles appear). it seems mostly limited to this area. if i switch desktops and go back, the corruption is gone. Second, I have only seen this once. there appears to be a dark 3 or 4 pixel band that goes across the screen. It is about an 1/8th up from the bottom of the screen and usually goes away when I switch to another desktop and back. So that patch seems to be going in the right direction, but is not 100% there yet. If you need any additional info like xorg.conf and Xorg.0.log from me, please let me know. Cheers, John
CORRECTION, the patch that Hong Liu had attached to bug 14066.
It seems we are one step closer to find the correct mode for you LVDS display. Would you please attach the xorg.conf and xorg log with option modedebug turned on? Thanks, Hong
Would you please try the following patch to see if anything is improved? It's against intel driver. diff --git a/src/i830_dvo.c b/src/i830_dvo.c index e6ff6af..e7342b0 100644 --- a/src/i830_dvo.c +++ b/src/i830_dvo.c @@ -83,7 +83,7 @@ struct _I830DVODriver i830_dvo_drivers[] = .type = I830_OUTPUT_DVO_LVDS, .modulename = "ivch", .fntablename = "ivch_methods", - .dvo_reg = DVOA, + .dvo_reg = DVOB, .address = 0x04, /* Might also be 0x44, 0x84, 0xc4 */ .symbols = ivch_symbols }, Thanks, Hong
Created attachment 14144 [details] xorg.conf from John Dorfman 02/04/07
Created attachment 14145 [details] Xorg.0.log - intel patch - xorg just restarted
Created attachment 14146 [details] Xorg.0.log - intel patch - linux rebooted
Created attachment 14147 [details] Xorg.0.log - no intel patch - xorg just restarted
Created attachment 14148 [details] Xorg.0.log - no intel patch - linux rebooted
So I tried the Intel driver patch and have some feedback. I am attaching my xorg.conf with the modedebug option on, and Xorg.0.log for 4 different cases. Case 1. patched xorg server from bug 14066, patched intel driver version 2.2.1_pre20080125 from above, restarted Xorg server Results: Xorg server restarted with black screen and a mouse pointer I was able to move. Case 2. patched xorg server from bug 14066, patched intel driver version 2.2.1_pre20080125 from above, rebooted linux to start Xorg Results: Before login, looks fine, but if I switch to a console, then back to Xorg, the screen is pretty much one color and will not refresh. If I login first, everything is fine except a little corruption appears mostly at the top sometimes. If I switch to the console and back, all the objects (not the background) are corrupted. Case 3. patched xorg server from bug 14066, NON-patched intel driver version 2.2.1_pre20080125, restarted Xorg server Results: Same as Case 1. NOTE that the black screen did NOT happen to me before when I first patched the the Xorg server. So I am not sure why it does not work now. Case 4. patched xorg server from bug 14066, NON-patched intel driver version 2.2.1_pre20080125, rebooted linux to start Xorg Results: Same as Case 2. In summary, it did not seem to help, and it looks like the improvements that I thought happened did not. I am not sure how that happened...
Thanks for your test reports! What is the laptop model you are using? Thanks, Hong
No problem, just trying to get the problem solved. :) My laptop is a Sony Vaio PCG-R505GC. Let me know if you need more info. Thanks, John
Does the old i810 driver work for you? If it works, would you please try it and then dump the registers when your display is working (use the intel_reg_dump tool in xf86-video-intel/src/reg_dump). Thanks, Hong
Yes, I think the old i810 driver worked for me. Basically, everything worked fine until I upgraded to the most recent major release of X.org (about 2 months ago I think). I specified my driver as "i810" in xorg.cong before the upgrade which I assume was the old i810 driver you are talking about. Of course, now my driver is specified as "intel" in xorg.conf. Also, attached is a text file with the dump of the registers. Hope that helps!
Created attachment 14303 [details] i830 registers dump from Sony Vaio PCG-R505GC
(In reply to comment #20) > Created an attachment (id=14303) [details] > i830 registers dump from Sony Vaio PCG-R505GC > What I mean is would you please dump the registers when you are using the i810 driver (not intel driver)? I am trying to find out whether the intel driver is doing something wrong compared with the i810 driver. Thanks, Hong
Hi Hong, Okay, I have some more data. There is a bug somewhere, but I am not sure if it is with the intel driver. Let me know what you think from the data. All the below data used xorg server 1.3 (downgraded from 1.4) and DirectFB 1.0.0 (downgraded from 1.1.1). Kernel used xf86-video-i810 or intel version Desktop tested Results 2.6.24 1.7.4 (i810) Gnome No video corruption, xorg does not refresh if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed 2.6.24 2.2.1_pre20080125 (intel) Gnome Same as above 2.6.24 1.7.4 (i810) E17 window frame does not render, didnt see corruption, but it usually happens in window frame, xorg does not refresh if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed 2.6.24 2.2.1_pre20080125 (intel) E17 window frame renders, but i do see a little video corruption sometimes as described in previous posts, xorg does not refresh if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed 2.6.19 1.7.4 (i810) Gnome No video corruption, xorg DOES refresh successfully if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed 2.6.19 2.2.1_pre20080125 (intel) Gnome Same as above 2.6.19 1.7.4 (i810) E17 window frame does not render, didnt see corruption, but it usually happens in window frame, xorg DOES refresh successfully if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed 2.6.19 2.2.1_pre20080125 (intel) E17 window frame renders, but i do see a little video corruption sometimes as described in previous posts, xorg DOES refresh successfully if switched away (ctrl+alt+F1) and back (ctrl+alt+F7) or hibernated and resumed Summary: It seems that Gnome never has video corruption, E17 (which I get from CVS) has video corruption or / (maybe) and no window frame rendering. Switching to an earlier kernel eliminates the refresh problem. I will post a intel video dump with the earlier 2.6.19 kernel and 1.7.4 i810 driver and another with the earlier 2.6.19 kernel and 2.2.1_pre20080125 intel driver
Created attachment 14370 [details] i830 dump with 2.6.19 kernel and i810 1.7.4 driver
Created attachment 14371 [details] i830 dump with 2.6.19 kernel and i810 2.2.1_pre20080125 driver
(In reply to comment #22) > Hi Hong, > > All the below data used xorg server 1.3 (downgraded from 1.4) and DirectFB > 1.0.0 (downgraded from 1.1.1). > Do you have the kernel fb module (intelfb) loaded? Please remove it before your testing. (grep "intelfb" in your dmesg log will give you the answer). > Summary: It seems that Gnome never has video corruption, E17 (which I get from > CVS) has video corruption or / (maybe) and no window frame rendering. So Gnome doesn't have problem with i810 and intel driver only when using xorg server 1.3? What about xorg server 1.4 with i810 and intel driver? Let's focus on your 1st problem here. With xorg server 1.4 + intel driver, display corrupts, while xorg server 1.4 + i810 works OK? If i810 has no problem, then please dump the registers (both i810 and intel for comparison). > Switching to an earlier kernel eliminates the refresh problem. What is the refresh problem you mentioned? X can't come back when switching VT? If so, please open a new bug about VT switch problem, and add the info you find (2.6.19 is OK while 2.6.24 isn't). Thanks, Hong
> Do you have the kernel fb module (intelfb) loaded? Please remove it before > your > testing. (grep "intelfb" in your dmesg log will give you the answer). In 2.6.19, I am using vesafb. newgallifrey johnd # ps -A | grep fb 758 ? 00:00:00 vesafb "dmesg | grep intelfb" turned up nothing In 2.6.24, I am using uvesafb (vesafb was not working so well anymore and it sounds like gentoo, the distro i use, are trying to steer toward uvesafb). newgallifrey linux # dmesg | grep fb Kernel command line: root=/dev/hda6 resume2=swap:/dev/hda8 pci=assign-busses video=uvesafb:ywrap,1024x768-16@60,nocrtc splash=verbose quiet CONSOLE=/dev/tty1 mapped APIC to ffffb000 (01403000) fixmap : 0xfffb5000 - 0xfffff000 ( 296 kB) vmalloc : 0xe0800000 - 0xfffb3000 ( 503 MB) uvesafb: Intel Corporation, Almador Graphics Controller, Hardware Version 0.0, OEM: Almador Graphics Chip Accelerated VGA BIOS, VBE v3.0 uvesafb: VBIOS/hardware doesn't support DDC transfers uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: redraw uvesafb: framebuffer at 0xe8000000, mapped to 0xe0880000, using 832k, total 832k fb0: VESA VGA frame buffer device ieee1394: Host added: ID:BUS[0-00:1023] GUID[080046030143f6fb] So no intelfb it appears. I choose the options in the kernels I compile, and I know I never used the intelfb, so that pretty much seems out. > So Gnome doesn't have problem with i810 and intel driver only when using > xorg server 1.3? > What about xorg server 1.4 with i810 and intel driver? Looks that way, but I have to double confirm with xorg server 1.4. It will take a little while to recompile stuff... Will let you know for sure. > Let's focus on your 1st problem here. With xorg server 1.4 + intel > driver, display corrupts, while xorg server 1.4 + i810 works OK? > If i810 has no problem, then please dump the registers (both i810 and > intel for comparison). Okay, and actually xorg server 1.4 + intel, display corrupts AND xorg server 1.4 + i810, display corrupts. that is why I downgraded to 1.3 to try that. This actually might be an E17 problem as I updated from 1.3 to 1.4 and updated E17 at the same time. Need to double confirm that Gnome is having problem with 1.4. I thought it was... QUESTION FOR YOU: Since I have Gentoo, shall I move to the latest stable packages? (easy for me, just issue command "emerge sync" to have latest packages available while updating back to 1.4? Or shall I just update back to the packages I was using when filing this bug? > What is the refresh problem you mentioned? X can't come back when > switching VT? > If so, please open a new bug about VT switch problem, and add the > info you find (2.6.19 is OK while 2.6.24 isn't). Well the X display comes back sort of. Basically, only the profile of stuff appears, so a terminal window might show up as just a off white rectangle, the task bar is a grey rectangle, etc. This happens in 2.6.19 too just for a second. Then the screen refreshes so the desktop looks normal while the 2.6.24 never refreshes and the display stays the same as it initially was. So, I will file a separate bug for this, but might wait a little to try to get this one resolved first. Thanks, John
(In reply to comment #26) > > Do you have the kernel fb module (intelfb) loaded? Please remove it before > > your > > testing. (grep "intelfb" in your dmesg log will give you the answer). > > In 2.6.19, I am using vesafb. > newgallifrey johnd # ps -A | grep fb > 758 ? 00:00:00 vesafb > > "dmesg | grep intelfb" turned up nothing > > In 2.6.24, I am using uvesafb (vesafb was not working so well anymore and it > sounds like gentoo, the distro i use, are trying to steer toward uvesafb). > Please remove any kernel framebuffer driver and re-test. pls see http://www.intellinuxgraphics.org/how_to_report_bug.html
(In reply to comment #26) > In 2.6.24, I am using uvesafb (vesafb was not working so well anymore and it > sounds like gentoo, the distro i use, are trying to steer toward uvesafb). > OK, please try to not load any kernel framebuffer module (since both kernel fb module and Xorg 2D intel driver are trying to programming the hardware without any knowledge of the existence of each other. This may cause problem). > QUESTION FOR YOU: Since I have Gentoo, shall I move to the latest stable > packages? (easy for me, just issue command "emerge sync" to have latest > packages available while updating back to 1.4? Or shall I just update back to > the packages I was using when filing this bug? I think you should try the lastest package (when I mean xorg sever 1.4, I am meaning the latest stable package you can get :) ) since we are all working on the latest git version. If you find a workable package, then it may help us to locate the bug by using git bisect to find which commit causes your problem. Thanks, Hong
>> In 2.6.24, I am using uvesafb (vesafb was not working so well anymore and it >> sounds like gentoo, the distro i use, are trying to steer toward uvesafb). >> > OK, please try to not load any kernel framebuffer module (since both kernel fb > module and Xorg 2D intel driver are trying to programming the hardware without > any knowledge of the existence of each other. This may cause problem). Okay, removing uvesafb eliminates the "lack of refresh" problem when switching to a terminal and back to Xorg or when hibernating with tuxonice and resuming! So I should file a separate bug for this on this site using the link to the guide for filing bugs that Michael Fu provided, correct? >> QUESTION FOR YOU: Since I have Gentoo, shall I move to the latest stable >> packages? (easy for me, just issue command "emerge sync" to have latest >> packages available while updating back to 1.4? Or shall I just update back to >> the packages I was using when filing this bug? > I think you should try the lastest package (when I mean xorg sever 1.4, I am > meaning the latest stable package you can get :) ) since we are all working on > the latest git version. > If you find a workable package, then it may help us to locate the bug by using > git bisect to find which commit causes your problem. Okay, I updated everything to the latest. I am running xorg-server 1.4.0.9, intel driver 2.2.0.90, Gnome 2.20.3, and the latest from E17 CVS from about 3 days ago. With that, I can confirm that I see no problems with Gnome except the occasional line of text in a terminal window goes blank and then will come back if I type more. Not sure if that is related to this at all. In E17, I eventually get some corruption (a little) on top after maybe 5-10 minutes. ( I am attaching a screenshot of this. ) Also, there can be a bit more for a second or two. (Am attaching another screenshot). This only happens every 10 hours, maybe. So let me know if you think this is related to the intel driver at all.
Created attachment 14606 [details] Screenshot in E17 with little corruption at top
Created attachment 14607 [details] Screenshot in E17 with more corruption at top It seems dragging large windows around makes this happen more often as I just found out.
(In reply to comment #29) > Okay, removing uvesafb eliminates the "lack of refresh" problem when switching > to a terminal and back to Xorg or when hibernating with tuxonice and resuming! > So I should file a separate bug for this on this site using the link to the > guide for filing bugs that Michael Fu provided, correct? Actually this is a known issue. We recommend users not to use any kernel framebuffer driver when using xorg 2d driver. > With that, I can confirm that I see no problems with Gnome except > the occasional line of text in a terminal window goes blank and then will come > back if I type more. Not sure if that is related to this at all. In E17, I > eventually get some corruption (a little) on top after maybe 5-10 minutes. ( I > am attaching a screenshot of this. ) Also, there can be a bit more for a > second or two. (Am attaching another screenshot). This only happens every 10 > hours, maybe. So let me know if you think this is related to the intel driver > at all. > I am not sure whether this is a driver bug. Zhenyu, What's your opinion (Is this EXA related)? Thanks, Hong
(In reply to comment #32) > Zhenyu, What's your opinion (Is this EXA related)? > To see if it's driver exa render related, we can use several driver options to try. - "NoAccel" to disable driver acceleration totally, see if this's software render issue. - "ExaNoComposite" to disable driver exa composite acceleration, see if composite operations cause problem. - "Tiling" to see if driver render acceleration has problem in handling tiled surfaces. - "AccelMethod" "XAA" not suggest, but just like "ExaNoComposite" to see if no render acceleration is ok.
okay, i will try these options out and let all of you know.
(In reply to comment #34) > okay, i will try these options out and let all of you know. > Hi, John, thanks for working closely with us. to make the bug fixing more efficiently, we want a bug to be focused on just one issue. if you find something wrong after you followed zhenyu's suggestion on testing, would you please kindly help to open a new bug ( thus we can have a more meaningful bug summary line )? I'll mark this bug as fixed for the screen flickering issue because of fb driver thanks.
hello, okay, fyi, it does look like exa is an issue, so i will file a separate bug for that. thanks for working through this bug with me as well!
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.