xscreensaver to use CPU, even if not current VT (New User Login)

[Paul Sladen]

For fast-user switching, multiple X sessions are started on multiple virtual
terminals, but non-visible screensavers are still left running.

If one X login is being used (for example on vt7) and another is in the
background (eg. on vt9) then xscreensaver will continue to run unabated on the
background X server, in turn using up 50%-100% of the CPU.

xscreensaver can be put into 'suspend' mode and this should to done (perhaps
polling?) if the vt of the X session is not the currently visible vt.

[Jamie Zawinski (jwz)]

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 address hidden> http://www.jwz.org/
                     <email address hidden> http://www.dnalounge.com/
                                          http://jwz.livejournal.com/

[Michael Shields (shields)]

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.

[Jamie Zawinski (jwz)]

> 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 address hidden> http://www.jwz.org/
                     <email address hidden> http://www.dnalounge.com/
                                          http://jwz.livejournal.com/

[Paul Sladen (sladen)]

For fast-user switching, multiple X sessions are started on multiple virtual
terminals, but non-visible screensavers are still left running.

If one X login is being used (for example on vt7) and another is in the
background (eg. on vt9) then xscreensaver will continue to run unabated on the
background X server, in turn using up 50%-100% of the CPU.

xscreensaver can be put into 'suspend' mode and this should to done (perhaps
polling?) if the vt of the X session is not the currently visible vt.

[Peter Jochum (peter-jochum)]

This is a good idea. My workaround for this was choosing a CPU friendly screensaver such as popsquares.

[Jose-Luis Rivas (ghostbar)]

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

[Andrea Corbellini (andrea.corbellini)]

Oliver: are you still working on this bug?

[Jose Luis Rivas (joseluis-rivco)]

severity 317691 wishlist
severity 495047 wishlist

quit
--
Jose Luis Rivas. San Cristóbal, Venezuela.
GPG 0xCACAB118 0x7C4DF50D
http://joseluisrivas.net/acerca - http://ghostbar.ath.cx/about