mjhjmtu

I have a Dell Inspiron laptop with Gentoo and OpenRC. It has no trouble entering hibernation and suspend via gui or keyboard. It also restores normally.

I have configured xfce4-power-manager to put it to sleep and hibernation with lid event. And here comes the most fascinating thing: it wakes up as if normal, but its screen is black. It is completely black, it was simply not turned on upon waking up.

It looks like it is fine suspending and waking up from keyboard sleep button or via gui and in this case it properly switches the screen on, but with lid - it for some reason does not switch the screen on.

When this happens I can attach a monitor via HDMI and from it manually enable laptop screen, just like in this question. In my case however this happens only if triggering syspend/hibernate via lid.

Inspecting the logs I see no difference suspending this system via lid or keyboard. From the logs' perspective in both situations resume is happenning identical and system is similarly operational, apart from disabled screen for the case with the lid.

I have tried making ACPI Video built-in, Brightness modules built in, tried completely disabling EFI FB from kernel, but nothing helps. Also tried to enable the screen with brighness keys and "monitor select" Fn-key, also without any luck. Tried installing vbetool. This is not only helpless in solving this, but also breaks suspend and hibernation completely.

Given the observations, it looks like something (hardware or software) is supposed to turn the screen on, but with lid event it does not work out properly or timely.

Given the resume from lid event, what is responsible for enabling the screen? How is the time of this enabling controlled? Am I missing some kernel module, that is resonsible for lid? For video? For screen turning on?

Given that I can later manually enable the screen via HDMI, can I add this action to resume script? How do I do that? What could the command "Enable the embedded screen/ Screen:0" be like?

More detailed answer follows for anyone interested

My failing kernel was for some reason lacking CONFIG_DRM_FBDEV_EMULATION=y

TL;DR end

Suddenly I have remembered that I once had genkernel kernel with initramfs, that probably worked fine.

It used the config from LiveCD, so I got that config and compiled the kernel with this config. Guess what? The issue was gone!

So I've got 2 configs, one of which works and the other does not. Firstly I thought it is because of initramfs, but it was really quick to recompile the working config without initramfs to be sure, that it is failing not because of initramfs. Next step was to diff the both configs and try to identify the setting, which affects my system. Well, easier said than done: diffing gave me overwhelmingly huge amount of differences to figure it out.

I had no other choice other than bit by bit morphing the working config into non-working, searching for the setting needed. It took quite a loooooot of tries, but eventually it was a success!