- Aug 22, 2017
-
-
Commit 476154fe and commit 867b2039 broke the build. Full Continuous log: http://build.gnome.org/continuous/buildmaster/builds/2017/08/21/49/build/log-gnome-settings-daemon.txt https://bugzilla.gnome.org/show_bug.cgi?id=786577
-
- Aug 21, 2017
-
-
Bastien Nocera authored
This is the equivalent of "undefined" for the accelerometer orientation. Don't use it to prime our nice ambient light readings curve. https://bugzilla.gnome.org/show_bug.cgi?id=786164
-
Bastien Nocera authored
backlight_enable() does 2 things, fiddle with the DPMS as well as attempt to claim the light sensor. But the light sensor claim attempt will always fail as the "session_is_active" variable has not been initialised yet. So just try a tad later for it to work as soon as you've logged into the session. https://bugzilla.gnome.org/show_bug.cgi?id=786164
-
Bastien Nocera authored
We need to both watch for the signal and setup inhibitors to be informed about suspend attempts, so move the comment above both calls. https://bugzilla.gnome.org/show_bug.cgi?id=786164
-
Bastien Nocera authored
We definitely do want to be able to disable light sensor monitoring even if we're not in an active session any more. The only case this conditional was supposed to prevent is trying to claim the light sensor when the session is inactive. Anything else should be allowed. https://bugzilla.gnome.org/show_bug.cgi?id=766067
-
- May 05, 2017
-
-
Jeremy Bicha authored
-
- May 04, 2017
-
-
Bastien Nocera authored
If we handle rfkill input keys without telling rfkill, we end up handling those keys in gnome-settings-daemon, as well as in the kernel's rfkill-input driver. As handling all the different keys would require more work than possible in a stable release, we'll let rfkill-input handle this, and lose the OSD for now. https://bugzilla.gnome.org/show_bug.cgi?id=760517
-
- Apr 24, 2017
-
-
Bastien Nocera authored
Bizarrely, since 2011, gnome-settings-daemon was documented as using org.gnome.SettingsDaemon.MediaKeys D-Bus name, but everybody ended up using the org.gnome.SettingsDaemon owned by the daemon instead, and never reported the discrepancy. This fixes the code to match the 6-year old API as documented by owning the org.gnome.SettingsDaemon.MediaKeys. The portion of this patch adding the org.gnome.SettingsDaemon.MediaKeys name owning will need to be backported as far as reasonably possible by distributions, and all users of the API changed before GNOME 3.26. This would obviously have been easier if the problem was reported when detected, committer of this fix included. https://bugzilla.gnome.org/show_bug.cgi?id=781326
-
- Mar 14, 2017
- Mar 07, 2017
-
-
Administrator authored
-
- Mar 03, 2017
-
-
- Feb 14, 2017
-
-
Rui Matos authored
Since grabbing is asynchronous, we might end up with requests to grab a binding combo while we already have a pending grab for that same combo. If this happens, the last request should win, so keep track of it to re-try when we get the reply for the pending grab. https://bugzilla.gnome.org/show_bug.cgi?id=758302
-
Rui Matos authored
If a binding definition changes again before we get the dbus reply for the previous change we'd never ungrab the previous accel id. https://bugzilla.gnome.org/show_bug.cgi?id=758302
-
Rui Matos authored
If a MetaKey instance is removed from the array and free'd after we call grab_media_key() but before the dbus reply comes in, we end up writing over free'd memory (&key->accel_id). https://bugzilla.gnome.org/show_bug.cgi?id=758302
-
-
Rui Matos authored
If there are gsettings changes to a custom binding's gsettings we could end up calling update_custom_binding() twice in a row: one for the 'binding' setting and one for the 'command' setting. This means that we would add the same binding twice and the second addition would fail resulting in key->accel_id being set to 0, preventing us from handling the binding when it gets activated. Since we're only interested in changes to the 'binding' setting, we can prevent this problem and the extra work we always do by ignoring changes to any other setting keys. Thanks to Matthijs Kooijman (matthijs@stdin.nl) for debugging and pointing out the problem. https://bugzilla.gnome.org/show_bug.cgi?id=758302
-
- Jan 11, 2017
-
-
NSS_Initialize is a noop if called multiple times. We currently call NSS_Initialize twice in gnome-settings-daemon. Once by NMClient and once by the smartcard plugin. NMClient does it first, and it does it without initializing the secmod database. When the smartcard plugin tries to initialize NSS with the secmod database later, it's call is turned to a noop. This commit changes the smartcard plugin to use NSS_InitContext instead, which can properly handle being initialized multiple times with different configurations. See: https://wiki.mozilla.org/NSS_Library_Init https://bugzilla.gnome.org/show_bug.cgi?id=751040
-
- Nov 17, 2016
-
-
Bastien Nocera authored
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
-
- Oct 18, 2016
-
-
YunQiang Su authored
-
- Oct 15, 2016
-
-
Kjartan Maraas authored
-
- Oct 11, 2016
-
-
Rui Matos authored
-
- Oct 10, 2016
-
-
Bastien Nocera authored
When finalising the sharing manager, we destroyed the services hashtable, but service_free() passed NULL as the manager, making it impossible to really stop the service. As _stop() was already called, we shouldn't need to stop the service, or crash. https://bugzilla.gnome.org/show_bug.cgi?id=772587
-
Bastien Nocera authored
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
-
Bastien Nocera authored
We have 2 checks for the same thing within a couple of lines. Merge those. https://bugzilla.gnome.org/show_bug.cgi?id=772581
-
Bastien Nocera authored
The data now comes from hwdb via gnome-desktop, and the name of the vendor changed. https://bugzilla.gnome.org/show_bug.cgi?id=741688
-
-
-
-
-
- Oct 06, 2016
-
-
- Oct 04, 2016
-
-
Rui Matos authored
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
-
- Sep 22, 2016
-
-
- Sep 19, 2016
-
-
Inaki Larranaga Murgoitio authored
-
- Sep 20, 2016
-
-
Bastien Nocera authored
As the value can be < 0, make sure that we don't set up timeouts for negative amounts of time. https://bugzilla.gnome.org/show_bug.cgi?id=771543
- Sep 16, 2016
-
-
Jordi Mas authored
-
-
-
- Sep 14, 2016