I have set my screensaver to blank screen. While active I often see messages like: "unrecognised ClientMessage WM_CHANGED_STATE recieved for window Gaim" in the upper part of the screen. I don't think such messages should appear, because: 1) They can only confuse the user - this is debug info 2) While the screensaver is active the user is usually away, so all these messages can do is cause monitor burn-in. Perhaps these messages can be controled by the debug USE. Reproducible: Always Steps to Reproduce: Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer -momit-leaf-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -mtune=pentium4 -fomit-frame-pointer -momit-leaf-frame-pointer -pipe -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.ITDNet.net/gentoo" LANG="en_US.utf8" LC_ALL="en_US.utf8" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X acl alsa apache2 avi berkdb bitmap-fonts bonobo cdr crypt cups curl directfb doc dvd dvdr eds emboss encode flac foomaticdb gd gdbm gif gnome gpm gstreamer gtk gtk2 guile hal imagemagick imlib ipv6 ithreads java jpeg junit kde kdeenablefinal ldap libg++ libwww mad mikmod mmap mmx motif mozilla mp3 mpeg mysql ncurses nls nptl nvidia ogg oggvorbis opengl pam pdflib perl pic plotutils png postgres pthreads python qt quicktime readline sdl session sharedmem spell sse sse2 ssl svga symlink tcltk tcpd tetex threads tiff truetype truetype-fonts type1-fonts unicode usb vorbis win32codecs xml xml2 xmms xv zlib linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS
just to clarify: this does *not* happen with -r2? could i get the output of `emerge -pv xscreensaver` please?
This has always happened, as far as I recall, -r2 included. I like packing maximum info in the bug summary, that's why I included the version. home ~ $ emerge -pv xscreensaver These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] x11-misc/xscreensaver-4.22-r3 [4.22-r2] +gnome +jpeg +kde -kerberos -krb4 +motif -new-login +nls -offensive +opengl +pam -xinerama 0 kB Total size of downloads: 0 kB home ~ $
A quick grep in <xscreensaver-4.22-source>/driver reveals the probable source of the messages: xscreensaver.c:1644: fprintf (stderr, "%s: %d: unrecognised ClientMessage \"%s\" received\n", I am not sure why is stderr ending up on the screen though. Also, I don't remember this happening with a screensaver other than blank screen.
-r4 should fix the problem... please confirm
Yes, it seems fixed. Thanks.
Ok, I saw a new message this morning. It looked like: xscreensaver:<time-stamp>:0: for window <hex number> ( Gaim/gaim ) I am running xscreensaver-4.22-r4 now.
This is still not fixed. I am looking at the patch you are applying in -r4: + /* fprintf (stderr, "%s: %d: unrecognised ClientMessage \"%s\" received\n", blurb(), screen, (str ? str : "(null)")); + */ + fprintf (stderr, "%s: %d: for window 0x%lx (%s)\n", blurb(), screen, (unsigned long) w, wdesc); Perhaps the the second printf should be commented too.
(In reply to comment #7) > This is still not fixed. > Perhaps the the second printf should be commented too. well, what i really need to figure out is why stderr is showing up on the screen AT ALL
I did a little grepping in the source, and I think the reason is in driver/stderr.c, in particular these functions: /* If stderr capturing is desired, this replaces `stdout' and `stderr' with a pipe, so that any output written to them will show up on the screen as well as on the original value of those streams. */ void initialize_stderr (saver_info *si) { ... } /* Called when data becomes available on the stderr pipe. Copies it into stderr_buffer where stderr_popup_timer_fn() can find it later. */ static void stderr_callback (XtPointer closure, int *fd, XtIntervalId *id) { ... } /* Polls the stderr buffer every few seconds and if it finds any text, writes it on all screens. */ static void stderr_popup_timer_fn (XtPointer closure, XtIntervalId *id) { ... } The criteria on whether stderr capturing is desired seems to be a X resource: driver/stderr.c: Boolean stderr_dialog_p; driver/stderr.c: stderr_dialog_p = get_boolean_resource ("captureStderr", "Boolean");
(In reply to comment #9) > The criteria on whether stderr capturing is desired seems to be a X resource: Did you test setting this resource to false?
No, but I will try that probably next weekend and report back.
Ok, I guessed it is a X resource, because of the name of the function get_boolean_resource, it seems to be an option in ~/.xscreensaver. man xscreensaver goes: captureStderr (class Boolean) Whether xscreensaver should redirect its stdout and stderr streams to the window itself. Since its nature is to take over the screen, you would not normally see error messages generated by xscreensaver or the sub-programs it runs; this resource will cause the output of all relevant programs to be drawn on the screensaver window itself, as well as being written to the controlling termi- nal of the screensaver driver process. Default true. Since this appears to be the intended xscreensaver behaviour what is the correct way to proceed ? Patch the Gentoo xscreensaver to default to false ? Bug upstream ?
In the limited testing I gave it, setting captureStderr: False in .xscreensaver supresses the debug output.
Reopen if you can reproduce w/ >=x11-misc/xscreensaver-5.01-r2; thanks.