fce 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
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: 1
f0b1ddb60ccda2989c6da6977ab51c75dfd7/src/xfce-screensaver.c#L233
Is xscreensaver-systemd not running for you?
--
Jamie Zawinski • jwz.org • dnalounge.com
rder, 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
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 s
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
> 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
s 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
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 = &win->state;
if (s->debug_p) fprintf (stderr, "%s: tab changed\n", blurb());
+ populate_prefs_page (s);
pref_changed_cb (GTK_WID
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
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.
See also https://github.com/mirror/libX11/blob/master/src/ErrHndlr.c#L38
--
Jamie Zawinski • jwz.org • dnalounge.com
t 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
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
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
--
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
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
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
Things change. Intentionally. It's better now. Adjust and move on with your
life.
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 chang
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 thi
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.
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
Correction, Gallant is in fact BSD licensed:
http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev/wsfont/gallant12x22.h
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.
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.
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 backgroun
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.
Please make sure you grab xscreensaver-6.05.1.tar.gz if you already grabbed the
other one; there was a last minute fix.
CREEN-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
op 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
olicyAgent" not
in use
[ kill server ]
xscreensaver-systemd: 02:07:26: X connection closed
Exit 1
--
Jamie Zawinski • jwz.org • dnalounge.com
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
nately 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
stupide
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/
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.
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
> 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/
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 Zaw
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 Za
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 blindl
to clear the whole
line.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
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/
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.
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/
ing 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
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/
ner.
> 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
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/
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/
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.
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 ins
.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/
nd 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/
dministrator 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/
> 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?
>
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
akes 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/
gt; 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/
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
et:
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
'-*-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/
27;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/
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!
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/
matic]
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,a
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.
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/
o10646-1"
xlsfonts -fn "-*-*-medium-r-*-*-*-180-*-*-p-*-iso10646-1"
Maybe test with "xterm -font "
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
sfonts 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/
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
For best logging: xscreensaver -verbose -log log.txt
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 v
screen could involve a multi-second animation.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
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/
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/
STSCRIPT_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-i
"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/
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/
To be clear: my intention is to ignore this trivial problem.
> 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
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 def
Well, there's no way for glitchpeg to work on your desktop image, because your
desktop is not a jpeg...
Cache times out after 3 hours, or the first time no suitable images are found.
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,
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 addition
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/
ge 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/
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/
> 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.
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.
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.
Absolutely not. That is completely antithetical to the purpose of the
webcollage screen saver.
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/
Well, on every system I've ever had access to, intltool rarely works, so I took
to just ignoring it entirely. YMMV.
Wow, that's really strange.
--
Jamie Zawinski https://www.jwz.org/ https://www.dnalounge.com/
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/
This is a bug in your video drivers and not xscreensaver, I'm afraid:
https://www.jwz.org/xscreensaver/faq.html#server-crash
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/
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.jw
1 - 100 of 347 matches
Mail list logo