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
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 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
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]
Bug#317691: xscreensaver: should throttle when starting new login
Package: xscreensaver Version: 4.21-5 Severity: minor When used with gdmflexiserver, xscreensaver now has a useful button on the lock screen to start a new session. However, this leaves a screensaver running on the old display, now hidden but likely consuming a significant amount of CPU. 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. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.11-powerpc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xscreensaver depends on: ii libatk1.0-0 1.10.1-2The ATK accessibility toolkit ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.6.5-1 The GLib library of C routines ii libgtk2.0-0 2.6.8-1 The GTK+ graphical user interface ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library ii libjpeg626b-10 The Independent JPEG Group's JPEG ii libpam0g 0.76-22 Pluggable Authentication Modules l ii libpango1.0-01.8.1-1 Layout and rendering of internatio ii libsm6 4.3.0.dfsg.1-14 X Window System Session Management ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14 X Window System miscellaneous exte ii libxml2 2.6.16-7GNOME XML library ii libxmu6 4.3.0.dfsg.1-14 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-14 X pixmap library ii libxrandr2 4.3.0.dfsg.1-14 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-14 X Toolkit Intrinsics ii xlibs4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4 compression library - runtime Versions of packages xscreensaver recommends: ii libjpeg-progs 6b-10 Programs for manipulating JPEG fil ii miscfiles [wordlist] 1.3-6 Dictionaries and other interesting ii netpbm2:10.0-8 Graphics conversion tools ii perl [perl5] 5.8.7-3Larry Wall's Practical Extraction ii wamerican [wordlist] 5-4American English dictionary words ii wamerican-large [wordlist]5-4American English dictionary words ii xli 1.17.0-18 view images under X11 ii xloadimage4.1-14.2 Graphics file viewer under X11 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
