1/29/2024 0 Comments Xscreensaver tlpUnlike many other kludges it will automatically re-enable the screensaver if your application crashes or exits via some route that forgets to call the re-enable code. It controls most popular screensavers, and the OS vendor would be responsible for updating it/ maintaining it to work with newer screensavers or better ways of doing this in the future. However, xdg-screensaver is a FreeDesktop standardised shell script which you can run as a sub-process to control the screensaver. GNOME and KDE look to be implementing a DBUS approach to this problem, but in my opinion even if it becomes widespread (it isn't yet widespread enough to rely on it in 3rd party code) it's not the right approach. But no such mechanism yet exists to my knowledge. In my opinion there should be a mechanism administrated by the X server, which both screensavers and interested applications can voluntarily use to negotiate suppression of any screensaver during the runtime of one or more programs. I knew I couldn't be the only or first one to face this problem. Looking at xdg-screensaver (which seems to be a shell script that ultimately just does a "wait" for my process - cool) it seems to be made to do just what I want. With my thought of synthesizing X events, I was imagining it would be just often enough to make the screen saver think there was activity. No, of course not expecting to run it every frame, but don't want it causing hiccups when it does run, is all. So, good intentions, but doesn't seem to actually work. To re-enable the screensaver, I have to manually kill them, and manually remove the files it leaves around in /tmp: wordwarvi]$ kill 4218 wordwarvi]$ rm wordwarvi]$ xdg-screensaver wordwarvi]$ ![]() Running xdg-screensaver resume window-id does not resume the screensaver. rw- 1 scameron scameron 15 20:12 wordwarvi]$ wordwarvi]$ xdg-screensaver wordwarvi]$ ls -ltr /tmp | grep xdg Scameron 4313 3151 0 20:15 pts/1 00:00:00 grep wordwarvi]$Īnd they never die, even after the program they are supposedly waiting for dies, and the screensaver is never re-enabled. Or whether the window id is gotten via xprop, and xdg-screensaver run manually, two processes are created: wordwarvi]$ ps -efa | grep xdg Once you do "xdg-screensaver suspend window-id", where window id is gotten from within the program via xwindow_id = GDK_WINDOW_XWINDOW (GTK_WIDGET (widget)->window) The xdg-screensaver script is there, and seems to be intended to work, it just doesn't actually work. Hmm, unfortunately, at least on Fedora core 8, this does not appear to work. Seems like maybe synthesizing X events somehow to fool the screensaver into thinking there's some activity might do the trick in a universal way, but I'm really not sure how to do that (and hoping you wouldn't need to be root to do it.) Just wondering if anybody else has run into this, and what they've done, and if they did anything, if it was as ugly as it seems to me it would have to be, or if there's some elegant solution out there. Has anybody encapsulated the code to inhibit all of these into a fast chunk of code? Oh, and it has to be GPL compatible.Ĭurrently my code simply whines piteously about the uncooperative screensaver developers if any screensaver is detected and the joystick is in use, and doesn't actually try to do anything other than advise the user to manually disable the screensaver, as the only other thing I can think to do is so incredibly ugly that I simply refuse to do it. I put "the" in quotes, because there are at least three different popular screensavers, xscreensaver, gnome-screensaver, and kscreensaver, each with their own unique and clunky methods by which an application might inhibit them. ![]() I have a gtk based game program that's cranking out 30 frames/second while mixing several channels of audio, and since it's controlled by a joystick, sometimes "the" screensaver will kick in. I'm looking for a decent, non-lame way to inhibit xscreensaver, kscreensaver, or gnome-screensaver, whichever might be running, preferably in a screensaver-agnostic manner, and it absolutely positively must execute fast.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |