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 or none. 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... Any ideas?
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.
Alexandre, 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 reporter's distribution. 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 information. 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.
Alexandre, I suggest the following as a start which may resolve the issue for you (for both machines you mention): http://people.freedesktop.org/~hughsient/quirk/ 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. Regards Chris
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.