1. 30 Jun, 2022 1 commit
  2. 16 Jun, 2022 1 commit
  3. 08 Jun, 2022 3 commits
  4. 01 Jun, 2022 1 commit
  5. 29 Dec, 2021 2 commits
  6. 01 Nov, 2021 1 commit
  7. 12 Jan, 2021 1 commit
  8. 06 Jan, 2021 3 commits
  9. 18 Oct, 2020 1 commit
    • Sebastian Krzyszkowiak's avatar
      foreign-toplevel-management: Report the surface's parent · 992841c2
      Sebastian Krzyszkowiak authored and Simon Ser's avatar Simon Ser committed
      Some window switchers, like mobile ones, may want to skip or group
      dialogs and other child windows on their window lists. Right now
      the only way to group toplevels is to use app_id, which will end
      up grouping too much in case of multiple toplevels with separate
      documents. Reporting on the toplevel's parent makes it easy to
      distinguish separate window stacks and act accordingly.
      992841c2
  10. 04 Sep, 2020 1 commit
    • Roman Gilg's avatar
      output-management-v1: add head identifying events · 50f3a8d3
      Roman Gilg authored and Simon Ser's avatar Simon Ser committed
      The following information through separate events are added:
      - make
      - model
      - serial_number
      
      This should allow clients to identify a display over different sessions and
      load configuration data back.
      
      A note is added that the description should be preferred when representing a
      display in UI to users but as a short form for example the model could be used
      in this case of course too.
      50f3a8d3
  11. 26 Aug, 2020 1 commit
    • Vlad Zahorodnii's avatar
      layer-shell: Require an initial commit · 95b627f2
      Vlad Zahorodnii authored and Simon Ser's avatar Simon Ser committed
      Currently, the compositor doesn't have enough information to decide if a
      given unmapped layer surface can be rearranged or rather configured.
      
      In order to address the ambiguity, this change adjusts the protocol spec
      saying that every client must perform an initial commit without a buffer
      attached after creating and setting up a layer surface.
      
      If the compositor knows that the initial state for a specified surface
      has not been committed yet, it can skip such a surface when re-arranging
      layer shell clients.
      95b627f2
  12. 30 Jun, 2020 2 commits
  13. 08 Jun, 2020 1 commit
  14. 04 Jun, 2020 1 commit
  15. 26 May, 2020 1 commit
  16. 17 May, 2020 1 commit
  17. 20 Feb, 2020 1 commit
  18. 10 Feb, 2020 2 commits
  19. 15 Jan, 2020 1 commit
  20. 31 Dec, 2019 1 commit
  21. 23 Nov, 2019 1 commit
  22. 22 Oct, 2019 1 commit
  23. 16 Oct, 2019 1 commit
  24. 05 Jul, 2019 2 commits
  25. 26 Apr, 2019 1 commit
  26. 16 Mar, 2019 6 commits
    • Simon Ser's avatar
      Address @dcz-purism's comments · d278d209
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      d278d209
    • Simon Ser's avatar
      Remove arbitrary modes · 125b006f
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      125b006f
    • Simon Ser's avatar
      Introduce custom modes · 6c576d10
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      6c576d10
    • Simon Ser's avatar
      Address @ddevault comments · c2d41a86
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      c2d41a86
    • Simon Ser's avatar
      All heads must be either enabled or disabled · 79817655
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      79817655
    • Simon Ser's avatar
      Add wlr-output-management-unstable-v1 · 4361785c
      Simon Ser authored and Drew DeVault's avatar Drew DeVault committed
      This commit adds a new output management protocol. It can be used to get the
      current output configuration and apply a new one. It's based on the GNOME D-Bus
      API [1] and the KDE protocol [2] [3].
      
      Goals:
      
      * High-level API, not a copy of KMS
      * Protect against races wrt. hotplugging
      * Extensible via backwards-compatible changes
      * Atomic (both when reading current config and when applying a new one)
      
      Features:
      
      * Read all outputs including disabled ones
        * Identification (name, description), available modes, physical size
        * Current mode, enabled/disabled
        * Position, scale, transform
      * Write
        * Modeset, enable/disable
        * Position, scale, transform
      
      Non-features (ie. features in GNOME or KDE excluded from this protocol):
      
      * No DPMS (left out for another protocol because it can operate on wl_output)
      * No gamma ramps (left out for another protocol, we already have one)
      * Cannot set the primary logical monitor and the presentation monitor (should be
        a separate protocol, could use wl_output)
      
      Available outputs and their current configuration are advertised when the client
      binds to the manager as "heads" (a head is an enabled or disabled output).
      
      Clients can create a configuration object, add some outputs to configure and
      apply the new state.
      
      The GNOME protocol has a concept of "logical monitor": it's a region of the
      screen you can assign physical monitors to. You can modeset and enable/disable
      physical monitors while you can position, scale and transform logical monitors.
      This nicely splits physical properties and logical properties. I've tried to
      design a protocol with a similar concept [4], but it turned out being pretty
      complicated since you need to have at least two extra objects (one to read the
      current logical monitors, one to configure them). I've decided against this
      approach for now.
      
      TODO:
      
      * Custom modes
      * Output cloning with different resolutions or underscan
      * Should transform & scale be per slot or per output device?
      * Check all of this makes sense for non-KMS outputs?
      * Make sure a compositor can offload everything to a helper client (ie. it
        doesn't apply an initial default modeset on hotplug)
      * Should some features be optional?
      * Better wording
      * Should zero modes mean the output doesn't support modes? What to do if an EDID
        is malformed and returns zero modes?
      
      Possible future features:
      
      * Modes aspect ratio and interlaced modes
      * Underscanning? (needs investigation)
      * is-builtin property for heads? (should this be in the compositor?)
      * Expose suggested panel orientation and tiling data?
      * Variable refresh rate? (needs investigation)
      
      References:
      
      [1]: https://gitlab.gnome.org/GNOME/mutter/blob/master/src/org.gnome.Mutter.DisplayConfig.xml#L292
      [2]: https://github.com/KDE/kwayland/blob/master/src/client/protocols/outputdevice.xml
      [3]: https://github.com/KDE/kwayland/blob/master/src/client/protocols/output-management.xml
      [4]: https://paste.sr.ht/%7Eemersion/8727ea50437fff3927c81c40c0ecc9c9885817ef
      4361785c
  27. 15 Feb, 2019 1 commit