On Fri, 06 Apr 2007 12:15:10 -0500 Ravenlock <[EMAIL PROTECTED]> babbled:
> Hello, > > While investigating a different DPMS issue I've run across what I > believe is an Xorg/xscreensaver/DPMS issue. Running Xorg 6.9.0 (maybe > others for all I know) if I enable the xscreensaver, and setup DPMS to > *not* enter standby, but *do* enter suspend... I get a segv shortly > after the screen suspends. > > I use the following commands specifically. > 1) xset s noblank > 2) xset s 60 5 > 3) xset dpms 0 0 120 > > The commands above are important. The screensaver must be set to no > blank, it should alternate at a short period (or you'll have to wait for > the segv). And on two different machines I have had to setup DPMS > differently... but what seems significant is I am *not* entering standby > or suspend before entering off. > > The following is the backtrace I get with gdb attached to Xorg. > > Program received signal SIGSEGV, Segmentation fault. > 0x080d9121 in SaveScreens () > (gdb) bt > #0 0x080d9121 in SaveScreens () > #1 0x080deb5d in ScreenSaverTimeoutExpire () > #2 0x080de8db in DoTimer ()/gallery/main. > #3 0x080de3f9 in WaitForSomething () > #4 0x080ba564 in Dispatch () > #5 0x080cce94 in main () > > Now... all this is interesting. And I *think* it is an Xorg issue > entirely. I say think because I *can not* reproduce this running other > window managers (fvwm). However, given the above bt, and the fact that > E17 does not segv when it occurs, it just looks like Xorg > > However, my question to the ml here is... Do we ignore the bug and code > to "spec" until Xorg fixes it? Meaning the DPMSSetTimeouts() man page > says you may disable any one of the modes. Or do we prevent the user > from shooting themselves in the foot by altering our config panel? > > Presently the E17 DPMS config panel allows us to put ourselves in this > particular position. So if we do nothing, we are coding to what the > manpage says is perfectly legitimate, and the user can apparently > configure their machine to segv on timed intervals. > > Or we can apply the attached patch. The attached patch will fix the > problem behavior and make no (noticeable?) change in functionality. It > does so by quietly setting any disabled lesser mode to the same timeout > as the next greater mode's timeout. I did this without modifying the > gui intentionally. Ideally I would be able to report this upstream, and > once its fixed we could quietly revert this patch and be on our way. > > I'm hoping for comments on if anyone else can reproduce this, whether > this is in fact a bug with Xorg, if this is a suitable way to "fix" it, > or if we should just carry on without the patch. > > Questions, comments, and complaints welcome. interesting. i can't reproduce. X.Org version: 7.1.1 so it's definitely an x bug. if x is segving... x is definitely having problems - we code to spec. if an older x with certain drivers might have a problem - we can try code around - but if it is painful - we don't. :( as your x is old-ish - might want to try an update :) > -- > Regards, > Ravenlock > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
