On Fri, Jan 26, 2007 at 02:17:34PM +0000, Alan Mycroft wrote: > Stefan, > > Sorry to trouble you again; by all means tell me "this is too off-topic > for you" or "someone else is fixing it" or perhaps point me at > a suitable place to discuss this (I'm wary of contributing directly > because I'l not really an OS hacker -- I'm more of a compiler person). > > Anyway you remark: > > This looks like https://bugzilla.novell.com/show_bug.cgi?id=197858 > > I don't think it is related to suspend at all, it is an Xserver bug. > > Well, yes and no. I've read the above bugzilla, and it certainly > looks like this (I note this thread seems not to be active recently, so > more input may be welcome?). > > In particular I note the following interaction of X and suspend > (which I didn't see reported there) > 1. I power up, and login directly to FVWM2 (i.e. little messing around) > 2. then powersave events (I use plug/unplug laptop power) then do *not* > cause the backlight to be turned on. So X is working properly.
Check with "acpi_listen" if there really are acpi events before suspending. Maybe this is not the case (which would again be a different bug :-). > 3. However, if I then force suspend with /usr/bin/powersave -u > and then resume then: > 4. powersave events now *do* cause the backlight to turn on :-( Beware: "powersave events" are something completely different then "ACPI events" i was talking about. I'm assuming you mean "ACPI events" :-) > So, is this more a matter of the X-server (or some hardware) not > being reset properly after resume? Probably not. The X server (probably only the SUSE-patched version) has a bug, where it listens for ACPI events, to get ACPI "video notifications". But that code is buggy: it "wakes up" the X server on _any_ ACPI event, before checking if it even cares about this event. Now maybe this code is even more buggy than i thought and it actually does not react to any ACPI event before suspend in some cases. > [Of course, it may be localised to my hardware, but the bugzilla report > seems to indicate it's a more general (and unsolved) problem. I have at least one machine, that wakes up the X server on any event even before suspend. > Incidentally, if instead of 3, I do: > 3'. force hibernate with /usr/bin/powersave -U > then the same situation occurs > 4. powersave events now *do* cause the backlight to turn on :-( > > [There seems an additional oddity -- my testing "xset dpms 0 0 5" > (which I set before set before the suspend/hibernate) > is still reflected in xset -q > afterwards, but its effect has been lost by the Xserver.] Yes. I investigated this, and the piece of code that awakes the X server is completely different from the DPMS timings etc. It is "halfway through" the input device handling. > I suspect the Xserver perhaps needs reloading after suspend/hibernate. no. You should be able to work around this X server bug by using something like Section "ServerFlags" Option "AllowMouseOpenFail" "on" Option "NoPM" "yes" EndSection in the xorg.conf. I am quite sure this is not related to the s2disk/s2ram software. And not a kernel problem. So yes, it is offtopic here, but feel free to open a bug in the Novell Bugzilla against your SUSE version :-) > Is there a forum I can contribute positively to this, instead of bugging > you? https://bugzilla.novell.com :-) -- Stefan Seyfried \ "I didn't want to write for pay. I QA / R&D Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \ -- Leonard Cohen ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
