Bug#317691: xscreensaver: should throttle when starting new login
Hi, are you still experimenting this issue? I cannot test this problem in a configuration like yours so I cannot reproduce it nor denied this bug exists. Regards, Jose Luis. -- ghostbar on Linux/Debian 'sid' x86_64-SMP - #382503 Weblog: http://ghostbar.ath.cx/ - http://linuxtachira.org http://debian.org.ve - irc.debian.org #debian-ve #debian-devel-es San Cristóbal, Venezuela. http://chaslug.org.ve Fingerprint = 3E7D 4267 AFD5 2407 2A37 20AC 38A0 AD5B CACA B118 signature.asc Description: OpenPGP digital signature
Bug#317691: xscreensaver: should throttle when starting new login
On 2005-07-10 12:00:13, Jamie Zawinski wrote: On Jul 10, 2005, at 10:57 AM, Michael Shields wrote: However, this leaves a screensaver running on the old display, now hidden but likely consuming a significant amount of CPU. Do you have evidence that this CPU usage is a problem? Because it shouldn't be: http://www.jwz.org/xscreensaver/faq.html#suspend Yes: 1. Much of the load seems to be in the server, not in the client. The server is not niced, so it competes with my visible session. For example, right now if I unthrottle the hidden session, XFree86 consumes 60% of the CPU to run hypertorus without GL acceleration (because only the first login can be accelerated). 2. Even if the CPU load were completely niced, on a laptop, having the CPU spin to run a hidden screensaver is a significant power draw versus leaving the CPU idle, and will cause the battery to run down sooner. It would be helpful if starting a new session also set the old one to a blank screen instead of a graphics hack, as if xscreensaver-command -throttle had been run. Not a bad idea, I suppose, but the more general solution would be to throttle while (and only while) the VT that the X server is running on is not the selected one. You want the screen saver to un-throttle when the user switches back. You're right. Also, if you switch away from the second session back to the first, it could start a screensaver and have the same issue. However, I don't know how to tell A) which VT X is on; B) whether it is the front; or C) when it changes. Well, on Linux, it looks like you can check the current VT using a VT_GETSTATE ioctl (on /dev/tty0), and wait for a VT to become active using VT_WAITACTIVE. These are documented in console_ioctl(4). There doesn't seem to be a way to be notified when your VT becomes inactive. So, one way to implement this without requiring anything of gdmflexiserver or similar apps would be to check on startup which VT is ours, and then while running a hack, check occasionally to see if the active VT is our VT. If it isn't, or when the user hits the new login button, then throttle, use VT_WAITACTIVE to block until the user returns, then unthrottle. Does this seem like a reasonable approach? -- Shields. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317691: xscreensaver: should throttle when starting new login
So, one way to implement this without requiring anything of gdmflexiserver or similar apps would be to check on startup which VT is ours, and then while running a hack, check occasionally to see if the active VT is our VT. If it isn't, or when the user hits the new login button, then throttle, use VT_WAITACTIVE to block until the user returns, then unthrottle. Does this seem like a reasonable approach? That seems reasonable, though I'm not entirely comfortable with the assumption that the VT that is current when xscreensaver starts up is the VT that the X session is running on; if that's not the case for whatever reason (e.g., something earlier in the startup script was being slow, and the user switched VTs to figure out why) the failure mode is not so good. Another thing that might be a problem (I haven't checked) is whether these ioctls work from unprivileged processes. E.g., xscreensaver cannot use the VT_LOCKSWITCH ioctl (which would be a nice option to prevent VT switching when the screen was locked) because that ioctl can only be called by root (and xscreensaver has long discarded its privs by the time it would want to use it). -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ http://jwz.livejournal.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317691: xscreensaver: should throttle when starting new login
On Jul 10, 2005, at 10:57 AM, Michael Shields wrote: However, this leaves a screensaver running on the old display, now hidden but likely consuming a significant amount of CPU. Do you have evidence that this CPU usage is a problem? Because it shouldn't be: http://www.jwz.org/xscreensaver/faq.html#suspend It would be helpful if starting a new session also set the old one to a blank screen instead of a graphics hack, as if xscreensaver-command -throttle had been run. Not a bad idea, I suppose, but the more general solution would be to throttle while (and only while) the VT that the X server is running on is not the selected one. You want the screen saver to un-throttle when the user switches back. However, I don't know how to tell A) which VT X is on; B) whether it is the front; or C) when it changes. -- Jamie Zawinski [EMAIL PROTECTED] http://www.jwz.org/ [EMAIL PROTECTED] http://www.dnalounge.com/ http://jwz.livejournal.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
