Bug#1014782: The problem remains
> The DEACTIVATE events I found, that are apparently sent by the Xfce > Power Manager, are not preceeded by xscreensaver-systemd lines, > although other DEACTIVATE lines are, e.g. "inhibited by "chromium"". So > apparently the systemd integration is working, but Xfce isn't using it? Sounds that way! Which is surprising, from reading the code, but not actually a problem, I guess. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1014782: The problem remains
If blanking is being inhibited by dbus, the verbose log will look like this: xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" (:1.48) with "video-playing" cookie "0C765C49" xscreensaver-systemd: 16:54:30: inhibited by "firefox-esr" since Mon Feb 20 16:54:30 2023 xscreensaver-systemd: 16:54:30: exec: xscreensaver-command --verbose -deactivate xscreensaver: 16:54:30: ClientMessage DEACTIVATE: already inactive, resetting activity time xscreensaver-command: already inactive, resetting activity time xscreensaver-systemd: 16:54:32: uninhibited by "firefox-esr" (:1.48) with "video-playing" cookie "0C765C49" If blanking is being inhibited directly, you'll see only the "deactivate" line.
Bug#1014782: The problem remains
On Feb 20, 2023, at 9:44 AM, Celejar wrote: > > It turns out that the DEACTIVATEs were being sent by the Xfce Power > Manager's Presentation Mode. I'm not sure I was even aware of that > mode's existence, but it apparently has a long history of becoming > turned on without the conscious intention or awareness of the user :) Good to know! So, it sounds like you were seeing XFCE invoking "xscreensaver-command -deactivate" directly, is that right? That would have been happening here: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L122 However it looks like that's a fallback, and first it would have tried to connect to DBus, meaning you should have seen diagnostics from xscreensaver-systemd instead: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/blob/2969f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L233 Is xscreensaver-systemd not running for you? -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
> According to upstream, this code is intended to handle errors in > async operations: gdk_x11_display_error_trap_pop_internal() uses > XNextRequest() to get a sequence number for the next X11 request, and > then _gdk_x11_display_error_event() treats sequence numbers between the > start sequence number recorded when the error trap was pushed, and the > end sequence number recorded when it was popped, as having been handled > elsewhere. Oh my god that's an absolutely insane way to go about it. I'm not sure X11 sequence numbers are even guaranteed to be in order, or increase. Anyway, the bottom line is this: one must call XSync before calling XSetErrorHandler. If the GTK devs refuse to add that one line change, well, good luck to you all. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
> I'm not an expert on the finer points of the X11 protocol, so I'm not sure > what this implies. Are you saying that this is (likely to be) the root > cause of the user-visible bug here (xscreensaver-settings not starting), Yes. GTK calls XSetInputFocus (for some unknown reason) and attempts to ignore errors from it (for some other unknown reason, but possibly this very one). That XSetInputFocus call is the one triggering the X error causing xscreensaver-settings to crash. Had GTK ignored the error properly, this would not happen. > In the VM where I reproduced this, xfce4-terminal is working fine, and > some random GTK 3 apps like xfce4-about and xfce4-mouse-settings are also > working normally, so there's some extra factor with xscreensaver-settings > (perhaps just order of operations during startup, or perhaps X11 calls > done via GTK are colliding with direct X11 calls done by xscreensaver). That's unfortunate, but it is all very timing-sensitive, so anything could be throwing that off. > - Then in xscreensaver_window_realize() -> XtDisplayInitialize(), > _XtDisplayInitialize calls XSynchronize(0x5560a9a0, False), > undoing the effect of GDK_SYNCHRONIZE=1 on the connection used by > GTK/GDK/xscreensaver. I think this is why GDK_SYNCHRONIZE had no > effect for you. This makes sense, thanks. In that case, moving the call to XSynchronize to just after the call to XtDisplayInitialize should fix that oddity, at least. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo
> There's actually a good question to ask here. Why, exactly, is xscreensaver > divided up the way that it is in Debian? Two reasons: 1: Because in 1998, some dude wanted to save a few hundred kilobytes on his machine that didn't have a GPU, and had a hard drive an order of magnitude smaller than the one on my keychain. 2: Because the Debian (and Fedora) maintainers enjoy regularly wasting hours of my and their time on obscure bugs where the solution turns out to be "you installed *half* of the application, and nobody has ever tested it that way". It is trivially easy to fix this bug: they don't even have to re-write their build scripts. The problem can be solved with a one-line change: simply make "xscreensaver" depend upon "xscreensaver-data", "xscreensaver-data-extra", "xscreensaver-gl", "xscreensaver-gl-extra", "xscreensaver-screensaver-bsod" and "xscreensaver-screensaver-webcollage" and whatever else is lying around. Leaving out random pieces of XScreenSaver and hoping that it still works is absolutely, explicitly unsupported by me, the author. That the distro maintainers continue to intentionally insist upon screwing things up this way is absolutely baffling to me. I have been begging them to fix this for literally decades. I can *maybe* see the argument for allowing the hacks to be installed without the XScreenSaver daemon, for the case where some other screen saver framework wanted to run them -- except that none of the other extant frameworks can do that. They used to, but that was years ago. However, if the XScreenSaver daemon is installed, then *all* of XScreenSaver must be installed, or else you get all kinds of weird bugs. That is how it was designed, and that is how it was tested. Trying to install bits and pieces of it and hoping that it still holds together DEMONSTRABLY does not work. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo
> Marco and Teoh, out of curiosity, why do you not have xscreensaver-gl > installed on your systems? Because you went out of your way to make it trivially easy for someone to drive their car off the lot with no seat belts or alternator. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo
Wow it's almost like, as I have been saying for years, dividing the single XScreenSaver application that I maintain, test and distribute into multiple bafflingly-named packages that can be left out willy nilly causes repeated, predictable, time-wasting and extremely irritating problems for everybody, while solving no problems whatsoever. Put all of XScreenSaver into one package already, for fuck's sake! -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1031076: Doesn't go to DPMS sleep anymore and settings always disabled
Maybe this fixes it? --- a/driver/demo-Gtk.c +++ b/driver/demo-Gtk.c @@ -1677,6 +1677,7 @@ switch_page_cb (GtkNotebook *notebook, GtkWidget *page, state *s = >state; if (s->debug_p) fprintf (stderr, "%s: tab changed\n", blurb()); + populate_prefs_page (s); pref_changed_cb (GTK_WIDGET (notebook), user_data); /* If we're switching to page 0, schedule the current hack to be run.
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
You may want to report a second bug against GTK, that calling XSynchronize (dpy, True) does not work -- it appears that GTK or GDK are setting that to false at some time later. Proof: Add this to, e.g., update_subproc_timer and run with --debug: XSetWindowBackgroundPixmap (s->dpy, 0, 0); A second or two after startup, this will cause an X error. Backtrace will show a stack that does not include update_subproc_timer or XSetWindowBackgroundPixmap. Add XSynchronize (s->dpy, True); before that line. Now the backtrace is as expected. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
I meant to say: 1: every call to *XSetErrorHandler* has XSync before it, or 2: every *non-blocking* X11 call inside gdk_x11_display_error_trap_push has XSync before it.
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
See also https://github.com/mirror/libX11/blob/master/src/ErrHndlr.c#L38 -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
On Feb 10, 2023, at 5:29 AM, Tormod Volden wrote: > > Here is the code around that XSetInputFocus(): > https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/master/gdk/x11/gdkdisplay-x11.c#L1473 Tl;dr -- it looks like GDK is attempting to call XSetInputFocus and ignore errors from it, but it is doing it wrong. I can't find the definition of gdk_x11_display_error_trap_pop_ignored or even gdk_error_trap_pop_ignored, but assuming that they are the same code as _gdk_x11_error_handler_pop here -- https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/master/gdk/x11/gdkmain-x11.c#L323 that code is uselessly wrong and cannot ever have worked. If you don't call XSync before calling XSetErrorHandler, you have not blocked the error. All XSetErrorHandler does it set a function pointer on the Display object, it does not guarantee that the potential error response has been received. - Set error handler A - X request B generates error - Set error handler C - X requests D - X are sent - X request Z waits for a reply, receives error B - Error handler C is called instead of error handler A Now if you only used gdk_x11_display_error_trap_push and gdk_x11_display_error_trap_pop_ignored around an X11 function that waited for a response -- a "get" function -- that would work because a read implies a flush. But XSetInputFocus does not block. GDK should be changed so that either: 1: every call to XSetInputFocus has XSync before it, or 2: every *non-blocking* X11 call inside gdk_x11_display_error_trap_push has XSync before it. I suspect that with #1 it will be easier to not miss anything. As for why this is happening in XScreenSaver -- I suspect other apps running under this WM will have this problem as well. It would be interesting to try out a few more GTK3 apps and see if the same crash happens there. But it is obviously timing related, so that might not turn up any examples. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
On Feb 10, 2023, at 1:50 AM, Tormod Volden wrote: > > Wait, this was different: What is the X error if you let that continue? -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
> Neither of those changed the backtrace. Hmm. Try setting breakpoints in xscreensaver_app_new, xscreensaver_app_class_init, xscreensaver_app_open, xscreensaver_app_activate, xscreensaver_app_startup, xscreensaver_dialog_init, and xscreensaver_dialog_realize and let's see whether any of those are actually being called before the X error happens. If so, try putting the XSynchronize call there. If not... the X error is happening so early that it must be a GTK or GDK bug? -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
Ugh. Try adding XSynchronize (s->dpy, True); to xscreensaver_window_realize around line 4958, just after s->dpy = gdk_x11_get_default_xdisplay(); It's possible that that won't be early enough to catch it... If not, maybe this in xscreensaver_window_init -- XSynchronize (gdk_x11_get_default_xdisplay(), True); Wayland isn't involved here, is it? xscreensaver-settings should have printed warnings if so. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
You'll need to run with -sync for backtraces of X errors to make any sense. (Seeing XInternAtom in the stack is always an indication that the backtrace is bogus.) xscreensaver-settings doesn't do anything with focus, though, so this is still confusing. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030659: xscreensaver: segfault when starting xscreensaver-settings or xscreensaver-demo
Not having a GL visual reported here is definitely a problem in the "should never happen" category, so trying to figure out where that's going wrong would be helpful. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1030801: xdaliclock no longer honors -font or -geometry command line switches
Things change. Intentionally. It's better now. Adjust and move on with your life.
Bug#1028029: xscreensaver: contains non-free fonts
On Jan 6, 2023, at 1:50 AM, Bastian Germann wrote: > > But there is a version available at > https://sourceforge.net/projects/ocr-a-font/ that might be free. > You can certainly replace it. This one seems better than that one: https://tsukurimashou.osdn.jp/ocr.php.en Annoyingly, the name changes from "OCR A Std" to "OCR A".
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
You are making this all needlessly complicated. Each distro should have exactly one xscreensaver package which contains exactly one app-defaults file, with whatever patches are necessary to that. Which should be "just about none", as configure should have figured out the correct settings for things like newLoginCommand.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
No. There should be exactly one XScreenSaver package. So, so many problems have stemmed from this incomplete, broken installations as a result of this ridiculous extras-data-extras-gl-extras-extras nonsense. I am decades weary of hearing about them.
Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting
Yes, it is critical that the version of /usr/lib/X11/app-defaults/XScreenSaver actually correspond to the version of XScreenSaver that is installed. I would have thought this to be obvious. If the file does not exist at all, things *should* work ok, but having an old version there is definitely going to screw everything up. So just install it. Any solution that involves *increasing* rather than *decreasing* the number of packages that comprise XScreenSaver is an asinine solution.
Bug#1028029: xscreensaver: contains non-free fonts
Correction, Gallant is in fact BSD licensed: http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev/wsfont/gallant12x22.h
Bug#1028029: xscreensaver: contains non-free fonts
False. Luxi Mono is from Red Hat, I'm sure you've heard of them. OCRA is an ANSI Standard, and is public domain. Gallant is a reproduction of the Sun font created by Joshua M. Clulow and released, as far as I am aware, into the public domain.
Bug#1027999: xscreensaver: xscreensaver-systemd does not start: "inhibit sleep failed: Permission denied"
What does polkitd do, and why does xscreensaver-systemd fail without it? I gather it has something to do with "org.freedesktop.PolicyKit1" but I can't tell what that's for either, and xscreensaver-systemd does not explicitly use it.
Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent
Congrats, you are well on your way to understanding that Linux is a trash fire all the way down! On Sep 26, 2022, at 11:07 AM, Stefan Monnier wrote: > > Oh, it's worse: I installed `picom` which made the opacity slider work, > but that affects the whole window, whereas I only want the background to > be transparent. > > Along the way I noticed another problem with the opacity compared to the > old code that relied on the "Shape" X11 extension: even if I can use the > "opacity" setting to let me see my windows underneath the clock, > clicking in the background of the clock sends the even to the clock > rather than to the underlying window :-( > > >Stefan
Bug#1020460: xdaliclock: New version ignores Xresource settings and can't be made transparent
Less snarkily: none of these things can or will be fixed. Adapting xdaliclock to more modern toolkits in order to have fully scalable antialiasing and a real GUI for preferences has some other side effects. If you want to party like it's 1991, run the code from 1991. It still exists.
Bug#1019516: xscreensaver: New version available upstream
Please make sure you grab xscreensaver-6.05.1.tar.gz if you already grabbed the other one; there was a last minute fix.
Bug#774668: xscreensaver: check libxss-dev:XScreenSaverQueryInfo() during idle loop
>> xscreensaver does not use the MIT SCREEN-SAVER server extension >> because it is a flaky, unreliable piece of shit that tends to cause >> the sever to crash. > > Is it still the case after 7 years? I suppose somewhere in the multiverse there is a world where the MIT-SCREEN-SAVER extension is under active development. In our universe, that code almost certainly hasn't been touched since the 90s. XScreenSaver does not and will not use that server extension. Install XScreenSaver 6.04 and then "man xscreensaver-systemd". -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1012840: xscreensaver-systemd doesn't exit at end of Xfce session
On Jun 26, 2022, at 5:43 AM, Sergio Gelato wrote: > >> Huh. Well, xscreensaver-systemd calls XOpenDisplay specifically to make this >> happen > > I see that there is code to that effect in version 6.04 (it seems to have > first appeared in 6.00, although I see no mention of it on the What's New > page), but (as indicated on the Version: line) this bug report is against the > version in Debian stable (5.45). I take it that you would suggest backporting > a newer version (6.02 is in Debian testing) or cherry-picking the change? Oh, for fuck's sake, this is why I have, for years now, requested that Debian simply *stop shipping XScreenSaver*. I am so sick to death of this continuous bullshit of "well, there's a bug in your software from two years and six releases ago." To Debian as a whole, please, I beg of you, stop wasting my fucking time with this bullshit. To Sergio: before you submit a bug report in anything, UPGRADE. Not to the version that some slacking upstream asshat has made easily available to you, but to the ACTUAL LATEST VERSION. https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/ -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1012840: xscreensaver-systemd doesn't exit at end of Xfce session
On Jun 26, 2022, at 1:59 AM, Sergio Gelato wrote: > >> The display connection that both xscreensaver and xscreensaver-systemd have >> open will close with SIGPIPE. > > This does not match my observations. xscreensaver does appear to have a > connection to the X server, but xscreensaver-systemd does not. (It seems to > have connections to DBus instead.) Huh. Well, xscreensaver-systemd calls XOpenDisplay specifically to make this happen, and when I run xscreensaver-systemd and then kill the X server, I get this: # ./xscreensaver-systemd -v xscreensaver-systemd: 02:07:08: registered as "org.jwz.XScreenSaver" xscreensaver-systemd: 02:07:08: registered as "org.freedesktop.ScreenSaver" xscreensaver-systemd: 02:07:08: "org.gnome.SessionManager" not in use xscreensaver-systemd: 02:07:08: "org.kde.Solid.PowerManagement.PolicyAgent" not in use [ kill server ] xscreensaver-systemd: 02:07:26: X connection closed Exit 1 -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1012840: xscreensaver-systemd doesn't exit at end of Xfce session
I don't see how this is possible. When the user logs out, the X server exits. The display connection that both xscreensaver and xscreensaver-systemd have open will close with SIGPIPE. Send logs. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#1009864: xscreensaver: firefox stops (inhibits) xscreensaver from firing. Needs option to ignore firefox
> people want firefox, when playing a video, to inhibit xscreensaver. "Monkey paw curls." > Only problem is I'm not playing a video. Unfortunately, the net is full of > ads, so pretty much every page claims to be "playing a video". Yeah, that's awesome, isn't it? I had been under the impression that the bug you are describing only happened with Chromium, not with Firefox. Here's an excerpt from the tragically-long comment at the top of xscreensaver-systemd.c: * Twitter (and many other sites) auto-convert GIFs to looping MP4s to * save bandwidth. Chromium inhibits the screen saver any time a Twitter * GIF is on screen (either in the browser or in Tweetdeck). * * The proper way for Chrome to fix this would be to stop inhibiting once * the video loops. That way your multi-hour movie inhibits properly, but * your looping GIF only inhibits for the first few seconds. Firefox, Chrome and Chromium also all will leave the screen permanently inhibiited if they crash, too, which is great. And Firefox, Chromium and MPV inhibit screen blanking when only *audio* is playing, which makes no damned sense at all. So, if someone could report bugs against those applications, that would be great. Also, so that I'm clear on exactly what is happening, can you do a test with Firefox and see if what is going on is, in fact, that it treats any 2-second looping MP4 thumbnail as "playing a movie"? Finding any looping GIF on Twitter is a good way to test it. Then navigate away from that page and see if it uninhibits. I believe that Firefox didn't used to do this, so it would be interesting to know when they started. > I just want to be able to tell xscreensaver to ignore any calls from this > list of programs: > > 1) firefox-esr > > Oh look at that, end of list. Oh ho ho ho, the list of other programs that fuck this up is so much longer than that. It's basically all of them. Your best bet is probably just "rm xscreensaver-systemd". This will unfortunately have the side effect that your screen will not auto-lock when you close the laptop lid. > Yes, I know the proper fix is to tell firefox to give me an option to not > inhibit the screensaver That's not actually the fix, it's just that they are inhibiting it in the stupidest possible way. Maybe "be less stupid" will get more traction than "stop". We can dare to dream. -- Jamie Zawinski • jwz.org • dnalounge.com
Bug#961129: xscreensaver should not search for screensaver executables in PATH
It has been another 5 months with no response. I am once again *begging* you to stop making it possible to install only *part* of XScreenSaver. It causes a constant stream of problems for no benefit. Please, please, please, install the dependencies so that installing any part of XScreenSaver installs *the entire program* as I have designed and tested it. This requires only a one line change to your dependency list. Your continued refusal to do this keeps causing problems for everybody, including me. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#1007724: xscreensaver: xscreensaver-auth says it should be installed setuid root
There is no debate about this. It is insecure and irresponsible for xscreensaver-auth to *not* be setuid root. Install it setuid root, as it was designed to be, and as "make install" does by default.
Bug#1004947: xscreensaver: still happening in version 6.02+dfsg1-2
https://www.jwz.org/xscreensaver/faq.html#typeahead • I used to be able to start typing my password before the unlock dialog had appeared, but now I have to wait for the prompt. This is an inevitable consequence of the new security model introduced in XScreenSaver 6.00. The old behavior will not be returning, so get used to clicking the mouse or tapping "Shift" before you start typing your password. Just typing blindly had always been bad opsec anyway: if the screen was only blanked but not locked, you probably would have accidentally typed part of your password into another window.
Bug#1004946: Cannot hold down backspace to delete password
> Why did you switch to it? Or am I misunderstanding that you did? For the new security model. No other way to increase the privilege separation. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#1004946: Cannot hold down backspace to delete password
When an X11 client reads X11-core events of type KeyPress and KeyRelease, a held-down key will result in a series of synthetic release/press events to make it look like the key was pressed multiple times. The initial delay and repeat rate are configured in the X server by xset and/or xkbset. Also, not all keys auto-repeat. When that same X11 client reads XInput2-extension events of type XI_RawKeyPress and XI_RawKeyRelease, a held-and-released key results in exactly 2 events, no matter how long it was held. The XInput2 server extension ignores the server auto-repeat settings. It is unreasonable to expect an X11 client to hack auto-repeat by itself. This is a server-side configuration issue. Also this is far from the only problem with XInput2's keyboard event handling. See the comments in xscreensaver/driver/xinput.c for a laundry list of its bugs. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#1004946: Cannot hold down backspace to delete password
On Feb 11, 2022, at 8:51 AM, Daniel Kahn Gillmor wrote: > > If the regression is caused by changes in how XInput/XInput2 behave, > then maybe this problem should be addressed in that package. I'm > reassigning this report there and marking that it affects xscreensaver. I have no reason to believe that XInput2 has not always behaved that way. You are noticing it now because XScreenSaver only began using XInput2 as of 6.x. Stating the problem/annoyance more concisely: XInput2 does not send auto-repeat press/release events in the same manner as XNextEvent. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#1004947: Loses keystrokes until dialog displayed
https://www.jwz.org/xscreensaver/faq.html#typeahead This is an inevitable consequence of the new security model introduced in XScreenSaver 6.00. The old behavior will not be returning, so get used to clicking the mouse or tapping "Shift" before you start typing your password. Just typing blindly had always been bad opsec anyway: if the screen was only blanked but not locked, you probably would have accidentally typed part of your password into another window.
Bug#1004946: Cannot hold down backspace to delete password
For some reason, the XInput2 extension doesn't auto-repeat certain keys that used to auto-repeat when read the "old" way. Unfortunately there's nothing I can do about this. I process only the keystrokes that I receive. However you can use the traditional keystrokes ^U and ^X to clear the whole line. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
Well, I'm confused about how it got from "blanking" to "unblanking" without printing why active_at changed. Please try logging with -vvv -log to make sure it's printing everything. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
I don't understand why you are having trouble logging with 6.02. Did you launch it as xscreensaver -v -log log.txt? Investigating this in 5.x will not be helpful, because the flow of control is completely different with 6.x's new security model.
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
On Nov 7, 2021, at 10:31 AM, Lionel Élie Mamane wrote: > >> I couldn't immediately reproduce the behaviour I as complaining >> about within a few minutes, also not with 5.45. (...) I will make >> longer (e.g. overnight) tests. > > I reproduced the issue with 5.45 and more patience, on the scale of > ten minutes. The attached log file is from 5.45 and contains at least > two occurrences, about 10 minutes apart. The screen spontaneously > turns back on, and back off after about 3 minutes, the configured idle > time to DPMS off. I don't know what "about ten minutes apart" means without you saying actual timestamps, but that log file shows the screen powering on due to user activity: > xscreensaver: 18:48:06: user is active (keyboard activity) > ... > xscreensaver: 19:25:42: user is active (mouse motion) -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#997794: xscreensaver: systemd integration leads to spurious deactivations (unblank) on desktop
First, upgrade to 6.02. Then, run xscreensaver with -log to see what's going on. Probably some other app is trying to disable blanking while locked. > Killing the "xscreensaver-systemd" process fixed it. Being an > always-running desktop, it is never suspended, so from reading its man > page, I gather xscreensaver-systemd doesn't do anything useful for > that particular machine. xscreensaver-systemd is also the mechanism by which most movie players and web browsers tell XScreenSaver to not blank the screen while a video is playing. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#961129: xscreensaver should not search for screensaver executables in PATH
You could solve this problem with a one-line change: simply make "xscreensaver" depend upon "xscreensaver-data", "xscreensaver-data-extra", "xscreensaver-gl", "xscreensaver-gl-extra", "xscreensaver-screensaver-bsod" and "xscreensaver-screensaver-webcollage". I can see the argument for allowing the hacks to be installed without the XScreenSaver daemon, in case some other screen saver framework wanted to run them (do any of the other frameworks still support that? I don't think so?) However, if the XScreenSaver daemon is installed, then *all* of XScreenSaver must be installed, or else you get the "zoom" problem and related. That is how it was designed, and that is how it was tested. Trying to install bits and pieces of it and hoping it still holds together demonstrably does not work. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#961129: xscreensaver should not search for screensaver executables in PATH
On Oct 13, 2021, at 4:36 AM, Tormod Volden wrote: > > I was obviously talking about what to do in the Debian package, not > upstream. So was I. I was discussing *your* decisions that make *my* program malfunction for *my* users, and cause more work for *me*, the author and maintainer. > I think it makes sense for us to not blindly pick whatever is in the user's > PATH. You are absolutely 100% wrong. Do not make this change. Many things will malfunction. Do not make the mistake of forking my program even more than you already have. That does not go well for any of us. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#961129: xscreensaver should not search for screensaver executables in PATH
On Oct 12, 2021, at 4:53 AM, Tormod Volden wrote: > > I agree to "xscreensaver SHOULD search for screensavers only in > /usr/lib/xscreensaver, Well, you're wrong, and I'm not going to do that. The fix is *simple and obvious*, make there be ONE xscreensaver installer package instead of FIVE -- one that installs *all* of XScreenSaver instead of only bits and pieces and expecting that to still work. I cannot comprehend why you continue to refuse to implement this trivial fucking fix. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#988158: xscreensaver regularly crashes, leaving screen unlocked
An XIO error means that the server dropped our connection, as opposed to the client making an invalid request, which is weird. Usually IO errors only happen when the X server crashes. Maybe it's a driver bug? Maybe you're running out of memory? (Though typically the server sends a more sensible X error than this when out of memory.) However, the XScreenSaver daemon does not use XSHM, so that error message is probably coming from the display mode, not the daemon. A crash in the display mode won't cause the daemon to exit and the screen to unlock. As always, the only way to figure this out is if you include all of the output of -log. Also, you're running 5.45 instead of 6.00 and if you can't reproduce it in 6.00 there's no point in investigating any further. So try that. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#987149: xscreensaver: allows starting external programs with cap_net_raw
As I said, it's already fixed in 6.00. The fix is just to configure without setcap and use setuid instead, which works properly with Mesa. I assume that having 6.00 distributed by Debian prior to 2035 would be asking too much, but we dare to dream.
Bug#987149: xscreensaver: allows starting external programs with cap_net_raw
Already fixed in XScreenSaver 6.00. The bug is in Mesa: it has a panoply of env vars that do what LD_PRELOAD does, except Mesa only checks geteuid instead of checking getauxval AT_SECURE, as the kernel does. So anything that uses both Mesa and setcap is vulnerable. Ironically, using setuid instead of setcap does not have the vulnerability.
Bug#979562: lightdm session termination does not stop xscreensaver
> my .icewm/startup file at the moment contains: > > xscreensaver -nosplash -log wtf-xscreensaver.txt & > > When icewm starts, I see the splash screen for a brief moment (not joking, > looks -nosplash has no effect there), but it does not happen every time. This kinda sounds like *something else* is launching xscreensaver at the same time, and whatever that is is doing it without -nosplash. The two of them racing would explain the "already running" error. > Or, if run ps quick enough before it's killed, I see: > > user 3904 0.0 0.0 5712 1128 ?SN 21:13 0:00 > xscreensaver-systemd -verbose > lightdm11997 0.1 0.0 18948 5952 ?Ss 21:55 0:00 > xscreensaver > lightdm12068 0.0 0.0 5712 1128 ?SN 21:55 0:00 > xscreensaver-systemd > user 12416 0.0 0.0 3748 664 pts/0S+ 21:56 0:00 grep saver Note that pid 11997 does not have -nosplash on its command line. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
> Why would a xscreensaver instance running for user A have any influence on a > xscreensaver instance running for user B? That seems absolutely weird to me > and something I don't understand. Yeah, that sounds impossible, assuming that the X server has restarted between user A and user B. If things have gone wrong in a weird way, the "xscreensaver-systemd" process of user A might linger, but it won't be able to communicate with user B's xscreensaver. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
On Jan 10, 2021, at 3:20 AM, Tormod Volden wrote: > > For a multi-user host the administrator expectations are different, since > there might be various login managers and user desktop environments, and > xscreensaver should only run in some of them. I would think that if an administrator installed xscreensaver on a multi-user system, the expectation would be for it to run in all graphical login sessions. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#979562: lightdm session termination does not stop xscreensaver
> In xscreensaver (or maybe lightdm). > Why is xscreensaver started in the lightdm session anyway? > Is xscreensaver really usable as a per user service or should it be per > session? > Why is the lightdm xscreensaver instance interfering with the xscreensaver > instance of the logged in user? > Questions that only the xscreensaver maintainer can answer. > > If he thinks there is a genuine systemd issue, then I'd appreciate if it was > reassigned back with more details. XScreenSaver author here. I know nothing about lightdm, and didn't write the code attempting to integrate the two. However: 1) XScreenSaver should be running as the logged-in user, and terminate when they log out. Typically this happens when the X server dies and the $DISPLAY socket is closed, but SIGTERM works just as well. 2) It is also reasonable to configure things so that XScreenSaver is running when no one is logged in (so that there is a screensaver atop the login screen). If it is launched as root, it will setuid to "nobody" at startup, etc. But in this case, when a user logs in, it must be killed and re-started as that user.
Bug#978589: systemd based startup not working
On Jan 2, 2021, at 2:52 AM, Eduard Bloch wrote: > > I don't have enough information to judge here. What I see is that the > xscreensvaer logo appears twice, i.e. when the lightdm screen comes and > when the xsession starts. When I check on the process list briefly in > those first seconds, there is: Ok, that's different! You mean the splash screen? If you're seeing that, then it did manage to connect to the X server! This is all very strange, I'm not sure what's going on. I guess I'd try to coerce more logs out of everything involved? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
> created. With absolute path, it is created but then it's created by > lightdm user first and then maybe the user session cannot replace it. Ok, that definitely means you're running as the wrong user, which explains why .Xauthority is not readable. Though why the earlier xscreensaver log said you were running as the correct user is confusing. Unless that log was from before this problem began. > Ok. Is this supposed to be gone when user logs out? Does this interfere > with my trying different parameters (-log, --log, etc.) above, are those > cached and therefore ignored after subsequent changes? xscreensaver-systemd should be killed by xscreensaver when it exits, but it's definitely not a part of the problem that you're experiencing right now. > ## > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 30 > 19:08:25 2020 > ## No "running as" line in this log? > Just guessing, is this maybe some bug of xscreensaver-systemd which > makes it request an early shutdown of xscreensaver? No, all "xscreensaver-systemd" does is occasionally run "xscreensaver-command". You are not getting that far. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
> Once logged in, I can see some active process of xscreensaver (this is what > "pidof xscreensaver" tells me). > > But after some seconds, this process is gone. Why? Don't know. Dunno. Maybe it's trying to connect and timing out. Run xscreensaver with --log log.txt Or if you have an old version, -verbose -no-capture -log log.txt > 2884 0.0 0.0 5716 1064 ?SN 01:13 0:00 xscreensaver-systemd > > The manpage of this binary is slightly confusing. That is some kind of > helper, fine, but who is supposed to run it? Xsession? Or systemd user > session? It mentions "When run from ~/.xsession or equivalent" but there > is no information on what is considered "equivalent" here. It is launched by xscreenasver itself. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Service has > more than one ExecStart= setting, which is only allowed for Type=oneshot > services. Refusing. > Dez 30 01:13:20 whitestar systemd[2605]: xscreensaver.service: Cannot add > dependency job, ignoring: Unit xscreensaver.service has a bad unit file > setting. Sounds like it doesn't like your edits? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978589: systemd based startup not working
The fact that $DISPLAY is not set at the time xscreensaver is launched is not a good sign. The cookie error suggests that ~/.Xauthority does not exist or is not readable. However you do appear to be running as yourself, not as "nobody". Perhaps $HOME is set to something weird? Maybe try setting your command to "printenv ; pwd ; xdpyinfo ; xscreensaver" and see if that provides some clues.
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
> I've found the reason why xfonts-100dpi wasn't working for me: > on startup, the X server removes unexisting directories from the > default FontPath AHA! That explains it! Thanks for figuring that out. After installing both xfonts-100dpi and gsfonts-x11 and restarting X, I get: xset q | grep font /usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,built-ins And after that, having •either* xfonts-100dpi or gsfonts-x11 installed makes both xterm and xscreensaver have correct fonts. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
With only gsfonts-x11, I get the same results as you for find /usr -name fonts.alias | xargs grep -i 'helvetica-bold-r-' and find /usr -name fonts.dir | xargs grep -i 'urw-nimbus.*bold.*iso8859-1$' and dlocate n019004l.pfb and yet xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' does not work. So there must be some *other* thing installed on your system that is not installed on mine that is making Xlib Helvetica work. I don't know what that is. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
So, on your system where: - xfonts-100dpi is not installed - gsfonts-x11 is installed - xterm uses Helvetica with: -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' What do you get from: find /usr -name '*helvB18*' find /usr -name fonts.dir | xargs grep -i 'helvetica-bold-r-.*180' And of the matched font files, what packages are they from? E.g.: % apt-file search /usr/share/fonts/X11/100dpi/helvB18.pcf.gz xfonts-100dpi: /usr/share/fonts/X11/100dpi/helvB18.pcf.gz -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
> On my machine, if only gsfonts-x11 is installed, then everything is nice. Not here. > But if only xfonts-100dpi is installed, I get a tiny, unreadable font Also, not here. > It seems that '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' does not > exist in xfonts-100dpi, dpkg-query -L xfonts-100dpi | grep helvB18 /usr/share/fonts/X11/100dpi/helvB18.pcf.gz /usr/share/fonts/X11/100dpi/helvB18-ISO8859-1.pcf.gz > I think that you should fix font selection, and choose a default font > that will yield reproducible results. Easy for you to say! -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
On Dec 26, 2020, at 3:45 AM, Vincent Lefevre wrote: > > I'm wondering whether this could be gsfonts-x11. Nope, I get crappy fonts in xscreensaver and xterm with: apt remove xfonts-base xfonts-100dpi apt install gsfonts-x11 -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
> With only xfonts-base, I get something similar to the correct version. > And installing xfonts-100dpi doesn't make any difference. > > So I suppose that xfonts-base should be recommended instead of > xfonts-100dpi, since this is what appears to be the default. On my Raspian 10.6 system, installing "xfonts-base" and uninstalling "xfonts-100dpi" results in the crappy version, with no useful fonts being found. I have only seen it work properly when "xfonts-100dpi" is installed. Regardless of which font packages are or are not installed, I get this from xlsfonts: xlsfonts -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' -adobe-helvetica-bold-r-normal--25-180-100-100-p-0-iso8859-1 -adobe-helvetica-bold-r-normal--25-180-100-100-p-138-iso8859-1 -adobe-helvetica-bold-r-normal--25-180-100-100-p-138-iso8859-1 That probably means that xlsfonts is reporting that it is available in scaled form, even though it is not available in bitmap form. That is to say, while it may work with XftFontOpenXlfd, it does not work with XLoadFont. Tested with "xterm" as well as with with xscreensaver; xterm gets the font with "xfonts-100dpi" but not without: xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' So perhaps there is something else loaded on your system that is making Xlib able to find Helvetica and Courier. But it's not "xfonts-base" that is doing that. apt list --installed '*font*' Listing... Done fontconfig-config/stable,now 2.13.1-2 all [installed,automatic] fontconfig/stable,now 2.13.1-2 armhf [installed,automatic] fonts-dejavu-core/stable,now 2.37-1 all [installed,automatic] fonts-dejavu-extra/stable,now 2.37-1 all [installed,automatic] fonts-dejavu/stable,now 2.37-1 all [installed,automatic] fonts-droid-fallback/stable,now 1:6.0.1r16-1.1 all [installed] fonts-freefont-ttf/stable,now 20120503-9 all [installed,automatic] fonts-liberation2/stable,now 2.00.5-1 all [installed] fonts-noto-mono/stable,now 20181227-1 all [installed,automatic] fonts-piboto/testing,now 1.2 all [installed,automatic] fonts-quicksand/stable,now 0.2016-2 all [installed,automatic] fonts-sil-gentium-basic/stable,now 1.102-1 all [installed,automatic] fonts-sil-gentium/stable,now 20081126:1.03-2 all [installed,automatic] gsfonts/stable,now 1:8.11+urwcyr1.0.7~pre44-4.4 all [installed,automatic] libfont-afm-perl/stable,now 1.20-2 all [installed,automatic] libfontconfig1-dev/stable,now 2.13.1-2 armhf [installed,automatic] libfontconfig1/stable,now 2.13.1-2 armhf [installed,automatic] libfontembed1/testing,now 1.21.6-5+rpt1 armhf [installed,automatic] libfontenc1/stable,now 1:1.1.3-1 armhf [installed,automatic] libxfont2/stable,now 1:2.0.3-1 armhf [installed,automatic] timgm6mb-soundfont/stable,now 1.3-2 all [installed,automatic] xfonts-100dpi/stable,now 1:1.0.4+nmu1 all [installed] xfonts-encodings/stable,now 1:1.0.4-2 all [installed,automatic] xfonts-utils/stable,now 1:7.7+6 armhf [installed,automatic] -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#978086: xscreensaver: should use scalable fonts by default and not depend on bitmap fonts
The screen savers themselves use XFT and scaled fonts, if available. The xscreensaver daemon does not, as it uses only Xlib, and links as few libraries as possible for security reasons. Without Xlib bitmap fonts, the text on the unlock dialog won't display properly.
Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames
The reason remote.c includes @hostname on the XA_SCREENSAVER_ID is to detect the case when "xscreensaver" and "xscreensaver-demo" are running on different hosts, because if they are different hosts, they are likely different file systems for the home directory. Your first patch disables this check. I still don't understand why a user name would have an @ in it in the first place, so I can't comment on the rest. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#932837: xscreensaver: No text on lock screen
> I find it strange, if I read it correctly, that it first succeeds > to replace the -*-helvetica-bold-r-*-*-*-140-*-*-*-*-iso8859-1 font > (with -*-*-medium-r-*-*-*-140-*-*-p-*-iso10646-1) twice but fails the > third time… I think the output is still truncated on that third attempt. It should end with either a line saying "substituted" or saying "unable to find any alternatives". If you run with -no-capture-stderr that should stop the truncations, hopefully. However, I thought you said that things were working ok with the self-compiled version, and it was the package-installed version where the fonts were blank? Do these commands return usable fonts? These are the fallback font patterns that it tried as a last resort, since your system has *none* of the other standard X11 fonts installed: xlsfonts -fn "-*-*-medium-r-*-*-*-140-*-*-p-*-iso10646-1" xlsfonts -fn "-*-*-medium-r-*-*-*-180-*-*-p-*-iso10646-1" Maybe test with "xterm -font " -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#932837: xscreensaver: No text on lock screen
> Well, that “set of garbage fonts” is fine for XScreenSaver 5.36… I assure you, I did not write all that code for shits and giggles, but to fix an actual problem people were experiencing on font-bereft systems like yours. >> so it would be helpful if you send me the output of xlsfonts on your >> system where it's doing something terrible. > > Here it is. Well, that set of fonts is, in fact, garbage, but I think it should have fallen back to -misc-fixed-medium-r-normal-*-*-*-*-*-c-*-iso10646-1 -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#932837: xscreensaver: No text on lock screen
XScreenSaver (as of 5.42) tries really hard to do something sensible with whatever set of garbage fonts you happen to have installed, so it would be helpful if you send me the output of xlsfonts on your system where it's doing something terrible. Is there anything about fonts in the log output of xscreensaver -verbose -log log.txt ? If you're feeling adventurous, rebuilding with DEBUG defined in utils/font-retry.c and sending me the output of a run with that version might be helpful. Though I guess that if the self-compiled version does not exhibit the problem, that won't help.
Bug#953098: xscreensaver: Crashes with XIO: fatal IO error
For best logging: xscreensaver -verbose -log log.txt
Bug#953098: xscreensaver: Crashes with XIO: fatal IO error
As far as I know, an XIO error means the X server dropped the connection to the xscreensaver client. So either the X server itself crashed, or it decided to disconnect xscreensaver for some unknown reason. If the client had done something wrong, X11-protocol-wise, this would have been a more verbose "X" error, not an "XIO" error. Maybe this is the kernel OOM-killer shooting down random long-running processes, as it sometimes likes to do? "Resource temporarily unavailable" sure sounds like it could be the X11 server trying to say that it ran out of memory.
Bug#781961: systemd-logind integration for XScreenSaver
> Jamie, if there is a way to sync on the X server actually completing its > work, then we could do that instead. xscreensaver-command uses XSendEvent to send the ClientMessage to xscreensaver; it then waits up to 10 seconds for a response message to be written to the window. However, that the response is sent when xscreensaver has *begun* the process of blanking the screen, not after. It's probably only a few hundred instructions, but there are a couple of X11 round-trips before that window shows up. Also recall that if the user has "fade" turned on, blanking the screen could involve a multi-second animation. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#781961: systemd-logind integration for XScreenSaver
Actually, I think you're right: DEACTVIATE was not forcing the monitor to be
powered on.
I'd like to include your code with the next xscreensaver release if that's ok
with you -- is the latest version on GitHub what you'd like to go with?
Thanks!
--- a/driver/xscreensaver.c
+++ b/driver/xscreensaver.c
@@ -1831,6 +1831,11 @@ handle_clientmessage (saver_info *si, XEvent *event,
Bool until_idle_p)
}
else if (type == XA_DEACTIVATE)
{
+
+ /* Regardless of whether the screen saver is active, a DEACTIVATE
+ message should cause the monitor to become powered on. */
+ monitor_power_on (si, True);
+
# if 0
/* When -deactivate is received while locked, pop up the dialog box
instead of just ignoring it. Some people depend on this behavior
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#781961: systemd-logind integration for XScreenSaver
Wow, this seems like a huge amount of code to do such a simple thing! Is that... normal? Is this really how insane the world has gotten? Also: I thought that -deactivate would power on the screen by itself, so that xset isn't necessary? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
> but I think those are all using TrueType fonts via fontconfig/etc, not > "traditional" X11 fonts. Ok but "traditional" X11 is perfectly capable of using TrueType fonts, server-side, XLoadFont-style. On my system (your paths will vary) -- % xlsfonts -ll -fn '-bitstream-bitstream vera serif-medium-r-normal--0-0-0-0-p-0-iso10646-1' | grep NAME FAMILY_NAME bitstream vera serif WEIGHT_NAME medium SETWIDTH_NAME normal ADD_STYLE_NAME FACE_NAME Bitstream Vera Serif _ADOBE_POSTSCRIPT_FONTNAME BitstreamVeraSerif-Roman RASTERIZER_NAME FreeType % find /opt/X11/share/fonts -type f | grep -i verase /opt/X11/share/fonts/TTF/VeraSe.ttf /opt/X11/share/fonts/TTF/VeraSeBd.ttf % xterm -fn '-bitstream-bitstream vera serif-medium-r-normal--17-120-100-100-p-107-iso10646-1' ...works! -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
> I've re-collected the debug output from the prior round of this from the
> clean restart of the X server in the hopes that might help provide less
> confusing diagnostics. Notably now helvetica doesn't appear at all in the
> output of xlsfonts.
Yeah you definitely need to run the font tests on the same instance / run in
which xscreensaver is exhibiting problems...
> -arabic-newspaper-medium-r-normal--19-140-100-100-p-0-iso10646-1
I'm gonna guess that this font, despite claiming to be 10646 (Unicode) does not
actually contain Latin characters... So that's not ideal if your locale is set
to one that requires those.
It looks like you've got a smattering of Arabic and Japanese fonts, but all of
your Latin fonts are fixed-width! Is that intentional? By which I mean is, did
you do this on purpose or is your distro doing this by default for some reason?
Maybe you manually deleted some package that you shouldn't have?
Are any of your apps capable of displaying Latin letters in variable width? If
so, my next question will be, what font are those apps finding and how?
The following patch might help: this will remove the wildcard font-family
fallback, which should result in the xscreensaver dialogs being in "fixed"
instead of that Arabic font. But I'd still like to understand how your machine
got into this state, and how likely it is that others will also be dealing with
similar configurations.
diff --git a/utils/font-retry.c b/utils/font-retry.c
index ab999e2b..66b827f4 100644
--- a/utils/font-retry.c
+++ b/utils/font-retry.c
@@ -114,7 +114,8 @@ load_font_retry_1 (Display *dpy, int screen, const char
*xlfd, Bool xft_p)
"american typewriter",
"fixed",
"ocr a std",
- "*" };
+ /* "*" */
+ };
const char *variable[] = { "helvetica",
"arial",
"bitstream vera sans",
@@ -126,7 +127,8 @@ load_font_retry_1 (Display *dpy, int screen, const char
*xlfd, Bool xft_p)
"palatino",
"lucida",
"bitstream charter",
- "*" };
+ /* "*" */
+ };
const char *charsets[] = { "iso10646-1", "iso8859-1", "*-*" };
const char *weights[] = { "bold", "medium" };
const char *slants[] = { "o", "i", "r" };
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
Ok, I'm not really sure what's going on here. Both of these fail: xscreensaver: failed -*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1 xscreensaver: trying -*-helvetica-bold-r-*-*-*-180-*-*-p-*-iso10646-1 And they should not, because look, they're right there: -adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso10646-1 -adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1 -adobe-helvetica-bold-r-normal--25-180-100-100-p-138-iso10646-1 -adobe-helvetica-bold-r-normal--25-180-100-100-p-138-iso8859-1 What do you get with: xlsfonts -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' xlsfonts -fn '-adobe-helvetica-bold-r-normal--0-0-100-100-p-0-iso8859-1' Does text show if you do: xterm -fn '-*-helvetica-bold-r-*-*-*-180-*-*-*-*-iso8859-1' (The spacing will be weird because it's expecting fixed with, but "ls" should produce at least some readable words.) Possibly the problem is that your font cache needs to be regenerated with fc-cache? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to
To be clear: my intention is to ignore this trivial problem.
Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to
> From a user point of view, if I say that you should not look for image > files to display, you should just not do that. This is a bug in > Xscreensaver. There is no good reason why it should give an error. With your settings, the only option is to change the failure mode from "print an error message as text", to "don't print any text and just display colorbars or black instead". Doesn't seem like much of an improvement to me. So I'm not gonna spend time on that.
Bug#699392: xscreensaver requires xfonts-100dpi or xfonts-75dpi
Xscreensaver 5.42 tries really hard to do something sensible with whatever set of garbage fonts you happen to have installed, so it would be helpful if you send me the output of xlsfonts on your system where it's doing something terrible. If you're feeling adventurous, rebuilding with DEBUG defined in utils/font-retry.c and sending me the output of a run with that version would also be helpful.
Bug#914109: xscreensaver-data: looks for image files to display even though it is told not to
Well, there's no way for glitchpeg to work on your desktop image, because your desktop is not a jpeg...
Bug#910612: xscreensaver should clean out it's pic cache
Cache times out after 3 hours, or the first time no suitable images are found.
Bug#781961: ditto
If you know of a way to run an X11 application without using libx11, let me know. I'm not going to argue about this any further. I've explained how you can solve your problem: write a shell script that locks xscreensaver between "lid closed" and "cpu halted". If that shell script talks to dbus, or does not talk to dbus, that's great either way. Linking additional libraries into the xscreensaver daemon is never, ever, ever going to happen, and if my explanation of why does not satisfy you, I guess we'll both just have to live with that.
Bug#781961: ditto
It is not my responsibility to secure Debian's laptop power management system. It is not my responsibility to integrate xscreensaver with Debian's laptop power management system. It is my responsibility to make *xscreensaver* as secure as it can be. It is my judgement that linking with additional massive, someone's-learning-experience libraries like dbus does exactly the opposite of that. Again, you have my sympathies that the operating system you choose to use treats security as an afterthought.
Bug#781961: ditto
There is absolutely no chance in hell that the xscreensaver daemon will ever, ever link with dbus. Over my dead body. For all of these reasons: https://www.jwz.org/xscreensaver/toolkits.html If you can craft some shell script that fixes the problem you are experiencing without modification to the xscreensaver daemon, great. If you can't, then you (and all Linux users) have my ongoing sympathies for the batshit insane design decisions that the creators of the GUI desktop libraries have foisted upon you. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#781961: ditto
I absolutely agree with you that there should be documentation on how to solve this problem. If you come up with a set of simple steps that solve it, please let me know and I will happily add it to the xscreensaver FAQ. The reason it's not there already is that I have no idea -- because, as you have discovered in your googling, the whole thing is a gigantic clusterfuck of competing and incompatible non-solutions. If there were, hypothetically, some solution that worked on, say, all Debian systems, then it would be eminently sensible for the Debian-provided xscreensaver package to activate that solution by default. Hypothetically. If anyone actually knew how to do that. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.
009 -4 days elapsed 5.11: Apr 13 2010 - 7.2 months elapsed 5.12: Sep 15 2010 - 5.1 months elapsed 5.13: Apr 18 2011 - 7.1 months elapsed 5.14: May 20 2011 - 32 days elapsed 5.15: Sep 28 2011 - 4.3 months elapsed 5.16: Jun 19 2012 - 8.7 months elapsed 5.17: Jun 22 2012 -3 days elapsed 5.18: Jul 3 2012 - 11 days elapsed 5.19: Jul 26 2012 - 23 days elapsed 5.20: Oct 6 2012 - 2.4 months elapsed 5.21: Feb 4 2013 - 4.0 months elapsed 5.22: Jul 16 2013 - 5.3 months elapsed 5.23: Nov 9 2013 - 3.8 months elapsed 5.24: Dec 7 2013 - 28 days elapsed 5.25: Dec 9 2013 -2 days elapsed 5.26: Dec 9 2013 -0 days elapsed 5.27: May 27 2014 - 5.5 months elapsed 5.28: Jun 4 2014 -8 days elapsed 5.29: Jun 8 2014 -4 days elapsed 5.30: Sep 11 2014 - 3.1 months elapsed 5.31: Nov 15 2014 - 2.1 months elapsed 5.32: Nov 18 2014 -3 days elapsed 5.33: Jun 25 2015 - 7.2 months elapsed 5.34: Oct 24 2015 - 4.0 months elapsed 5.35: May 24 2016 - 7.0 months elapsed 5.36: Oct 10 2016 - 4.6 months elapsed 5.37: Jul 5 2017 - 8.8 months elapsed -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.
> Sometimes it goes more than a year between upstream's releases also, This has literally never happened. There are typically 4-8 releases a year, but there have never been fewer than 2 per year, since 1992.
Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.
Well, 5.36 was released on 11 Oct 2016, which, as of the date of this bug report, was 1 year and 3 days old. 5.37, which contains webcollage updates, was released on 5 July 2017. The latency with which distros package it up for you is entirely out of my hands.
Bug#878373: xscreensaver-screensaver-webcollage: Fails to get resuls from google, bing, and instagram making collages repetitive.
Here's an idea, try running a version of xscreensaver that is not over a year old. Yes, you have made the mistake of using Debian. I realize that they go out of their way to make that difficult for you. My sympathies.
Bug#878379: xscreensaver-screensaver-webcollage: Please provide a means to set safe seach levels for those image search mehods that support it.
Absolutely not. That is completely antithetical to the purpose of the webcollage screen saver.
Bug#876087: xscreensaver: source-less and unlicensed code at hacks/images/m6502/dmsc.asm
Oh FFS, the pedantry of you people knows no bounds. It's not even a *real emulator*. Did you even try emailing him? -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#873108: xscreensaver does not trap errors from intltool-update
Well, on every system I've ever had access to, intltool rarely works, so I took to just ignoring it entirely. YMMV.
Bug#860253: xscreensaver: Password dialog is not visible sometimes
Wow, that's really strange. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#860253: xscreensaver: Password dialog is not visible sometimes
Is the screen completely black? Do you have xscreensaver configured to be black-only or is it running savers? If you are not running savers, try doing that, to see if, when it is in this "invisible" mode, there are any pixels visible at all. My guess here is that a bug in your video driver is causing the screen to either not be powered on, or is causing the frame buffer to not be displayed. That is, the client-facing side of X11 believes there are bits on your screen, but the hardware-facing side has lost its mind. -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#858912: xscreensaver-gl-extra: "surfaces" hang the pc ; hard reboot looses recent work
This is a bug in your video drivers and not xscreensaver, I'm afraid: https://www.jwz.org/xscreensaver/faq.html#server-crash
Bug#853175: xscreensaver: enhancement wish: xscreensaver should be able to detect pause in VLC and videoplayback in browser
This is a problem with VLC or VLC's configuration, not xscreensaver: https://www.jwz.org/xscreensaver/faq.html#dvd -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
Bug#853174: xscreensaver does not recognize videoplayback in browser
To make this work, your browser will need to be configured to tell xscreensaver that it is playing videos. I don't know if that is possible with any extant browsers. Either way, not an xscreensaver bug. https://www.jwz.org/xscreensaver/faq.html#dvd -- Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
