1. 14 Apr, 2021 2 commits
    • Benjamin Berg's avatar
      Release 3.38.2 · e9c50573
      Benjamin Berg authored
    • Hans de Goede's avatar
      rfkill: set the g_io_channel to unbuffered mode · d2200632
      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"
      Before that kernel change the rfkill_event struct was 8 bytes large
      which allowed us to get away with using buffered io here.
  2. 21 Feb, 2021 2 commits
  3. 13 Jan, 2021 1 commit
  4. 11 Jan, 2021 3 commits
  5. 10 Jan, 2021 1 commit
  6. 06 Jan, 2021 1 commit
    • Bastien Nocera's avatar
      power: Don't warn more than once per warning level for devices · 60621b90
      Bastien Nocera authored
      A lot of wireless input devices, such as Logitech mice and touchpads, or
      Bluetooth LE input devices, will disconnect and reconnect frequently
      from the computer when unused.
      This causes a problem when the battery on the device is low because
      a new notification will be generated each time the device reconnects, as
      if it was the first time it connected.
      Saving the last warning-level for every external peripheral ensures that
      we only emit one low battery notification for each warning-level, when
      the threshold is crossed, rather than at every reconnect.
      The last warning-level is not stored, so a new session, or a reboot will
      cause devices to warn again once.
      Helps: #108
  7. 11 Dec, 2020 1 commit
  8. 03 Dec, 2020 1 commit
  9. 24 Nov, 2020 1 commit
  10. 20 Nov, 2020 1 commit
  11. 01 Nov, 2020 1 commit
  12. 27 Oct, 2020 1 commit
    • Benjamin Berg's avatar
      power: Never register sleep timeout for logout in GDM · c1f14103
      Benjamin Berg authored
      We already suppress logout actions in GDM (10aa1714, power: Avoid
      automatic logout in GDM/greeter). However, while this prevents the
      action, we may still warn.
      Change it so that the corresponding timeouts will never be registered.
      Leave the guard in gnome_session_logout but add a warning as we should
      never be hitting that code path.
  13. 18 Oct, 2020 1 commit
  14. 15 Oct, 2020 1 commit
    • Benjamin Berg's avatar
      power: Avoid automatic logout in GDM/greeter · 10aa1714
      Benjamin Berg authored and Benjamin Berg's avatar Benjamin Berg committed
      In GDM sessions (greeter, initial-setup), it does not make sense to
      automatically logout. This can happen if the system wide default is
      changed to default to the "logout" action.
      Note that we already use the RUNNING_UNDER_GDM environment variable in
      the keyboard plugin currently. So doing this is likely sane, even if we
      probably want a more elegant strategy to detect whether we are in a
      "login" session.
  15. 10 Oct, 2020 1 commit
    • Jing Wang's avatar
      Fix crashing when atime is not present · 647c0af7
      Jing Wang authored
      Recent changes to gio omit the atime instead of setting it to an out of range value.
      Fixes #556, but note this doesn't fix the fact that gio omitted atime on a system where atime should have been available.
  16. 08 Oct, 2020 2 commits
  17. 30 Sep, 2020 2 commits
  18. 28 Sep, 2020 1 commit
  19. 22 Sep, 2020 1 commit
  20. 20 Sep, 2020 1 commit
  21. 15 Sep, 2020 2 commits
  22. 13 Sep, 2020 1 commit
  23. 12 Sep, 2020 2 commits
  24. 10 Sep, 2020 1 commit
  25. 07 Sep, 2020 4 commits
  26. 06 Sep, 2020 4 commits