Results tagged “Xorg problems” from CLICK

My three-part series on how my Intel-graphics-equipped laptop lost X in the upgrade to Ubuntu 9.10 is a bit long.

If you just want to fix your computer, and by chance you are having the same problem as I, try this quick fix. It worked for me:

The problem is with kernel mode setting, which is causing X to die.

To test whether or not the fix works, when you get to the GRUB screen, hit esc to stop the boot, then go arrow down to the kernel boot line, type e to edit it and add the following to the end (or after the ro ... both work for me):

i915.modeset=0

Then type b to boot.

If your computer boots into Ubuntu 9.10 and you now have a working display, make this change permanent by adding that same line to the GRUB entries for Ubuntu permanently by using your sudo privileges to edit the GRUB configuration file, /boot/grub/menu.lst

Open the terminal and do the following:

$ sudo gedit /boot/grub/menu.lst

That will open GRUB's menu.lst file in the Gedit text editor.

Add this, again, either to the end of the kernel boot line for both the "regular" and "recovery" boot stanzas for the current Ubuntu kernel.

Here is what my "stanzas" now look like (excuse the skipped lines ... that's a CSS issue with this blog; keep the current line spacing in your menu.lst), with the additions in red type:

title      Ubuntu 9.10, kernel 2.6.31-14-generic
root      (hd0,2)
kernel      /boot/vmlinuz-2.6.31-14-generic root=UUID=dc3cf399-6b13-4704-80c5-0e02fe6cd364 ro quiet splash i915.modeset=0
initrd       /boot/initrd.img-2.6.31-14-generic
quiet

title      Ubuntu 9.10, kernel 2.6.31-14-generic (recovery mode)
root      (hd0,2)
kernel      /boot/vmlinuz-2.6.31-14-generic root=UUID=dc3cf399-6b13-4704-80c5-0e02fe6cd364 ro single i915.modeset=0
initrd      /boot/initrd.img-2.6.31-14-generic

Save the file in Gedit and close it. If this hack worked for you when you added it to GRUB during boot time, it should work for you automatically when you boot the machine again. It's a good hack because you can test it before you commit to it in /boot/grub/menu.lst.

Note: DON'T directly copy my menu.lst stanzas into your /boot/grub/menu.lst. Your UUID information will be different than mine, and wrong UUID numbers will render your system unusable. IF THE HACK WORKS WHEN YOU EDIT THE GRUB LINE DURING BOOT TIME, JUST ADD THE PORTIONS IN RED TO YOUR EXISTING BOOT STANZAS IN /BOOT/GRUB/MENU.LST.

Additional note: My graphics chip is the Intel 82830 CGC (aka Intel 830M)

Our story thus far: Xorg has been a pain in the you-know-where for my Intel-video-running laptops ever since Debian Lenny was still in Testing, and those problems have made everything from OpenBSD (and the rest of the BSDs, for that matter) to Ubuntu render video everywhere from unreliably to ... not at all.

Over the past many, many months, I've discovered fixes that worked for various releases of Debian (Lenny is good now), Slackware (I've tamed the 12.x series) and Ubuntu (I debugged xorg.conf for Jaunty with the live CD BEFORE installing it ...).

But things broke anew in the Ubuntu 9.04-9.10 upgrade. I thought I had the hack ready to roll for my Intel 82830 graphics chip. But said hack did not work.

I found a new hack with a quick bit of Googling. Now I'm running Ubuntu 9.10 with no xorg.conf file, and X is back. I won't yet say it's "better than ever," but it does work, and after a day or so of evaluation, I'll come back and see how things sit.

Here's how I did it:

I found the hack here. Testing the hack involved adding a boot parameter in GRUB, something which I'm a bit familiar with. But nonetheless, I did find this Ubuntu Wiki page helpful, even though in this case I want to turn this parameter off instead of on.

It all has to do with kernel mode setting.

To make X work, I escaped out of the boot process in GRUB, edited the boot line and added this to the end of that line:

i915.modeset=0

Once I booted with that i915.modeset=0 in my boot parameters, X worked and I was able to log in. I still had my "test" xorg.conf file active. But since it didn't do anything for me without this kernel mode setting, I decided to disable the configuration file by renaming it:

$ cd /etc/X11
$ sudo mv xorg.conf xorg.conf.910

Then I rebooted, and X worked just fine with this boot parameter and no xorg.conf file at all.

Now ... to make the kernel mode setting permanent, I went back to the Ubuntu Wiki.

I copied the following from that Wiki, modifying the setting, since we're turning this off rather than on:

Turn onoff kms in your kernel modules

1. To turn it onoff for one boot, in grub add the kernel parameter, i915.modeset=0, and boot.

2. Or, to turn it onoff permanently, create (if necessary) /etc/modprobe.d/i915-kms.conf with this line:

options i915 modeset=0

and then reboot. If there are problems, you can turn it off via the kernel option nomodeset.

"If there are problems." There won't be any stinkin' problems, I thought. This is going to work.

It did not work. Just like the user in the Ubuntu Forums post, I instead needed to permanently add i915.modeset=0 to my boot parameters in GRUB.

So I did just that.

$ sudo gedit /boot/grub/menu.lst

Then I added i915.modeset=0 to the end of the "kernel" line in both the "regular" and "recovery mode" portions of the kernel 2.6.31-14-generic areas of /boot/grub/menu.lst.

Now I have a working Ubuntu system once again. Thankfully I did this all in a single day (the helpful Ubuntu Forums post was only 12 hours old when I discovered it).

I'm used to mucking around in xorg.conf (and am damn glad I don't need one with this version of Ubuntu), just as I'm used to screwing with /boot/grub/menu.lst to make things work.

But in Ubuntu Linux, of all the operating systems out there, and with an in-place upgrade to the current distribution, and with a subset of video chips (Intel) that is problematic yet widely used, this is a total and complete deal-breaker for all but the most "Hardy" (pun intended) users.

The Linux geek who has encountered X issues before can muddle through this.

But a new user, a recent user, a "non-technical" user will most likely conclude that Ubuntu in particular, Linux in general (but perhaps not Xorg, which seems to be the real culprit here, or is it the Intel drivers?) and the whole not-Windows-or-Mac world is just not ready for them.

I don't mean to be reactionary here. Yeah, I thought I had the problem solved with a couple of hacks, but I had to find a third and fourth hack, adopting one and rejecting the other, in order to make what was a working system work once again. And yes, I made relatively quick work of it. But I consider that quickness a bit of luck. Nothing more.

If I had a 9.10 CD, which I don't (my CD drive is very flaky when it comes to CD-Rs, and I haven't yet sprung for the 5-for-$10 offer for Ubuntu CDs that is replacing the free ShipIt program), with which I could have tested this in a live CD environment as I did for 9.04. But I didn't have that CD (burning my own would've probably resulted in a coaster, at least for the laptop it was intended to test).

Whether or not the seeming end of the free-CD distribution from Canonical via ShipIt is an acknowledgment that Ubuntu is focusing on the already converted and abandoning the true newbie is the subject of another entry. Fresh from this X disaster, whether it's Ubuntu's fault, Xorg's or Intel's, I do have a working system, but the level of geekery involved is not in keeping with Ubuntu's "Linux for Human Beings" tag line.

Disclaimer: I'm not exactly sure about what is going on with the free shipping of Ubuntu discs to those who request it via ShipIt. The change in policy, which I can't quite figure out, was announced in this Jono Bacon blog post. Personally, I'd use OSdisc.com to get a single CDDVD for $5.95 (or CD for $1.95 &ndash go OSDisc.com!) if I couldn't burn my own, but I think the policy of limiting free Ubuntu CDs to LoCos and other "members of the tribe," as it were is a dangerous thing for Canonical to be doing at this point in time. I personally don't mind purchasing CDs directly from Canonical and probably will do so in the near future. But the ShipIt program, to me, is what makes Ubuntu different than the other 300 or so distros out there (although I'm sure Fedora will send out free CDs to those who ask for them; but Fedora — in my opinion anyway — doesn't have the commitments both to newbies and to the desktop that Ubuntu at least appears to have.

Maybe the overall wonderfulness of Ubuntu 9.10 will bring a restored sense of hope. I worried about breakage in the 9.04-9.10 transition, and breakage I got. All is well for the moment, but I can see 49 out of 50 users with my problem giving up before solving it.

Bottom line: This should be taken care of in the install/upgrade process. And whether it's Xorg or Intel that is screwing up the graphics for these "older" chips, I'd just like to let each and every one of you know that it's been a time-sucking pain in the ass.

I'll leave on an up-note: If this hack helped you, please leave a comment on this post (or if you really, really don't want to sign in with one of the many, many kinds of accounts we use on this Movable Type blog, send me an e-mail). You can even gloat over having an Nvidia or ATI graphics chip and thus skirting this multi-year nightmare entirely. Also, feel free to school me on any "better" ways to fix this issue (and I am very much open to anything "better" than this bit of hackery). None of you have been shy about correcting me before; don't stop now.

The day after – analysis: I've had the night to think about just what is going on with this Toshiba Satellite 1100-S101 laptop, its Intel 82830 graphics chip, Xorg, the Intel drivers and kernel mode setting.

Years of trouble with this graphics chip initially led me to believe that the issue I'm having with Ubuntu 9.10, Xorg 7.4 and Xserver 1.6.4 is caused by catastrophic regressions in support for a chip that worked fine back in the days of Debian Etch, Ubuntu Dapper and Slackware 11.

For a brief time I was able to run two systems — OpenBSD 4.4 and Ubuntu 8.04 — without an xorg.conf file.

Now I'm again running this Intel chip with no xorg.conf — not that the presence or absence of such a file is the sole determiner of "good" graphics. Good graphics are their own measure.

No, it seems to be the kernel mode setting in Karmic that is messing with my Intel 82830 video, and turning off this "feature" leaves me with as good an experience with X as I've ever had.

I just wish that somehow Xorg, the Linux kernel, the Ubuntu installer, or some other utility could recognize whether or not kernel mode setting will speed my boot or render the system totally unusable and configure accordingly. I haven't had to modify a boot parameter in GRUB in quite some time, and while it was easy for me, once again I don't think the new user of a very common graphics system should have to contend with this.

Whether it's the kernel developers, Xorg or Intel, I hope somebody can address this situation in future releases and at least give Linux a fighting chance on the desktops of those who aren't accustomed to the general level of hackery required to see something on their computer screen in the GUI.

Pulling the trigger on Ubuntu 9.10: An opera in three acts:

• Pulling the trigger on Ubuntu 9.10 upgrade, Part 1: Eyes wide open/shut
  
• Pulling the trigger on Ubuntu 9.10 upgrade, Part 2: Worst-case X scenario (no video)
  
• Pulling the trigger on Ubuntu 9.10 upgrade, Part 3: Bringing X back from the dead (and why, oh why didn't the installer just do this for me?)

When upgrading from Ubuntu 9.04 to 9.10 this morning, I purposefully did not make any changes to my "custom" xorg.conf. You know, the one that made my Intel video chip (82830, for those keeping score) work in Ubuntu 9.04.

Yes it used EXA acceleration and not UXA. But it worked in 9.04, and I was curious as to what the Ubuntu upgrade process would do about it.

Turns out, nothing.

Yes, post-upgrade, my Intel-video-equipped Toshiba Satellite 1100-S101 laptop has NO video in X. I can't even bring up a terminal outside of X, it's that messed up.

I knew this could happen. I pretty much think I know how to fix it. I haven't done that yet.

I used one of my Puppy Linux CDs that happens to work in the Toshiba's very touchy CD drive — version 2.16 (again submitted for those keeping score) — and at first I renamed my xorg.conf to xorg.conf.old and rebooted Ubuntu 9.10.

I wanted to see how Ubuntu 9.10 would deal with the Intel 82830 graphics chip with no xorg.conf file.

No change. No X. Time to pull out the UXA acceleration hack.

I got most of the code from this blog post by Ivan Kristianto, which I previously mentioned here.

I didn't do everything he suggested, but I did use this code for the "Device" section of xorg.conf (ignore the skipped lines ... it's a CSS issue in Movable Type):

Section "Device"
Identifier    "Configured Video Device"
Option        "AccelMethod"            "uxa"
Option        "EXAOptimizeMigration"        "true"
Option        "MigrationHeuristic"        "greedy"
# Option        "Tiling"            "true" # i8xx users: set to false
EndSection

As you can see, I didn't use the "Tiling" option, either true or false.

Well, X still didn't work. I thought I had this one in the proverbial bag.

And remember. I've been doing this for a couple of years. I've suffered through a lot of sub-par Intel video and numerous xorg.conf hacks. And I still couldn't get it to work.

So I turned to the world's oracle (not Oracle, capital O, but oracle, small o) — Google.

Would the vast Ubuntu user community have solved this issue already? Stay tuned for my next post to find out.

Pulling the trigger on Ubuntu 9.10: An opera in three acts:

• Pulling the trigger on Ubuntu 9.10 upgrade, Part 1: Eyes wide open/shut
  
• Pulling the trigger on Ubuntu 9.10 upgrade, Part 2: Worst-case X scenario (no video)
  
• Pulling the trigger on Ubuntu 9.10 upgrade, Part 3: Bringing X back from the dead (and why, oh why didn't the installer just do this for me?)

After finally figuring out how to make Xorg work in Debian Lenny (and presumably in Slackware 12.2 and ...), my new method didn't work in Ubuntu 9.04, and I was worried that my Intel 82830 CGC graphics chip would be left behind by Xorg (and by extension Linux and the BSDs and anything else that happens to use Xorg).

Here's what I did to get X working again in Debian Lenny. I added this line to the Device section of /etc/X11/xorg.conf:

Option          "AccelMethod"          "XAA"

But that didn't work in Ubuntu 9.04.

I tried various other suggestions, but nothing worked.

Then I came across this LinuxQuestions.org page, which had this suggestion specifically for the Intel 82830 CGC:

add these to the device section of /etc/X11/xorg.conf:

Option      "AccelMethod"   "EXA"
Option      "MigrationHeuristic" "greedy"

It works!

What's funny is that after following the link through from LinuxQuestions, it turns out this tip/hack comes from the very same thread from the Arch Linux forum that helped me the first time.

I consider this ArchLinux thread to be the best ... thread ... ever. I haven't yet taken the proverbial plunge and actually tried Arch Linux, but if ever a single forum thread would prompt me to move to a new distro, this is that thread.

Begin rant: But I'm also worried that your average new Linux user with 5-year-old Intel video hardware won't figure this out and will abandon Linux quickly as a result. I've been doing this for a couple of years now, and the solution wasn't so easy to find.

Very, very clearly, either the configuration utilities that are part of Xorg, or configuration utilities in the distributions themselves, have to somehow add these lines to xorg.conf or somehow compensate and not screw up X when this specific chipset comes up.

If you Googled your way here because you're having problems with your Intel video in Linux, add these two lines to your xorg.conf under the Device section, restart X (either by logging out or rebooting) and try it again. This fixed my Xorg problems and cleared the way for me to upgrade from Ubuntu 8.04 LTS to Ubuntu 9.04 — and to the next version of Debian, to Slackware 13.0 ... and just about everything else Unix-like out there on my 2002-era Toshiba 1100-S101 laptop (and probably on my Gateway Solo 1450 as well, but I'll have to test that with the live CD). And you can bet I'll be trying this with OpenBSD 4.5, too.

Final words: Xorg has been a mess for my Intel video-using laptops since Lenny was in Testing. It only got worse with the newer Xorg in Ubuntu 9.04. This fix to xorg.conf seems to solve the problem. I'm committed to using FOSS operating systems, but this is just another example of why Linux really isn't ready for the average user. In short, users shouldn't have to jump through hoops like this in order to get basic functionality.

I hope your visit to this page fixed your broken Intel video. If so (or not), either leave a comment below, or if you don't want to sign up for that, send me an e-mail at steven.rosenberg@dailynews.com.

I've written hundreds of posts about Debian, and maybe just as many about trouble I've had with my Intel-graphics-using laptops and screen artifacts in the X Window System graphical environment for Unix/Linux operating systems.

Now I've got a fresh, working Debian Lenny installation on a test machine and have solved the artifacts-in-X problem that has plagued me in Slackware and Debian (and a few other distros that escape me) for probably a year or more.

One of the hardest things I ever did in my Unix/Linux journey was give up Debian Lenny back in its Testing days when I couldn't solve the screen-artifact problem.

I worked for weeks, maybe months, hacking away at the problem, tweaking /etc/X11/xorg.conf any number of ways. But I could never solve it.

Among all the Linux distros I tried at the time (roughly all of 2008), only Ubuntu, it seems, was free of screen artifacts. And it was running without an xorg.conf.

Point of order: The screen-artifacts problem wasn't always a problem. I ran numerous distros on laptops with this Intel graphics chip in 2007, and it never happened. Debian Etch, CentOS 5, many, many Puppy Linuxes, Damn Small Linux, PCLinuxOS, Fedora. At one point in Debian Lenny's development, it started to happen. My conclusion at this point is that changes in Xorg, not in the OS itself, are responsible for the problem.

Further point of order: OpenBSD 4.4 also didn't have this problem. I wasn't so lucky in OpenBSD 4.5, where quitting X causes a segmentation fault and core dump. And the xorg.conf I generated with Xorg -configure in 4.5 crashed X entirely. To run it at all, I needed to use the xorg.conf I generated in the same way in 4.4. I don't think it's using the new intel driver in 4.5 vs. the old i810 driver in 4.4, but it very well could be.

Back to X artifacts in Linux: To attack/potentially solve the problem this time, instead of Googling my laptops' names (Gateway Solo 1450 or Toshiba 1100-S101) I instead Googled X artifacts and the graphics chip's name (which I got from running dmesg in a terminal), which is the Intel Corporation 82830 CGC.

I came up with this page from the Arch Linux forums, which gave this advice:

had this exact same problem. put:

Option          "AccelMethod"   "XAA"

into your xorg.conf in the Device section. should fix it!

That worked. After literally hundreds of changes in my own xorg.conf files on a half-dozen or more installs, adding this line to/etc/X11/xorg.conf in Debian Lenny solved my video-artifacts problem.

For me, this is huge. It's my Linux/Unix tip of the year for 2009. Even though there are still seven months left in the year, no tip can trump this one in my own personal FOSS world.

Back to Lenny: A full how-I-installed-Lenny post is forthcoming, but right now I'm in a test environment and will probably change a few things before I nail the tutorial down.

This time at least, I started with a minimal install of Etch and a Half (I'm having CD-reading issues with the Toshiba, and this is the only Debian CD it'll boot from; and I'm also having networking issues with Debian install CDs that are particular to the local network through which I connect to the Internet).

After the minimal install was done from the CD, I then upgraded (aptitude update, then aptitude upgrade, both at a root prompt), added Xfce and a few apps, then changed all references from Etch to Lenny in /etc/apt/sources.list, dist-upgraded to Lenny, added a Lenny kernel (the system didn't do this automatically), did another dist-upgrade, added some more apps, and got Flash and Java working in Iceweasel (the non-branded Debian build of Firefox).

Now I have a working machine that's doesn't quite sip memory like my identically configured (but now written-over) OpenBSD installation but is both faster than my favorite BSD as well as Ubuntu (yes, I know GNOME vs. Xfce isn't a fair fight).

Here's roughly what I have installed on the Lenny laptop:

OpenOffice 2.4
Iceweasel (Firefox w/o copyrighted names or graphics)
Icedove (Thunderbird w/o copyrighted names or graphics)
sudo (I consider it an essential utility, even on systems whose names aren't Ubuntu)
xfce4
xfce4-goodies
2.6.26 Lenny kernel
mtpaint (I'll get around to the GIMP at some point, but this small image editor does most of what I need)
Flash 10 (I used the .deb package from Adobe)
Java in Iceweasel (after adding contrib non-free to the repositories in /etc/apt/sources.list, I added the sun-java6-plugin)
CUPS
xpdf
menus (so I could use update-menus in the console)
GDM (makes it easier to run multiple window managers; unfortunately there's nothing in Debian like Slackware's excellent xwmconfig console utility)

I don't have the networkmanager app that usually runs in standard Debian with GNOME (and with every form of Ubuntu). I re-learned how to manage the network with config files (a lot different than in OpenBSD, that's for sure) and all network-manager-gnome did was screw things up — I couldn't get to it.

Either I'll get deeper into manual configuration in Linux (likely) and get a couple of NICs set up (wired and wireless), or I'll either figure out how to get the GNOME network manager to install (not as likely) or do a "standard" Debian desktop with GNOME and then add Xfce the next time I do an install (could happen).

As I and others have written before, Xfce in Debian is a whole lot lighter desktop than it is in Xubuntu. It's a bit harder to manage, but after the aforementioned six months using OpenBSD, I'm accustomed enough to using the terminal that I'm very happy to use Debian's excellent aptitude in the console/terminal to update and add/remove applications and really don't need Synaptic (which I could easily add).

As I also mention above, I started with the minimal install because I had problems with networking in the Debian installer (my network's problems, not Debian's), but the next time I do this, I'll probably select Xfce as my desktop either in the installer menu itself (if I can get a Lenny disc to boot) or at the boot line in the Etch and a Half installer (desktop=xfce, I believe the line is). My goal is to find a Lenny install disc (possibly the entire "disc 1" of either the GNOME or Xfce builds ...) that the Toshiba 1100-S101 will boot from. I've made them on various PCs and Macs, and it's hit or miss. The Toshiba will read the CDs, it just won't always (OK, will only seldom) boot from them.

Just to get all the GUI tools you might want in a pinch, it's probably a good idea to start with the "standard" GNOME desktop, but in this case I wanted to save disk space and keep the system lean.

As nice as it is to have Lenny back on one of my desktop systems (I haven't yet made the decision to replace Ubuntu 8.04 on my main production system, and despite all philosophical rants to the contrary, I'm sticking with it at present), it's even nicer to solve that X-artifacts problem that has kept me from using so many good systems for so long.

Helpful links for this install:

• Debian Lenny: Upgrade from previous releases (From the excellent Debian Lenny release notes)
• The Debian Menu System
• Arch Linux Forums: [solved] Intel Corporation 82830 CGC: Artifacts appear in X
• Debian Packages page

Debian Lenny — on this laptop anyway — just got the 2.6.26 kernel, along with X packages that, once again, have a chance of making Debian Lenny's ghosting problem go away when I run X.

Basically, I've concluded that for some reason the screen isn't properly refreshing during the course of the X session. (The hardware in question is a Gateway Solo 1450 with the Intel i810 video driver).

Lately I've been able to run xrefresh in a terminal and clear things up, but since this problem only exhibits itself in Debian Lenny and not in Debian Etch, Ubuntu, or anything else I've ever used on this laptop, I'd like to believe that said problem will somehow be miraculously solved, like the other half-dozen or more potential deal-breaking issues I've had with Debian Lenny over the course of its use on this PC.

What I'm saying is that after a whole lot of fiddling with xorg.conf, I can't seem to fix the problem myself, and I hope the fine Debian Developers out there will do it for me.

Once again, everything's looking good in my preliminary testing, but that optimism seems to fade rather quickly as things turn to their usual crap as the X session wears on.

As always, I'll report back when I know more.

Later: My X refresh problems continue as before.

I've been meaning to do a Debian Lenny install so I can see how X behaves in a fresh installation vs. my much-older Debian partition that began life as Etch and has seen many, many packages come and go.

First things first: The Desktop installation of Lenny will not fit in 3 GB. At least the download-and-install software portion wouldn't work in that amount of space when I selected Desktop during the "task select" portion of the Lenny install.

I didn't want to make my root partition any bigger than 3 GB, so I elected to do a Standard installation, which doesn't include X or a desktop environment, although I did notice a few X11-related packages sneaking in.

After the install, I used aptitude to add X, Fluxbox and a few apps.

I started with:

aptitude install xorg fluxbox

With that line, I don't think I would've needed to add xserver-xorg, which I believe is wholly contained in the xorg megapackage. (I'll have to check this out).

I added a few items to get me going:

aptitude install iceweasel ted geany

Since then (it's been 10 or so hours), I've removed X and Fluxbox, replaced X and brought in Xfce with:

# aptitude install xfce-desktop

I had plenty of space for that.

I've also pretty much found out that my problem with "ghosting" on the screen in X continues in this new installation. It's specific to Lenny; I haven't seen it in Etch or any other Linux distro. Sometimes running xrefresh in a terminal clears things up, usually not. I can't figure out what's going on (I'm no PC video or Xorg expert), and everything I've tried hasn't worked.

I need to keep Googling until I find someone with the same problem who's smarter than I am. Shouldn't take long, I hope.

I have three things to try:

1) Boot the 2.6.22 kernel instead of 2.6.25. I don't remember having this problem back when I first started running Lenny.

2) Modify GRUB's menu.lst, removing vga=771 from the kernel line. While searching for fixes, I found this Linux Questions thread, which suggests doing this. I've already modified menu.lst to see if this will work on the next boot.

3) Specify HorizSync and VertRefresh in xorg.conf. Currently these values are not set in the file. Perhaps spelling them out will affect the refresh rate.

Note: So far 1) and 2) all three haven't worked.

Further note: I'm cautiously ready to say that solution 3) HAS worked. I used the HorizSync and VertRefresh values that Puppy 3.01 autoconfigured for me, and so far X is behaving itself. I'll know for sure in a couple of days, but it looks like another Debian problem has been solved. Thanks, users and developers of Debian

Revised note: I did use the HorizSync and VertRefresh from Puppy, but it hasn't worked. Back to the drawing board.

Friday, Aug. 15 update: A new Intel video driver is coming into my Lenny installation right now. Could that help me? No help there, either.

I've talked for some time about the ghosting I get on the upper panel and in portions of Iceweasel/Firefox when using GNOME and Xfce in Debian Lenny.

All I have to do to make the problem go away is boot with the Xfce or Fluxbox window managers. It also doesn't happen with Debian Etch, an install of which I did yesterday. OK, I've seen the problem in Xfce, too ... and it seems related to X refresh.

So it's very possible that the problem I'm having isn't X- or driver-related, but something deep in the heart of GNOME.

I don't know if I'm the only one experiencing this problem, but I haven't been able to find any other reference to the problem, most likely because I'm not describing it in anywhere near the same way as anybody else.

A bunch of Xorg packages flowed into Lenny today, and I installed them. I'm still seeing some funky graphics in my "forward" arrow in Iceweasel, and sometime the little Web icon next to the Web page's name goes all green and opaque on me.

The problem with Iceweasel goes away if I drag the window so a portion goes off the screen. When it refreshes, all is well. The same happens when I mouse over icons in the upper GNOME panel. Of course it's hard to drag the upper GNOME panel off the screen, so areas with no icons or menus tend to stay funky.

So the problem has something to do with screen refresh. Perhaps an xorg.conf tweak will help me? Could the problem be somehow related to Iceweasel? (I've started running Epiphany to see how that affects the system.) I have no idea.

All I know is that I don't have the problem in Ubuntu, in Debian Etch, or in any other distro on this very same hardware.

And while I'm on the subject, compare /etc/X11/xorg.conf in Ubuntu Hardy with the same file on a Debian install. They look very, very different. Ubuntu's is much shorter. Autoconfiguration — or different apps/files — must be taking care of a whole lot more, given the short xorg.conf in Ubuntu.

I'm about to do a second install of Lenny on a free partition to see if a fresh installation takes care of the problem. I'm willing to break off /home into its own partition and reinstall Lenny since it works so much better on this laptop than Etch ever did. Aside from this nagging problem, of course.

This video issue and figuring out suspend/resume are pretty much the only things keeping Lenny from being as good as or better than Ubuntu Hardy on this machine. I'd like to say that I got Lenny to work better, but so far that hasn't happened.

I've tried LOTS of distributions, everything from Mandriva to PCLinuxOS to CentOS 5.2 and Fedora 9, and nothing except Ubuntu has working suspend/resume out of the box on this Gateway Solo 1450 (which comes up as "unknown" with s2ram at a console).

Just as I figured out how to control the CPU fan under ACPI, I'd love to have that same mastery over suspend/resume. If only ...

I realize that the whole Debian project ain't about me and my petty problems with my obscure hardware, but I'd like to see things working better. Maybe I'll do that reinstall and see how a fresh Lenny looks.