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.
--
Regards,
Ravenlock
Index: e17/apps/e/src/bin/e_dpms.c
===================================================================
RCS file: /var/cvs/e/e17/apps/e/src/bin/e_dpms.c,v
retrieving revision 1.1
diff -u -r1.1 e_dpms.c
--- e17/apps/e/src/bin/e_dpms.c 13 Feb 2007 16:33:35 -0000 1.1
+++ e17/apps/e/src/bin/e_dpms.c 6 Apr 2007 16:15:23 -0000
@@ -14,10 +14,22 @@
standby = e_config->dpms_standby_timeout;
if (e_config->dpms_suspend_enable)
- suspend = e_config->dpms_suspend_timeout;
+ {
+ suspend = e_config->dpms_suspend_timeout;
+
+ if (!e_config->dpms_standby_enable)
+ standby = e_config->dpms_suspend_timeout;
+ }
- if (e_config->dpms_off_enable)
- off = e_config->dpms_off_timeout;
+ if (e_config->dpms_off_enable)
+ {
+ off = e_config->dpms_off_timeout;
+
+ if (!e_config->dpms_standby_enable && !e_config->dpms_suspend_enable)
+ standby = e_config->dpms_off_timeout;
+ if (!e_config->dpms_suspend_enable)
+ suspend = e_config->dpms_off_timeout;
+ }
ecore_x_dpms_timeouts_set(standby, suspend, off);
-------------------------------------------------------------------------
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
