1. 08 Oct, 2018 1 commit
    • Daniel Drake's avatar
      monitor-manager: use MonitorsConfig to track switch_config · 6267732b
      Daniel Drake authored
      When constructing MetaMonitorsConfig objects, store which type
      of switch_config they are for (or UNKNOWN if it is not such
      type of config).
      Stop unconditionally setting current_switch_config to UNKNOWN when
      handling monitors changed events. Instead, set it to the switch_config
      type stored in the MonitorsConfig in the codepath that updates logical
      state. In addition to being called in the hotplug case along the same
      code flow that generates monitors changed events, this is also called
      in the coldplug case where a secondary monitor was connected before
      mutter was started.
      When creating the default linear display config, create it as a
      switch_config so that internal state gets updated to represent
      linear mode when this config is used.
      The previous behaviour of unconditionally resetting current_switch_config
      to UNKNOWN was breaking the internal state machine for display config
      switching, causing misbehaviour in gnome-shell's switchMonitor UI when
      using display switch hotkeys. The lack of internal tracking when the
      displays are already in the default "Join Displays" linear mode was
      then causing the first display switch hotkey press to do nothing
      (it would attempt to select "Join Displays" mode, but that was already
      Fixes: #281
  2. 30 Nov, 2017 1 commit
    • Jonas Ådahl's avatar
      monitor-manager: Compare keys when checking whether a config is complete · b7518c86
      Jonas Ådahl authored
      We only counted configured monitors and whether the config was
      applicable (could be assigned), howeverwe didn't include disabled
      monitors when comparing. This could caused incorrect configurations to
      be applied when trying to use the previous configuration.
      One scenario where this happened was one a system with one laptop
      screen and one external monitor that was hot plugged some point after
      start up. When the laptop lid was closed, the 'previous configuration'
      being the configuration where only the laptop panel was enabled, passed
      'is-complete' check as the number of configured monitors were correct,
      and the configuration was applicable.
      Avoid this issue by simply comparing the configuration key of the
      previous configuration and the configuration key of the current state.
      This correctly identifies a laptop panel with the lid closed as
      inaccessible, thus doesn't incorrectly revert to the previous
  3. 02 Oct, 2017 1 commit
  4. 21 Aug, 2017 2 commits
    • Jonas Ådahl's avatar
      monitor-config-manager: Keep short history of configurations · b140e7fb
      Jonas Ådahl authored
      In order to go back in monitor configurations, save them to a history.
      The history is implemented as a max 3 element long queue, where newly
      set configurations are pushed to the head, and old are popped from the
      The difference between using a single previous config reference and a
      queue is that we can now remember the configuration used prior to a
      D-Bus triggered configuration when the user discarded the configuration.
      This will later be used to restore a previous configuration when a
      laptop lid is opened.
    • Jonas Ådahl's avatar
      Migrate old monitor configuration files to new system · bc316246
      Jonas Ådahl authored
      This commit changes the new configuration system to use monitors.xml
      instead of monitors-experimental.xml. When starting up and the
      monitors.xml file is loaded, if a legacy monitors.xml file is
      discovered (it has the version number 1), an attempt is made to migrate
      the stored configuration onto the new system.
      This is done in two steps:
      1) Parsing and translation of the old configuration. This works by
      parsing file using the mostly the old parser, but then translating the
      resulting configuration structs into the new configuration system. As
      the legacy configuration system doesn't carry over some state (such as
      tiling and scale used), some things are not available. For tiling, the
      migration paths makes an attempt to discover tiled monitors by
      comparing EDID data, and guessing what the main tile is. Determination
      of the scale of a migrated configuration is postponed until the
      configuration is actually applied. This works by flagging the
      configuration as 'migrated'.
      2) Finishing the migration when applying. When a configuration with the
      'migrated' flag is retrieved from the configuration store, the final
      step of the migration is taken place. This involves calculating the
      preferred scale given the mode configured, while making sure this
      doesn't result in any overlapping logical monitor regions etc.
  5. 19 Jul, 2017 1 commit
    • Rui Matos's avatar
      backends: Add API to switch to predetermined monitor configurations · 3f9c5823
      Rui Matos authored
      This will allows us to support the XF86Display key present on some
      laptops, directly in mutter. This is also known, in evdev, as
      The common usage for this key is to alternate between a few well known
      multi-monitor configurations though these aren't officially
      standardized. As an example, Lenovo documents it as:
      "Switches the display output location between the computer display
      and an external monitor."
      On this patch, we're just introducing the configurations that have been
      implemented in g-s-d until now, which go a bit beyond the above
  6. 14 Jul, 2017 3 commits
  7. 26 May, 2017 1 commit
  8. 07 Apr, 2017 6 commits
  9. 25 Jan, 2017 6 commits