Red Hat Bugzilla – Bug 398991
can't power on/off notebook's LCD display any more
Last modified: 2008-02-18 20:19:27 EST
Description of problem:
It used to be possible to use Fn-F4 on my HP Presario R3004US notebook to switch
between 4 different settings, when using the vesa driver and with an external
VGA display connected to the notebook: LCD only, external VGA display only, both
A few days ago, I noticed that this no longer worked. Fn-F4 would still log a
"kernel: video bus notify" in /var/log/messages, as before, but now
/var/log/X.0.log will get a "PM Event received: Capability Changed" logged (I
don't remember having seen this before), and the screen will now blank for a
moment and then return to the previous configuration, in which both internal and
external displays get the video signal.
I don't know whether this is in any way related, but Fn-F8 used to perform the
same function on my older Dell Inspiron 8000 (except it didn't have the "both"
setting), and it would bring signal back to the internal LCD display, powered
off after keeping the lid closed for 10+ seconds, even in the absence of an
external display. This doesn't work any more, and the only way I know to
re-enable the LCD now is to hibernate or reboot. Oh, this one notebook doesn't
use the vesa driver, but rather the nv driver. So maybe it's a different
problem. Or maybe the problem is in other part of X, or even in the kernel...
Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.
Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.
Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.
We will review this issue again once you've had a chance to attach this information.
Thanks in advance.
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Asking these "recorded message" questions is sort of silly when they're not even
vaguely related with the reported problem. E.g., you haven't mentioned which of
the two affected systems you wanted the information for, which shows you haven't
even bothered to read the bug report. If you had, you might very well have been
able to tell me that it has nothing to do with X, that it's some new feature in
the kernel video output drivers that export this functionality through /sys.
And that the fact that the new behavior occurred even without X, or with the -nv
driver, indicates it can't possibly be a problem in X.
Indeed, going back to a 2.6.21ish kernel restores the expected behavior.
Unfortunately I still have no idea as to how to get that behavior back, not
through /sys, not through hot-keys :-(
Problem affects Fedora 8 as well (not sure if only with latest updates or with
original kernel as well, but I don't think it matters at this point).
Alexandre, a) I understand that boiler-plate comments are PITA, but there is
just too many bugs to write a novel for each of them and yes, I can screw up
sometimes, b) actually I read this bug (of course, I do read all of them), and i
meant to get information only about HP notebook (I thought that Dell was used
only as an example), c) requiring all these logs would help us to get more
information about your hardware, when the only thing I get about from your
initial report is that Dell "doesn't use vesa, but nv driver". Sorry, but that's
not enough information to work on.
So, if this is meant as bug report for both computers (we generally prefer one
bug for one issue), please attach all these configuration and log files for both
computers. I will sort it out somehow.
Any update on this? Are you able to attach the data Matej has requested?
I could, but I don't see how this would help. The problem has nothing to do
with X, like I thought as of the time I filed the bug report. It's some new
kernel "feature", that breaks the hot keys even before X is started.
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
Closing as INSUFFICIENT_DATA.
Why are you still messing with and harassing me about this bug as if it were an
X issue? It's a kernel issue, and bugzilla says so. I have no idea why it's
still assigned to xgl maintainers, but that's an error. Unfortunately, I don't
know how to fix it.
Reading /usr/share/doc/kernel-*/video-output.txt, I get the impression that it
should be possible to power on or off the internal and the external video output
through /sys/class/video_output, but I have been completely unable to figure out
what I have to write where, and it would be awesome to have the BIOS hot keys
back. Clearly the kernel does get some event, for it issues a video bus notify
message, but then it reverts the effects, rather than doing what it's meant to do.
I suggest the following as a start which may resolve the issue for you (for both
machines you mention):
Please also understand that if you are unable to provide information as
requested we will likely close bugs as we need co-operation in order to resolve
a bug. Whilst you may not recognise this as an X issue it may well be, or
perhaps kernel or as I have indicated above a HAL/udev issue. The reason we ask
for this info is so that we can determine this better. By all means add your
thoughts but please do add the requested info so we can start to resolve the
problem and add in the necessary people to this bug.
rawhide updated to kernel 2.6.25 pre enables the hot key to switch between
internal and external video again, both before and after X (and hal) start
running. With nv and nouveau, X needs a restart to work on the newly-selected
screen, but it gets back in shape if you switch back to the originally-working
one, just like before.
I still don't see how a problem that shows up before any X-related stuff (or
hal) is started could possibly be an X (or hal) issue, so if you can give me a
clue as to how that could be, I'll be glad to provide the requested info.
Otherwise, I think it's just waste of bandwidth and database space. And if you
just want the info for some configuration database, then you most certainly
already have it, because I filed it before in other bug reports that were actual
X bug reports.