At least once, right?

https://bugzilla.redhat.com/show_bug.cgi?id=1145144

Make sure that the plugin is stopped when it's disposed of.

https://bugzilla.redhat.com/show_bug.cgi?id=1145144

So that we don't get called out when the plugin is stopped.

https://bugzilla.redhat.com/show_bug.cgi?id=1145144

It's not the screen where you can't see anything if the backlight isn't
on, it's a keyboard.

Make sure to only reset the keyboard backlight to the maximum when
there's an error reading that value.

https://bugzilla.gnome.org/show_bug.cgi?id=734074

Cosimo Cecchi authored Jul 11, 2014 and Cosimo Cecchi committed Jul 22, 2014

Fixes a regression from dd2477bf where
regular files would never get deleted from the trash.

https://bugzilla.gnome.org/show_bug.cgi?id=733419

When on AC, we wouldn't be resetting the timeout ID, and throwing
a warning later on, when the network state changed.

To match the other g_file_delete() calls.

Check whether a leaf node is a symlink before processing it, and if it
is, check whether we should delete the link itself.

This works around a possible bug in GIO where GFileEnumerators will get
the filetype of the linked-to item, instead of detecting that it is a
symlink.

https://bugzilla.gnome.org/show_bug.cgi?id=730223

The caller already knows which idle mode it wants us to move to.

Automatically going back to the previous idle mode here would at best
cause a quick spurious idle mode switch which would be immediately
overriden by the caller or, at worst, we could go into suspend if the
previously saved mode was SLEEP.

The latter could happen on resume from suspend because there's a race
between idle_became_active_cb() and handle_wake_up_screen(). If the
second wins the race then we'd set a teporary unidle with the previous
mode being SLEEP, meaning that when idle_became_active_cb() cancels
the temporary unidle afterwards we'd immediately move to SLEEP again.

https://bugzilla.gnome.org/show_bug.cgi?id=729024

It might happen that there's no device connected and yet the CRTC
associated with an output has a valid mode.

RRGetOutputInfo tells us if the hardware was able to detect a device
connected to the output so let's use that.

Note that in versions newer than 3.8, this check isn't required since
the list of outputs that we get from mutter's DisplayConfig interface
is already filtered by mutter and doesn't contain any disconnected
outputs.

https://bugzilla.redhat.com/show_bug.cgi?id=1081093

When trying to wake up the screen, try to use XF86WakeUp in preference
to the left Alt. Don't use the right Alt key as it might be set as the
Compose key which would eat the event without resetting the idle.

Also make sure to initialise the keycode only once.

https://bugzilla.gnome.org/show_bug.cgi?id=729375

This reverts commit 2af30cc9.

Wrongly committed.

When an output is disconnected, it's possible that the XRandR
configuration doesn't actually change, and thus doesn't emit
the "changed" signal. To work-around that, also capture the
output-connected and output-disconnected signals and go through
a forced refresh.

https://bugzilla.redhat.com/show_bug.cgi?id=1081093

Instead of comparing the shell's exit code by hand, use
g_spawn_check_exit_status() to get the script's exit code.

https://bugzilla.gnome.org/show_bug.cgi?id=710791

The code at the bottom says we'll ignore further configuration if
"1" is returned, but the top said if "0" is returned.

Make both say "1".

before 34395459, apply_all_settings()
and then apply_numlock() would sync up the numlock LED on a newly
hotplugged device.
34395459 removed that call, so devices
now come up with the numlock LED off even when the numlock is on, and a
subsequent state change will wrongly toggle it, i.e. LED off when numlock
is on, LED on when numlock is off.

This should really be fixed in the xserver but it's unlikely to happen,
restoring this patch in gnome-settings-daemon seems the simplest solution
for now.

https://bugzilla.gnome.org/show_bug.cgi?id=722753

Tim Lunn authored Nov 09, 2013 and Bastien Nocera committed Nov 09, 2013

fix possible race since notify_have_shell is getting called after the
managers are destroyed.

https://bugzilla.gnome.org/show_bug.cgi?id=711238

We allow using the power key pretty much everywhere now, but
we also ensure that we never show interactive dialogues on the
lock screen (something that was possible with other suspend/power
buttons already if more than more than one user was logged in,
or an interactive shutdown was configured).

See https://bugzilla.redhat.com/show_bug.cgi?id=980692

https://bugzilla.gnome.org/show_bug.cgi?id=707095

Shutdown is supposed to shutdown without asking, as "interactive"
already should do what we need for interactive shutdowns.

https://bugzilla.gnome.org/show_bug.cgi?id=698733

They only differed by a single line.

Passing "9223372036854775807" (G_MAXINT64) as the timestamp will
overflow as the timestamp is cast to a guint32 internally. Clamp
that value instead to avoid g-s-d crashing.

See https://bugzilla.redhat.com/show_bug.cgi?id=1022562

https://bugzilla.gnome.org/show_bug.cgi?id=711065

https://bugzilla.gnome.org/show_bug.cgi?id=709576

The default timeouts for DPMS in Xorg were finally applied after about
10 years:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=6238bd68bd71323f8b4f1808f34dabe2ae447fe3

So work-around that horror.

https://bugzilla.gnome.org/show_bug.cgi?id=709114

The recent lirsvg security changes made the include portion of the
SVG used for the OSD fail to parse.

Set the base URI for the layouts before loading the SVG data to
fix the new strict loading policy (#691708).

https://bugzilla.gnome.org/show_bug.cgi?id=709350

Conflicts:
	plugins/wacom/gsd-wacom-osd-window.c

The code was handling touchpad "left-handed" key as a boolean, but it's
an enum.

https://bugzilla.gnome.org/show_bug.cgi?id=708546

We might set up different layouts in different groups - see
replace_layout_and_variant(). But we don't want the X server group
switching feature to actually switch them. Regularly, if we have at
least two input sources, gnome-shell will tell us to switch input
source at that point so we fix that automatically. But when there's
only one source, gnome-shell short circuits as an optimization and
doesn't call us so we can't set the group switching XKB option in the
first place otherwise the X server's switch will take effect and we
get a broken configuration.

https://bugzilla.gnome.org/show_bug.cgi?id=709085

Mark Ellis authored Sep 30, 2013 and Bastien Nocera committed Sep 30, 2013

If max_age and max_size are both -1, thumbnail cleaning
is disabled, so there is no need to scan the cache
directories.

https://bugzilla.gnome.org/show_bug.cgi?id=625609
https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/505085

Dominique Leuenberger authored Aug 20, 2013 and Rui Matos committed Sep 05, 2013

https://bugzilla.gnome.org/show_bug.cgi?id=706442