1. 22 Jul, 2021 19 commits
  2. 16 Jul, 2021 4 commits
    • Bastien Nocera's avatar
      build: Fix str/bool comparison · 28e28e9e
      Bastien Nocera authored
      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.
      28e28e9e
    • Bastien Nocera's avatar
      build: Bump required meson version · b6c23eb2
      Bastien Nocera authored
      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'}
      b6c23eb2
    • Bastien Nocera's avatar
      tests: Fix error during output checker exception · bd21f016
      Bastien Nocera authored
      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
      bd21f016
    • Benjamin Berg's avatar
  3. 13 Jul, 2021 1 commit
    • Kai-Heng Feng's avatar
      media-keys: Add one second delay between each rfkill event · f4dbcf3d
      Kai-Heng Feng authored
      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.
      f4dbcf3d
  4. 08 Jul, 2021 1 commit
  5. 28 Jun, 2021 1 commit
  6. 14 May, 2021 3 commits
  7. 12 May, 2021 1 commit
  8. 10 May, 2021 1 commit
  9. 25 Apr, 2021 1 commit
  10. 23 Apr, 2021 1 commit
  11. 14 Apr, 2021 4 commits
    • Benjamin Berg's avatar
      Release 40.0.1 · f33abac1
      Benjamin Berg authored and Benjamin Berg's avatar Benjamin Berg committed
      f33abac1
    • Nishal Kulkarni's avatar
      night-light: Minor get_property fix · f80f9938
      Nishal Kulkarni authored and Benjamin Berg's avatar Benjamin Berg committed
      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.
      f80f9938
    • Benjamin Berg's avatar
      rfkill: Do not sync state immediately when opening rfkill · 1ec87c5e
      Benjamin Berg authored
      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.
      1ec87c5e
    • Benjamin Berg's avatar
      rfkill: Fix rfkill event read length check · f6ce8d3f
      Benjamin Berg authored
      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.
      f6ce8d3f
  12. 13 Apr, 2021 1 commit
    • Hans de Goede's avatar
      rfkill: set the g_io_channel to unbuffered mode · d7a414cb
      Hans de Goede authored
      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.
      d7a414cb
  13. 07 Apr, 2021 1 commit
  14. 03 Apr, 2021 1 commit