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]

Reply via email to