Otherwise fontconfig might report that no update was necessary, and
g-s-d would print a different message, resulting in a test failure.

The file descriptor may have been closed (and set to -1) already, catch
this.

This also cleans up the startup logic and ensures we wait for the plugin
to be ready after launching it.

Otherwise we have few guarantees about how long it takes for the
settings to be applied.

The power and xsettings tests have diverged a lot, this lowers the
difference. The nice thing about this is that we now wait for the plugin
to be initialized based on its output.

Theoretically this could cause deadlocks when the kernel buffers are not
large enough to read the command output.

Using a pipe without guaranteeing that it is actually read could
potentially get us into really weird deadlock situations. Switch to use
OutputChecker to avoid the issue (and log the notifications).

The default timeout of 60 seconds is rather long. If we run into that,
we don't necessarily get a proper backtrace from python before meson
kills the process. As such, lower the timeout to ease debugging.

Just because poll is the more modern API.

Otherwise the interpreter can apparently deadlock on shutdown trying to
join the still running thread.

Exit code 77 means that the test has been skipped and will be
interpreted as such by meson.

gnome-settings-daemon/meson.build:87: WARNING: Trying to compare values of different types (str, bool) using ==.
The result of this is undefined and will become a hard error in a future Meson release.

And remove the "install" arg in configure_file() to quiet the warnings

WARNING: Project specifies a minimum meson_version '>= 0.47.0' but uses features which were added in newer versions:
 * 0.49.0: {'/ with string arguments'}
 * 0.50.0: {'install arg in configure_file'}

Traceback (most recent call last):
  File "/builds/GNOME/gnome-settings-daemon/plugins/power/test.py", line 760, in test_lid_close_inhibition
    self.check_no_lid_uninhibited(gsdpowerconstants.LID_CLOSE_SAFETY_TIMEOUT - 1)
  File "/builds/GNOME/gnome-settings-daemon/plugins/power/test.py", line 327, in check_no_lid_uninhibited
    self.plugin_log.check_no_line(b'uninhibiting lid close', wait=timeout)
  File "/builds/GNOME/gnome-settings-daemon/tests/output_checker.py", line 143, in check_no_line
    return self.check_no_line_re(needle_re, wait=wait, failmsg=failmsg)
  File "/builds/GNOME/gnome-settings-daemon/tests/output_checker.py", line 133, in check_no_line_re
    raise AssertionError('Found needle %s but shouldn\'t have been there (timeout: %0.2f)' % (str(needle_re), timeout))
NameError: name 'timeout' is not defined

When pressing airplane mode hotkey on many HP laptops, the AT keyboard,
HP Wireless device (HPQ6001) and Intel HID device (INT33D5) can all send
rfkill hotkey event.

Preferably we should just leave one device and unregister the others. In
practice this is hard to achieve, becuase the presence of a device
doesn't necessarily mean it can generate rfkill hotkey event, we can
only know what devices are capable to generate rfkill event when the
hotkey gets pressed.

So add a delay between each rfkill event to workaround the issue. This
is also how the other OS handles multiple rfkill events.

Nishal Kulkarni authored May 14, 2021 and Benjamin Berg committed May 14, 2021

reference counting is implemented manually instead of using grefcount
provided by glib.

Fix: using grefcount and its functions for `DeleteData` struct

Updated `glib_min_version` to 2.58

Nishal Kulkarni authored May 07, 2021 and Benjamin Berg committed May 14, 2021

Replace `gdk_error_trap_push` and `gdk_error_trap_pop_ignored` with
`gdk_x11_display_error_trap_push ()` and
`gdk_x11_display_error_trap_pop_ignored ()` calls.

Nishal Kulkarni authored Apr 14, 2021 and Benjamin Berg committed Apr 14, 2021

Current behavior:
`gsd_night_light_get_property` function would set the wrong value,
value for PROP_SUNSET and PROP_TEMPERATURE was set to cached_sunrise

Minor Fix:
For PROP_SUNSET case set value to cached_sunset.
For PROP_TEMPERATURE case set value to cached_temperature.

We are opening the device asynchronously anyway. There is really no need
to sync the state immediately, we can simpl rely on the POLL handler to
do so later on from the mainloop.

The difference we should see is that the debug information about there
being no rfkill devices is gone. And, that some of the debug messages
will be slightly different.

The kernel may return a short read for rfkill events in case it is using
an older API version while g-s-d was compiled using the newer struct. As
this is perfectly valid, we need to check the read length against
RFKILL_EVENT_SIZE_V1 rather than the size of the struct.

Access to a /dev/foo device should never use buffered mode.

While debugging a gsd-rfkill issue I noticed in the g_debug output
that the rfkill-glib.c code now seems to be receiving bogus events.

Doing a strace I noticed some read(dev_rfkill_fd, buf, 8) calls,
even though we call:
  g_io_channel_read_chars(..., sizeof(struct rfkill_event, ...)

Which requests 9 bytes. The problem is the kernel expects us to
read 1 event per read() system-call and it will throw away
excess data. The idea is here that the rfkill_event struct can
be extended by adding new fields at the end and then userspace code
compiled against older kernel headers will still work since it
will only read the fields it knows in a single call and the
extra fields are thrown away.

Since the rfkill-glib.c code was using buffered-io and asking
g_io_channel_read_chars for 9 bytes when compiled against recent
kernel headers, what would happen is that 2 events would be consumed
in 2 read(fd, buf, 8) syscalls and then the first byte of the
second event read would be appended to the previous event and
the remaining 7 bytes would be used as the first 7 bytes for the
next event (and eventually completed with the first 2 bytes of
the next event, etc.). Leading to completely bogus events.

Enabling unbuffered mode fixes this.

Note this is a relatively new problem, caused by the kernel
recently extending the rfkill_event struct with an extra byte-field:
"rfkill: add a reason to the HW rfkill state"
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14486c82612a177cb910980c70ba900827ca0894

Before that kernel change the rfkill_event struct was 8 bytes large
which allowed us to get away with using buffered io here.