After pressing the Ctrl+Alt+Del shortcut, the shutdown dialog doesn't
appear on screen for a couple of seconds.

The media-keys daemon calls the 'Shutdown' method synchronously. After that
gnome-session calls the daemon with 'QueryEndSession'. The daemon cannot
reply as it's blocked waiting for the reply to the Shutdown method.

Sending the message asynchronously fixes that delay.

Based on report by Xiaoguang Wang <xwang@suse.com>

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

We get called for every removed GDK device, so check whether it's of
interest early, instead after throwing a bunch of warnings.

gsd-wacom[1884]: g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
gsd-wacom[1884]: gsd_wacom_device_get_device_type: assertion 'GSD_IS_WACOM_DEVICE (device)' failed
gsd-wacom[1884]: gsd_wacom_device_get_settings: assertion 'GSD_IS_WACOM_DEVICE (device)' failed
gsd-wacom[1884]: invalid (NULL) pointer instance

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

We have 2 checks for the same thing within a couple of lines. Merge
those.

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

When the session is inhibited from going idle e.g. because a media
player is active, we still want to blank the screen if the session is
locked (i.e. the "screensaver" is up).

Otherwise, we'd blank the screen when the session gets locked but then
on user activity we'd go back to NORMAL mode, unblanking the screen,
and ending up without an idle watch to blank again after a while since
we clear all watches and exit early if idle is inhibited.

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

Jason Gerecke authored Jul 06, 2016 and Carlos Garnacho committed Aug 22, 2016

Several small leaks exist were found and fixed in the wacom plugin after
running valgrind.

Jason Gerecke authored Jul 06, 2016 and Carlos Garnacho committed Aug 22, 2016

Most of the wacom plugin code protects X11 calls with gdk_error_trap_push/pop
and prints a warning if something fails. There were two calls that were not
protected, however, and one use of g_error instead of g_warning that would
cause the g-s-d process to die if e.g. the tablet disappears while g-s-d is
trying to work on it.

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

Calls to open_device can return null, don't try to configure the device
in those cases, it only leads to segfaults

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

Try not to claim the light sensor when our seat isn't active,
as this will just throw PolicyKit errors about not being authorised,
as happens with gdm trying to change the backlight when we're
logged in.

Also remove the calls to is_session_active() and use the cached variable
when possible.

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

When configuring mice and touchpads, we might stumble upon a Wacom pad
device. To check whether it's a synaptics device, we open the device,
get the properties, and close it back up.

But when we close it, we end up releasing whatever grab the wacom plugin
might have had on the pad buttons:

           When a client makes an XCloseDevice request, any active grabs
           that the client has on the device are released.  Any event
           selections that the client has are deleted, as well as any
           passive grabs. If the requesting client is the last client
           accessing the device, the server may disable all access by X to
           the device.

As we cannot change that behaviour, we'll use a call that doesn't
require opening the device so we don't have to close it.

See https://bugs.freedesktop.org/show_bug.cgi?id=94487

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

This is what you get for trying to port a patch that can't be ported.

1) Don't use the possibly dangling user_data when the calls might
   have been cancelled
2) Don't print warnings when calls were cancelled
3) Don't print criticals for run-time warnings

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

Because we used the wrong cancellable, it was possible for it not to
exist and the call not being cancelled. As we only used the return value
from the call, this shouldn't cause any crashes.

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

If the D-Bus proxy creation was cancelled, we might have a
use-after-free problem here.

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

We really don't need to call g_cancellable_is_cancelled() when we
could just check the error code we get back.

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

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

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

We really don't need to call g_cancellable_is_cancelled() when we could
just check the error code we get back.

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

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

Richard Hughes authored Mar 15, 2016 and Bastien Nocera committed Mar 16, 2016

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

Richard Hughes authored Mar 15, 2016 and Bastien Nocera committed Mar 16, 2016

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

Richard Hughes authored Mar 15, 2016 and Bastien Nocera committed Mar 16, 2016

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

Richard Hughes authored Mar 15, 2016 and Bastien Nocera committed Mar 16, 2016

Make sure to cancel any async operations when stopping the color plugin.

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

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

Carlos Garnacho authored Jan 22, 2016 and Bastien Nocera committed Mar 01, 2016

We fetch the current pad device from the button-mapping OSD window through
g_object_get(), which adds new references to GObjects.

Carlos Garnacho authored Jan 22, 2016 and Bastien Nocera committed Mar 01, 2016

It's not removed during finalization, so it's kept lingering, and called
when the device is actually removed/destroyed.

Carlos Garnacho authored Jan 22, 2016 and Bastien Nocera committed Mar 01, 2016

We're doing this call twice. This is safe, but unneeded.

Carlos Garnacho authored Jan 22, 2016 and Bastien Nocera committed Mar 01, 2016

We were failing to iterate through the list here...

In 5f29c37e we added a two-step
mechanism to avoid Bluetooth rfkills from being stuck in rfkill'ed mode.
The problem is that the 2-step unblocking will take Bluetooth adapters
out of rfkill even if they were disabled when we went into airplane
mode.

So only apply this two-step unlocking when enabling Bluetooth.

Jason Gerecke authored Jan 07, 2016 and Rui Matos committed Jan 07, 2016

The XIGrabButton and XIUngrabButton functions can fail with e.g. BadDevice,
so we should be careful to catch the error and not crash.

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

In case the IIO sensor daemon doesn't change the values immediately
after we claim the interface, we should get them to be in sync from
the start.

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

We can't change the brightness in that case but we can and should
avoid any polling the IIO sensor daemon might have to do while
inactive.

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

This fixes problems when the system has a platform rfkill device for
Bluetooth and the Bluetooth adapter's rfkill support somehow got
blocked.

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