XScreenSaver 4.21 out now. Lots of changes this time around, but the most interesting ones are: - fliptext; *
- text-manipulating modes can load URLs now, and can be bulk-configured via the GUI; *
- molecule -shells; *
- mouse hysteresis. *
This release is dedicated to the splitting headache I've had for the last twelve hours.
Is there a way to tell XScreenSaver to leave my DPMS settings alone, as opposed to force-on or force-off? I have a custom daemon on my laptop that watches the ACPI AC power state and changes the X DPMS settings via xset (short timeout on battery, long on AC), as well as puppeteering xscreensaver (via a combination of -watch and -thrttle) to squelch hacks when on battery (to prevent powernowd from escalating the CPU speed unnecessarily).
The problem is that if I start this daemon before xscreensaver, xscreensaver tends to trample on the initial DPMS settings the daemon sets up based on the power state, and making the daemon routinely reset the DPMS timeouts (the obvious-to-me workaround) seems inelegant. Starting xscreensaver and then the daemon works too - but I'm not sure when and on what interval xscreensaver applies the DPMS settings - once at startup, and if they're changed from the GUI?
Is there a more elegant solution to having my screensaver/blanking policy be sensitive to the AC power state?
No, xscreensaver has to be fully authoritative about the DPMS settings, otherwise there's no way to tell which to obey: the GUI, or some dumb shell script. Preference changes don't have timestamps, so you can't tell which was changed last. xscreensaver will stomp your out-of-band DPMS settings changes as soon as it notices that you've made them, which is every few minutes.
I don't know shit about laptops and battery management (and I'd like to keep it that way.) Send me a patch if you figure it out.
If there's a portable, reliable way to ask, "are we on battery now", then xscreensaver could be configured to stop running hacks in that case. (But it would not be able to also power down the screen, due to the previously-ranted-about dpms bug.)
If there's a portable, reliable way to ask, "are we on battery now", then xscreensaver could be configured to stop running hacks in that case.
Hahahahahahaha. Hahahahaha. Hahaha. Haha. Ha. No.
The best you're going to manage is hal, which is a wonderful piece of software that will bring about world peace when it's shipped everywhere. Which is likely to be in about 20 years. Of course, at that point it's also worth picking up stuff like dbus and sending events when the screen is locked.
In theory, this is all wonderfully platform independent. However, nobody seems to have written much of the non-Linux side of things. I expect it to ship as standard on flying cars.
Isn't there some /proc file that contains battery info on laptops?
On Linux, you can dig through /proc/acpi/battery/*/state - the number of directories depends on the number of batteries. Typical output looks like:
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 45780 mWh
present voltage: 16695 mV
with charged changing to discharging when on battery. /proc/acpi/ac_adapter/*/state will be either
state: on-line
or
state: off-line
This is no good for apm machines. The fifth field in /proc/apm gives you whether you're on AC or not - 0 represents battery, anything else should be AC. I haven't got any APM machines here to test, but the format string for the output is:
"%s %d.%d %x %x %x %x %d%% %d %s\n"
Macs are different again. On most machines, you ought to have APM emulation and be able to parse /proc/apm as before. Otherwise you need to use /dev/pmu, which seems to require you write a command to /dev/adb and read it back from /dev/pmu. This is plainly insane, so you should just assume the existence of /proc/apm instead.
On BSDs or Solaris, God help your soul.
Wow.
Well, good luck with that!
Yeah. Hal makes that all go away from the application writer point of view, but it's going to be a while before it's sufficiently ubiquitous that it's reasonable to depend on it. Gnome are moving towards using it quite heavily (I'm giving a talk on power management at their development conference in a couple of months), so there's some hope that someone will just write a nice, non-invasive patch that does the right thing when the functionality is available.
configure: error: Your system doesn't have "bc", which has been a standard part of Unix since the 1970s. Come back when your vendor has grown a clue.
Which word didn't you understand?
bc
"bc" is provided by the "bc" package. You should install it.
All old-school UNIX commands (the two-letter ones) are acronyms.
bc - broken calculator
cd - change directory
dd - disk dump
ls - look somewhere
mv - move violently
od - octal dump
etc.
i'm assuming that bc is not required for xscreensaver 4.12, because that's what i'm currently running and it works just fine... 8/
It's required at compile-time, in the configure script. I believe there's no other portable way to do math in sh.
i compiled v4.12 without any problems and it works fine, but v4.21 says i'm missing something... something which nothing else has complained about. am i doing something wrong?
I will try to be as vague in my answer as you were in your question: "maybe."
If the "something" you're talking about is "bc", that requirement has been in there for many years.
okay, either why did v4.12 compile without any problems, or why does v4.21 want something that's apparently different from previous versions when it comes to the location and/or presence of bc?
Beats me. Probably the answer is "something changed on your system between when you compiled 4.12 and 4.21." That something probably being, "you used to have bc installed, and now you don't."
If this is traumatic to you, find a binary package instead of trying to build from source.
Noticing the new random-same mode in the changelog, I found that xscreensaver-demo doesn't like cyle to be 0 (the setting that should cause it never to cycle according to the man page). Could this be added as a new mode, "random-once"? Or could xscreensaver-demo be fixed and that feature documented in the tooltip?
I'm using 4.20 from Debian though, so if this no longer applies to 4.21, or is a debian-specific bug, let me know and I'll shut up.
Oops. Minimum was set to 1 instead of 0 in that widget. Edit xscreensaver-demo.glade2 and change line 290 from
<property name="adjustment">1 1 720 1 15 15</property> to
<property name="adjustment">0 0 720 1 15 15</property>
The xscreensaver.spec claims newLoginCommand is flaky, what sort of flakiness should I expect?
If I ever run gdmflexiserver, it wedges X so bad that I can't switch vts, and have to kill gdm remotely.
So, that sort of thing.
The new text-manipulating modes are way too enjoyable for words.
How about adding a "URL" option to the image manipulation checkboxen? For, I dunno, weathermaps and stuff.
Hrmmm. So I use XScreenSaver as my windows screen saver.
It's funny how I consider a move to Linux too much work, yet I'm willing to spend the time to port the de facto screen saver system for it over.
I don't know what that means. Either I really like XScreenSaver (which I do so much that I've installed linux on machines for the sole purpose of running the hacks) or I hate Linux (which I do for it's interoperability faults).
Anyway, I probably have a couple nights of work committing my heresy on this one now. Better get started.
What you are doing is wrong. Please stop.
Would this tasty ported goodness be available for downloading somewhere? If it isn't, would you be willing to make it so?
Please!......Pretty Please!.............With sugar on top!
I can have you killed.
Is there a way for people to change the lock screen image? I tried to use Swanson's themes (http://www.swanson.ukfsn.org/xss/) but it didnt work on xscreensaver 4.21.