LinuxQuestions.org - [SOLVED] Screen goes black on startup

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Screen goes black on startup (https://www.linuxquestions.org/questions/slackware-14/screen-goes-black-on-startup-892419/)

Screen goes black on startup

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?

Quote:

dmesg |grep drm
[ 11.481967] [drm] Initialized drm 1.1.0 20060810
[ 11.637941] [drm] MTRR allocation failed. Graphics performance may suffer.
[ 11.638352] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 11.638354] [drm] Driver supports precise vblank timestamp query.
[ 11.823780] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[ 11.838839] fbcon: inteldrmfb (fb0) is primary device
[ 11.975665] fb0: inteldrmfb frame buffer device
[ 11.976183] drm: registered panic notifier
[ 11.986652] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

dmesg |grep fb0
[ 0.000000] ACPI: HPET acffb000 00038 (v01 HP INSYDE 00000001 MSFT 01000013)
[ 1.251707] fbcon: VESA VGA (fb0) is primary device
[ 1.310925] fb0: VESA VGA frame buffer device
[ 11.838839] fbcon: inteldrmfb (fb0) is primary device
[ 11.975665] fb0: inteldrmfb frame buffer device

cat Xorg.0.log |grep driver
[ 270.768] X.Org XInput driver : 11.0
[ 270.772] (==) Matched intel as autoconfigured driver 0
[ 270.772] (==) Matched vesa as autoconfigured driver 1
[ 270.772] (==) Matched fbdev as autoconfigured driver 2
[ 270.772] (==) Assigned the driver to the xf86ConfigLayout
[ 270.773] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[ 270.773] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 270.795] (II) VESA: driver for VESA chipsets: vesa
[ 270.898] (II) Unloading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 270.898] (II) intel(0): [DRI2] DRI driver: i965
...

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.

Quote:

Originally Posted by business_kid (Post 4418850)

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 :-)

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.

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

Code:

acpi_backlight=vendor

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.