|
Bugzilla – Full Text Bug Listing |
| Summary: | X server wakes up on any ACPI event | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x> |
| Component: | X.Org | Assignee: | Egbert Eich <eich> |
| Status: | RESOLVED FIXED | QA Contact: | Stefan Dirsch <sndirsch> |
| Severity: | Critical | ||
| Priority: | P3 - Medium | CC: | am, eich, f.alabas, jc-wi, nderkach, riggwelter, sndirsch, suse-beta |
| Version: | Alpha 0plus | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Component Test | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 240055 | ||
| Attachments: |
p_xorg_acpi.diff
Patch to destinguish between general and input devices acpi_events.diff Fix Fix |
||
|
Description
Forgotten User ZhJd0F0L3x
2006-08-08 14:59:12 UTC
FWIW, i am using STABLE as of yesterday, root@susi:/root# rpm -qa xorg-x11 xorg-x11-server xorg-x11-7.1-10 xorg-x11-server-7.1-14 Is this already in RPM changelog of xorg-x11-server? ------------------------------------------------------------------- Mon Aug 7 11:02:11 CEST 2006 - sndirsch@suse.de [...] - p_xorg_acpi.diff: * reconnect to acpid when acpid has been killed (Bug #148384) Maybe I did sth. stupid when adjusting the patch to the X.Org 7 ... Is this a regression against X.Org 6.0 on 10.1? no, this is present since at least 10.1 or maybe even earlier. I just never actually realized what the real issue was, but the display never stayed off for me for quite a long time. Ok. After having a short look on the code, i assume that the problem is: - ACPI events are wired up to an input event handler - the ACPI eventhandler actually checks if the event is of type "video" and returns 1 in this case, 0 if not. I _believe_ (did not dig that far :-) that any input event first activates the backlight, and then checks if there is actually something to do (which it finds out that there isn't in the case of an ACPI button event). This also sort of explains why the backlight turns on, but the screen is not unblanked. A keystroke OTOH unblanks the screen (because the eventhandler has something to process). Just an uneducated guess :-) Egbert is willing to investigate this issue. Reassigning. jfyi: i have not noticed this on 10.2alphaX, but this might be because of different hardware It still happens: xset dpms force off; then pull the ac-adapter plug, then the light goes back on. I just happen to use a machine now, that throws much less ACPI events :-) Created attachment 105953 [details]
p_xorg_acpi.diff
Egbert, just a reminder, that we're still using your ACPI patch (which I needed to adjust for X.Org 7).
Created attachment 106208 [details]
Patch to destinguish between general and input devices
This patch fixes the problem both for acpi and apm.
Thanks for the patch, Egbert! The patch cannot be applied. Strange, even after disabling p_xorg_acpi.diff mentioned in comment #11. Need to investigate. Might be related to changes between RC1 and RC2. Egbert, nearly all hunks are already applied to RC2. The remaining hunk is the apm one. Created attachment 106217 [details]
acpi_events.diff
Updated patch for X.Org 7.2 RC2.
Seife, this should already be fixed with Beta2+! fixed for apm for RC1. This means the problem was gone it RC2 already. Yes, I think so. indeed, the problem is no longer there in beta2+ Thanks! spoke too soon. Still happens on beta2+ on the hp nx5000. d119:~ # rpm -q xorg-x11 xorg-x11-7.2-18 d119:~ # cat /etc/SuSE-release openSUSE 10.2 (i586) Beta2plus VERSION = 10.2 > Still happens on beta2+ on the hp nx5000. Is this still an APM notebook? This should be adressed with the patch in comment #17 and will be included for RC1. No, ACPI. It is easily reproducible: exit kpowersave rcpowersaved stop (now nothing catches the power button event) xset dpms force off (display dark) push power button (display black, but backlight on). Assigning back to Egbert. Egbert, what is the status of this one? This is also in SLE10SP1Beta1. Do i need an extra bug for that product? Created attachment 115856 [details]
Fix
In addtition to the AddGeneralHandler() Fixes that had been added to R7.2.nn this patch is needed to really prevent ACPI events from interferring. The problem happens on VTSwitch: here all devices which have been carefully avoided during initialization get 'enabled'.
Thanks. fixed for STABLE/Factory. i installed xorg-x11* and libdrm* from stable on my 10.2 and it seems to help. Thanks for verifying! At least it's easy to reproduce. Xorg & chvt 1 chvt 7 ==> Bang Program received signal SIGSEGV, Segmentation fault. 0x080cbccb in xf86EnableInputHandler (handler=0x81e6b38) at xf86Events.c:1783 1783 if (ih->fd >= 0 && FD_ISSET(ih->fd, inputDevices)) (gdb) p inputDevices $4 = (fd_set *) 0x0 (gdb) JFYI, I disabled the patch for now. Created attachment 116761 [details]
Fix
WakeupHanlder should not call xf86EnableInputHandler()
the backtrace isn't reliable.
Improved Fix.
Thanks! I'll give it a try. Ok. I can't reproduce any crashes when VT switching with the new patch right now. Seife, could you give it a try as well? Thanks. --> /work/built/mbuild/shannon-sndirsch-8/ The build works for me, does not crash on vt switch and does not wake up on power button presses. Thanks. Package submitted. Closing as fixed for STABLE/Factory. *** Bug 242024 has been marked as a duplicate of this bug. *** *** Bug 242026 has been marked as a duplicate of this bug. *** This bug does not appear fixed (at least in the 10.2 most recent fixes I picked
up from yast last night.
I have chased more explicit info on it (or possibly a variant on it) for my
Toshiba M300 laptop:
sys_vendor = "TOSHIBA"
sys_product = "PORTEGE M300"
sys_version = "PPM30E-00D01QEN"
bios_version = "Version 1.10"
I note the following bad interaction of X and suspend
(which I didn't see reported here explicitly).
1. I fleshly power up, and login directly to FVWM2 (i.e. little messing around)
and xset dpms 0 0 300 (or so).
2. then acpi_events (I use plug/unplug laptop power) then do *not*
cause the backlight to be turned on after DMPS turns off the screen
but they are reported by acpi_listen. Moreover, plug/unplug changes
brightness (before the 300 sec timeout). So X is working 'properly'.
3. However, if I then force suspend with /usr/bin/powersave -u
and then resume then:
4. afterwards acpi events (as reported by acpi_listen) now *do* cause the
backlight to turn on :-( [this has the effect of consuming battery but
not displaying text as X is still blanking the image, so the backlight is
spuriously on.]
5. This effect also happens with powersave -U.
Sorry if this is fixed in 10.3 (but surely it's critical enough to fix in 10.2).
>This bug does not appear fixed (at least in the 10.2 most recent fixes I >picked up from yast last night. This bug has not been fixed for 10.2. See my comment #42. *** Bug 230528 has been marked as a duplicate of this bug. *** *** Bug 193144 has been marked as a duplicate of this bug. *** |