Sorry folks for starting up another black screen thread.
HP laptop with Intel graphics, running Slackware current with a 2.6.38.7-smp kernel. Booting with the "nomodeset" kernel parm works but X gets stuck with a 1024x768 resolution. When booting without, the screen goes black after a few pages scroll by, just at the point where the console switches to a higher resolution.
Changing to a different console didn't help, so I blindly log on and type startx, and the screen comes back to life with KDE running at the higher 1366x768 resolution, I try a few apps, the webcam, suspend to RAM, resume, and everything is now working flawlessly so it doesn't look like an X issue.
At this point I can change to another console (or exit KDE altogether) and the screen is back on at the higher resolution. Looking at the X log and some dmesg output makes it seem that starting X possibly replaces, reloads or unloads a driver?
If this is the case, how can I prevent the conflicting driver from loading in the first place?

My guess (a wild one, based on the output) is that it doesn't like the VESA driver you're using with your framebuffer. I think that if you boot with "vga=normal" then it won't try to use the framebuffer, and hopefully it will play nicely.

As you may be able to tell, it has been a while since anything similar happened to me, so YMMV... Hope this helps,

I don't know if it is the problem, but with KMS enabled, you need to remove any vga= parameter from the kernel line.

My understanding is (on the reports of others) that Intel graphics suck. Whether they suck more or less than my ati graphics suck, we can test later.

I would take the approach of getting the framebuffer out of it, get vesa out, and run with the intel driver (i810, i915 or summat?). Kill kms on the boot line and in /etc/modprobe.d/intel.conf - search the net for the exact syntax. I take it you use X normally, so you don't actually need a vga console - let it do what it likes. We can try a suckability test then :-)

Thanks for the feedback. It turns out this wasn't much of a problem after all. Somehow the brightness is turned off completely as soon as the kernel's KMS stuff kicks in. All I had to do was press the laptop's brightness function key to restore it.
Would this be considered a graphics driver bug or a kernel bug?
Out of curiosity, I compiled and tested the 2.6.39.3 and 3.0-rc7 kernels and both displayed the same behavior.


KDE runs at an ugly resolution unfortunately without KMS, which is done by booting with the "nomodeset" parm. As for ATI vs. Intel cards "suckability" none of the few laptops with ATI cards I've dealt with recently had any problems with KMS or framebuffers etc.

1 members found this post helpful.

I'd marked this thread as Solved a while back, but found a better solution using this kernel parameter

1 members found this post helpful.

The latest upgrade in current to 3.10.5 seems to have solved this issue on my laptop.
The "acpi_backlight=vendor" kernel parameter workaround is no longer needed.