Hi "badbetty", does your computer have more than one video port or card? Do you suppose that the new kernel is choosing to put the display output on the port/card to which no monitor is attached?

Does your computer have an LCD display? Back when I was investigating the trouble with my ASUS computer I came across mention that for some hardware the backlight 'brightness' control is inverted. (This was not the trouble in my case.)

Latest findings might suggest it is an issue between whatever has changed in the kernel with respect to ACPI.

There are quite a few [old and newer] reports across distros on the internet about this type of issue.

In respect of this I added "acpi=off" in to the append attribute in the lilo.conf and behold, it booted up seemingly fine. Of course, this is not ideal, but it does help narrow down the issue. I will keep pursuing this angle and see how far I get, though not sure just yet where to look next on this kernel/acpi connection.

Something has gone awry between the working kernel and the updated kernel with respec to ACPI it would seem at the moment.

...
acpi=off appears to boot without issue (but not good for anything else in respect of acpi being permanently off once booted)

acpi=noirq issue persists

pci=noacpi kernel panics and wont boot at all.


now then, on to "how do I best 'bisect'" knowing it might be acpi related (just as @baumei hinted at to be fair).

I do wish these kernel-dev folk would check first before making changes - haha (only kidding)

aha... so after many many hours of learning to bisect, I found out that the 'screen blanking' issue seemingly starts to occur somewhere in 4.4.171... and then eventually refined that to:

bad: [0c4a25cc6f2934f3aa99a0bbfd20b71949bcad25] platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey

What that means I have no idea or what to do next please ?... but its now clear (I think haha) as all is fine before this version.


Phew it was a laborious effort I tell you :-~

Fill bug report in https://bugzilla.kernel.org/. Tell there about your findings and tell exactly what type of Asus laptop you have. Google search reveals some problem with this commit already (see https://lore.kernel.org/patchwork/patch/1087451/). They just add your laptop type to quirks and problem will be fixed in some future (maybe next) kernel release.

I will follow the link to bugzilla and see what's what there.

Quickly, as this OP was not about it, I will see if I can drum up enough enthusiasm to go through the same process for the bluetooth usb adapter issue I briefly mentioned (lots of reports of bluetooth issues following kernel upgrades too). This particular one, quite specific perhaps, is noticed to be that after the 4.4.157 where everything is fine, bluetooth sending (to the computer with the usb adapter) fails but all other functions are fine...rather odd it is.... just the 'sending to' part.

edit: oh and bluetooth audio sink not working too - forgot.

marking as solved from my perspective as its (poss. bug) going somewhere else now. thank you all.

Hi "badbetty", if you have not tried it yet, I think it would be interesting to see what the following commands do for your display: On my ASUS Eee PC HA1005 running 4.19.26, and on various other computers I have owned which ran Slackware, the above commands reliably turned the display ON or OFF.

Back when I was investigating my problem with kernel 4.4.172smp 32-bit, I used ssh to login to my Eee PC, switched to root, and ran the commands --> and as I recollect the commands did not do anything useful. I gather you are running 4.4.172 64-bit on different hardware; it may be the commands work in your case.

If the vbetool command works on your computer, it may be easily possible to use the command as a line in "/etc/rc.d/rc.local" to turn the display ON during boot-up. Or, perhaps to write a 'stanza' for your ACPI code which toggles between the two states (or some such thing).

@baumei

I will try them. Do they do a similar thing as the Fn + 'screen on/off' key that originally mentioned ?

Hi "badbetty", yes, when 'vbetool dpms' is able to function, its effect which the user can see is similar to the effect of <Fn> + 'screen on/off'. From what I have read, the manner by which vbetool does its work is different from the way the OS does it (I do not personally know).

If I understand correctly, your computer starts the boot process with the display functioning, and then part way through boot-up the display goes off --- and after boot-up your <Fn> + 'screen on/off' functions.

If 'vbetool dpms' is able to function on your machine with 4.4.182, then I would try putting "vbetool dpms on" in your "/etc/rc.d/rc.local" file, and reboot. What I would hope/expect to see from this is: when the boot-up process runs rc.local that the display would turn back ON.

Hi "badbetty",

Back in June you wrote:
I mentioned to LQ member 0XBF that you had found the 64-bit 4.19.56 kernel set had the black screen problem.

OXBF reported finding out from the maintainers of asus-wmi that a fix for the problem was developed, but the fix was not put into any kernel series older than 4.19.x, and that it was introduced into the series starting with the 4.19.58 kernel set. Also, the fix was put into the newer kernel series, beginning with whatever kernel was being published around the time of 4.19.58.
https://www.linuxquestions.org/quest...6/#post6061298

I gather the maintainers are considering backporting the patch to the other kernel series which are still supported.

@baumei

hi, thank you for that update.

Perhaps a case of 'watch this space'.

Much appreciated. Regards
Habs