Mantas Mikulėnas authored Feb 05, 2018 and Bastien Nocera committed Mar 31, 2018

On slower machines (esp. with tracker and/or dropbox starting on login)
this may take more than the usual timeout of ~25 seconds.

We cannot use the existing retry loop here – in this bug, the first call
actually *succeeds* from gnome-shell's side, even if gsd-mediakeys gives
up on waiting for the reply.

So if we called GrabAccelerators again, we would receive no accel IDs
(because all keys are duplicates), and gnome-shell would keep sending
AcceleratorActivated signals with accel IDs that the 1st call has
established – resulting in exactly the same "Could not find accelerator
for accel id" as we're trying to fix.

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

To make debugging issues with the automatic timezone feature easier.

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

Benjamin Berg authored Jan 17, 2018 and Bastien Nocera committed Jan 18, 2018

The test was trying to verify that no suspend action happened. However,
this cannot happen during testing, as the suspend action for lid close
is not done by gsd-power. So instead just verify that the lid switch
inhibition works as expected.

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

Carlos Garnacho authored Jul 19, 2017 and Bastien Nocera committed Jan 18, 2018

Udev is rather common, so this check doesn't suffice if anyone wants
to build with no wayland support whatsoever.

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

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

When a new idle inhibitor is added then the state needs to be forced to
normal mode even when the user is idle. However, this should not happen
if the screensaver is active at the time.

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

During testing debug output is enabled using --verbose.
Unfortunately the default logging handler in GLib is not flushing the
utput stream for each log message. In addition, the default buffering
for stdout seems to be block based (not line based) if stdout is not a
TTY.
This causes the log message to get stuck in the buffer and the tests
cannot read them.

See also https://bugzilla.gnome.org/show_bug.cgi?id=792432

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

Use the helper introduced earlier instead of re-implementing the loop for
every function to test the gsd-power log. The helper was introduced in
the commit 450a9361 ("power: Add helper to read plugin log during test").

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

Some tests create activity just after the screen is blanked. There is a
race condition as setting up the active monitor may only be done after
the idle time has been reset.
Prevent this by adding a short sleep. This race is inherent to
GnomeIdleMonitor.

Note that the race condition is actually between the call to
gnome_idle_monitor_add_user_active_watch and mutter receiving the dbus
method call.

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

GSD waits a while before a lid close action can affect anything. As the
setup routine updates the monitors, this safety timeout will be taken
into account.

This could cause rare test failures if the initialisation was too quick.
Add the explicit sleep to prevent any errors.

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

The new API has a composite device and g-s-d uses that rather than
collecting the information itself. Also, upower is doing the critical
action rather than g-s-d meaning that we can only check for the
notification.

Remove/Update the tests to reflect these changes.

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

Add a generic helper to find needles in the gsd-power plugin log.

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

When starting the tests dbus would print a warning as the
XDG_RUNTIME_DIR was not yet created. Simply create this directory to
prevent the warning from being printed.

dbus[2514]: Unable to set up transient service directory: XDG_RUNTIME_DIR "/tmp/gsd-power-testjFVT_p/runtime" not available: No such file or directory

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

The logind object attribute was renamed when moving to the dbusmock
template rather than using something custom. Update the tests to reflect
this. This happened in commit f581667b (tests: Use existing logind template).

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

Otherwise debug information may not be printed making testing
impossible.

This regression was introduced in commit 198f7ea2
(plugins: Rename sources of all test applications).

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

The test was setting GSD_MOCK but the C code checked GSD_MOCKED. Fix
this by using GSD_MOCKED in all cases.

This fixes a regression introduced in commit 5fc7cb64 (power: Make power
plugin "mock" support a run-time check).

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

Benjamin Tissoires authored Nov 02, 2017 and Carlos Garnacho committed Jan 15, 2018

Size-based input/output matching doesn't raise the "found" flag, which
would result on input_info_guess_candidates() still trying to assign the
builtin output to the input device if that is the only match found.

For screen integrated devices (i.e. not on the builtin output) this is
and undesirable possibility, setting the "found" flag to TRUE results on
the correct output being assigned.

Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>

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

GsdDeviceMapper used to refrain from remapping devices that already had
a configured output. This however results on wrong mapping when the input
device is plugged before the output, since the heuristics will attempt
really hard to find an output for the device before the real one is
available, and not remapped again when the output is plugged.

Fix this by forcing remapping on all screen-integrated devices on every
hotplug event, so the input device will get remapped to the right screen
(hopefully!) when it is plugged. This is not applied to devices mapped
to the builtin output, or those with no attached output at all, as in both
of these cases the configured output should be left static.

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

As iio-sensor-proxy isn't yet clever enough to only send property
changes signals to clients that have claimed a sensor, disconnect
the properties-changed signal so we don't attempt to make brightness
changes when we're not on the active seat.

See https://github.com/hadess/iio-sensor-proxy/issues/210
See https://bugzilla.gnome.org/show_bug.cgi?id=756539
See https://bugzilla.gnome.org/show_bug.cgi?id=773685
See https://bugzilla.gnome.org/show_bug.cgi?id=764896
See https://bugzilla.redhat.com/show_bug.cgi?id=1322588

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

Select which choice should appear in the gnome-shell dialogue, and click
"Ask!". The result of the selection will appear underneath the button.

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

The property change notification was trying to send a notification for
"kernel-noinput" which was the original name proposed for commit 3810072d
(rfkill: Add property to Rfkill helper to inhibit kernel handling).

There is no listener for the event, so this simply fixes a warning.

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

Hans de Goede authored Nov 16, 2017 and Rui Matos committed Nov 23, 2017

On some devices the power-button sends a KEY_POWER event immediately
after resume when the power-button was used to wakeup the system, causing
the system to suspend immediately again. This is esp. a problem on tablets
where the power-button is often the only way to wakeup the system.

This commit fixes this by listening for suspend/resume signals from
logind (which requires taking a delay inhibitor on suspend to do reliabe)
and on suspend temporarily disabling the power-button.

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

Роман Донченко authored Nov 12, 2017 and Rui Matos committed Nov 21, 2017

Currently, when gsd-clipboard receives a response to a conversion
request for the MULTIPLE target that indicates failure (i.e. property
== None), it doesn't free the contents list. This leads it to believe
it owns the CLIPBOARD selection, when it actually doesn't. Because of
this, it returns an error for all subsequent SAVE_TARGETS requests,
effectively becoming inoperative as a clipboard manager.

So fix that. Because of the way the code is structured, free_contents
will also be called when a request for the TARGETS target fails, but
at that point the contents list should be empty, so it'll be harmless.

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

Роман Донченко authored Nov 12, 2017 and Rui Matos committed Nov 21, 2017

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

Alberts Muktupāvels authored Oct 04, 2017 and Rui Matos committed Nov 02, 2017

This plugin does not use value from this setting.

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

This is a regression from commit
8966dd93.

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

Sébastien Bacher authored Oct 10, 2017 and Rui Matos committed Nov 01, 2017

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

The last call site to it was dropped in commit 4db56864

; this just fixes
a compiler warning about the unused function.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

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

Signed-off-by: Philip Withnall <withnall@endlessm.com>

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

Signed-off-by: Philip Withnall <withnall@endlessm.com>

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