Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
OpenBSD does not have nor use pam(8) for password authentication but
instead uses bsd_auth(3): add a bsd_auth authentication scheme to
make locking possible.
This has been a part of gnome-screensaver already but was probably
removed at one point. This is mostly identical to that code, with some
minor modifications.
|
|
The function g_get_real_name is used to get user's full name, but when the full
name is not existed, it will return an empty string instead of NULL.
|
|
configurations with overlapping monitor geometries
|
|
This changes the code quite a lot as both grabbing the pointer and the keyboard
have to be done simultaneously now.
|
|
and set grid property only once, after grid is created
|
|
|
|
Change shake times to even number, so the dialog can return to its original position.
|
|
position.
|
|
|
|
Which are completely broken in GTK+ 3.22.
|
|
|
|
and require libmatekbd and libmate-desktop >= 1.17
|
|
|
|
In some systems the gdm binary is actually called "gdm-binary", so we
need to check for that too.
|
|
fixes https://github.com/mate-desktop/mate-screensaver/issues/104
|
|
|
|
|
|
|
|
|
|
If the screensaver is already active without a lock, and it got a
request to lock, it would bail out without switching to a locked
state.
https://bugzilla.gnome.org/show_bug.cgi?id=668967
|
|
|
|
commit adfc280 changed the drawing area associated with each
monitors screensaver window to get realized early.
That change is seemingly causing problems for users.
This commit stops preemptively realizing the drawing areas, and
instead makes the background color settings get applied reactively
in response to realization.
http://bugzilla.gnome.org/show_bug.cgi?id=679441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this avoid some build warnings
|
|
|
|
taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=214ab95
https://git.gnome.org/browse/gnome-screensaver/commit/?id=4f0124a
|
|
|
|
That won't work correctly with GTK3, even more so given that we set
app_paintable = TRUE on the drawing area.
Instead, set the background GdkRGBA to black directly
on the GtkDrawingArea's GdkWindow.
taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=43ee32e
|
|
|
|
This gets rid of some compile warnings
taken from:
https://git.gnome.org/browse/gnome-screensaver/commit/?id=73c0e41
|
|
|
|
|
|
|
|
|
|
This reverts commit f1739c03e00a51e87bd49d04827e5b765d1c70de.
|
|
Add a handler for the PrepareForSleep event on the system bus under
systemd and lock the screen in such an event. This addresses the issue
where "systemctl suspend" suspends the system but the system isn't
locked on resume, with the obvious negative security connotations.
|
|
Right now the systemd event handling is not actually working at all.
This happens because _listener_message_path_is_our_session() has code to
check if the event came to our session (e.g. "10") and, under systemd,
does this by trying to compare it with the object path, by stripping the
/org/freedesktop/login1/session/ prefix.
However, under -at least recent versions- of systemd, the session ID
part of the path is escaped separately, and following D-Bus rules
initial numbers are escaped. In the example above, the obj_path is
/org/freedesktop/login1/session/_310, so the comparison actually fails.
Port a fix that has been present on various distributions (e.g. Arch)
and pieces of software (e.g. cinnamon-screensaver) since at least March
2013. The original author is Peter de Ridder <[email protected]>.
The bug and the fix can both be easily verified by running "loginctl
lock-sessions".
|
|
Don't fade to black when locking the screen
|
|
If the screensaver is explicitly asked to lock
(as opposed to locking because of idle), then
we should do it very quickly. 1 second is
too long.
This commit changes the fade to 60 steps per
second and a quarter of second long
(put another way, about 15 fade increments).
Taken from gnome-screensaver,
commit:44edc03104f9757f4d866f24df8793f064b6ce70
And applied to MATE by infirit
|
|
Fading to black has negative security consequences: the screen locking
and actual suspend race with each other, and this can result in the
screen's contents being briefly visible after resume.
This has been reported as #54 but has been known and patched for in
Debian/Ubuntu since at least 2010 (see LP 546578).
|
|
|
|
Use GDK_BLANK_CURSOR across Gtk versions for new cursors.
|