1. 24 Jun, 2019 14 commits
  2. 22 Jun, 2019 2 commits
  3. 20 Jun, 2019 24 commits
    • Niels De Graef's avatar
      cogl: Remove CoglError wrapper · 70bacb94
      Niels De Graef authored
      CoglError was added at a certain point to remove the hard dependency on
      GLib, but since this can't be avoided inside mutter, let's remove this
      whole abstraction.
    • Jonas Ådahl's avatar
      kms-update: Seal updates when posting them · 57dfe469
      Jonas Ådahl authored
      This makes sure that we won't accidentally change KMS transaction
      updates after they have been posted.
    • Jonas Ådahl's avatar
      backends/native: Add some KMS debug logging · 22a91f23
      Jonas Ådahl authored
      Using the g_debug() macro. Set G_DEBUG_MESSAGES to "mutter" to activate
    • Jonas Ådahl's avatar
      kms: Add high level code documentation · 6aa10266
      Jonas Ådahl authored
      Document the high level components of the KMS abstraction.
    • Jonas Ådahl's avatar
      backend/native: Add and use transactional KMS API · 75dff3e7
      Jonas Ådahl authored
      This commit introduces, and makes use of, a transactional API used for
      setting up KMS state, later to be applied, potentially atomically. From
      an API point of view, so is always the case, but in the current
      implementation, it still uses legacy drmMode* API to apply the state
      The API consists of various buliding blocks:
       * MetaKmsUpdate - a set of configuration changes, the higher level
      handle for handing over configuration to the impl backend. It's used to
      set mode, assign framebuffers to planes, queue page flips and set
      connector properties.
       * MetaKmsPlaneAssignment - the assignment of a framebuffer to a plane.
      Currently used to map a framebuffer to the primary plane of a CRTC. In
      the legacy KMS implementation, the plane assignment is used to derive
      the framebuffer used for mode setting and page flipping.
      This also means various high level changes:
      State, excluding configuring the cursor plane and creating/destroying
      DRM framebuffer handles, are applied in the end of a clutter frame, in
      one go. From an API point of view, this is done atomically, but as
      mentioned, only the non-atomic implementation exists so far.
      From MetaRendererNative's point of view, a page flip now initially
      always succeeds; the handling of EBUSY errors are done asynchronously in
      the MetaKmsImpl backend (still by retrying at refresh rate, but
      postponing flip callbacks instead of manipulating the frame clock).
      Handling of falling back to mode setting instead of page flipping is
      notified after the fact by a more precise page flip feedback API.
      EGLStream based page flipping relies on the impl backend not being
      atomic, as the page flipping is done in the EGLStream backend (e.g.
      nvidia driver). It uses a 'custom' page flip queueing method, keeping
      the EGLStream logic inside meta-renderer-native.c.
      Page flip handling is moved to meta-kms-impl-device.c from
      meta-gpu-kms.c. It goes via an extra idle callback before reaching
      meta-renderer-native.c to make sure callbacks are invoked outside of the
      impl context.
      While dummy power save page flipping is kept in meta-renderer-native.c, the
      EBUSY handling is moved to meta-kms-impl-simple.c. Instead of freezing the
      frame clock, actual page flip callbacks are postponed until all EBUSY retries
      have either succeeded or failed due to some other error than EBUSY. This
      effectively inhibits new frames to be drawn, meaning we won't stall waiting on
      the file descriptor for pending page flips.
    • Jonas Ådahl's avatar
      logical-monitor: Pass output when iterating over CRTCs · bea76004
      Jonas Ådahl authored
      While not currently used by any users, it'll be useful in future
    • Jonas Ådahl's avatar
      backend/native: Move some KMS utilities to its own file · 8932388d
      Jonas Ådahl authored
      They are not strictly related to any of the KMS objects, and should be
      reusable without adding a dependency on the non-meta-kms-* files in
    • Jonas Ådahl's avatar
      kms: Add API to register impl file descriptors · 2238c9f1
      Jonas Ådahl authored
      To let the MetaKmsImpl implementation register file descriptor GSource
      where the invoke function is ensured to be executed in the impl context.
    • Jonas Ådahl's avatar
      kms: Add API to add a GSource that'll be invoked in the impl context · ca21ca67
      Jonas Ådahl authored
      The MetaKmsImpl implementation may need to add a GSource that should be
      invoked in the right context; e.g. a idle callback, timeout etc. It
      cannot just add it itself, since it's the responsibility of MetaKms to
      determine what is the impl context and what is the main context, so add
      API to MetaKms to ensure the callback is invoked correctly.
      It's the responsibility of the caller to eventually remove and destroy
      the GSource.
    • Jonas Ådahl's avatar
      kms: Add API to post callbacks out of the impl context · 2bbd2e55
      Jonas Ådahl authored
      While the current impl context is in the same thread as the main
      context, the separation still exists, and to post callbacks from the
      impl context, it must pass MetaKms to make sure the callback is invoked
      in the right context.
    • Jonas Ådahl's avatar
    • Jonas Ådahl's avatar
      crtc/kms: Use MetaKmsPlane to check supported rotations and formats · d84c7269
      Jonas Ådahl authored
      Instead of manually retrieving supported transforms and formats from the
      primary plane of the CRTC, use the MetaKmsPlane abstraction to find the
      primary plane of the CRTC and check compatibility using the
      MetaKmsPlane API. This removes the last user of direct KMS API usage
      except for applying configuration.
    • Jonas Ådahl's avatar
      gpu/kms: Init global mode list from MetaKmsConnectors · aba68931
      Jonas Ådahl authored
      Instead of iterating over the available drmModeConnector objects to
      construct a GPU wide mode list, use the state managed by
      MetaKmsConnector. This also removes the last user of drmModeRes from
    • Jonas Ådahl's avatar
      output/kms: Outsource connector state fetching to MetaKmsConnector · f2d9a110
      Jonas Ådahl authored
      As with CRTC state, variable connector state is now fetched via the
      MetaKmsConnector. The existance of a connector state is equivalent of
      the connector being connected. MetaOutputKms is changed to fetch
      variable connector state via MetaKmsConnector intsead of KMS directly.
      The drmModeConnector is still used for constructing the MetaOutputKms to
      find properties used for applying configuration.
    • Jonas Ådahl's avatar
      crtc/kms: Outsource CRTC state fetching to MetaKmsCrtc · 596376c4
      Jonas Ådahl authored
      Move reading state into a struct for MetaCrtcKms to use instead of
      querying KMS itself. The state is fetched in the impl context, but
      consists of only simple data types, so is made accessible publicly. As
      of this, MetaCrtcKms construction does not involve any manual KMS
      interaction outside of the MetaKms abstraction.
    • Jonas Ådahl's avatar
    • Jonas Ådahl's avatar
      kms: Add connector representation · f59d62bc
      Jonas Ådahl authored
      Represents drmModeConnector; both connected and disconnected. Currently
      only provides non-changing meta data. MetaOutputKms is changed to use
      MetaKmsConnector to get basic metadata, but variable metadata, those
      changing depending on what is connected (e.g. physical dimension, EDID,
      etc), are still manually retrieved by MetaOutputKms.
    • Jonas Ådahl's avatar
      gpu/kms: Fix connector id type in helper · 5d5d2965
      Jonas Ådahl authored
      It's a uint32_t, not a long.
    • Jonas Ådahl's avatar
      output/kms: Make drmModeEncoderPtr array local · 065bf752
      Jonas Ådahl authored
      It was only used within one function, where it was always created, but
      still was kept around indefinitely for no reason. Lets get rid of it
      from the MetaOutputKms struct.
    • Jonas Ådahl's avatar
      kms: Add plane representation · 4d3e8043
      Jonas Ådahl authored
      A plane is one of three possible: primary, overlay and cursor. Each
      plane can have various properties, such as possible rotations, formats
      etc. Each plane can also be used with a set of CRTCs.
      A primary plane is the "backdrop" of a CRTC, i.e. the primary output for
      the composited frame that covers the whole CRTC. In general, mutter
      composites to a stage view frame onto a framebuffer that is then put on
      the primary plane.
      An overlay plane is a rectangular area that can be displayed on top of
      the primary plane. Eventually it will be used to place non-fullscreen
      surfaces, potentially avoiding stage redraws.
      A cursor plane is a plane placed on top of all the other planes, usually
      used to put the mouse cursor sprite.
      Initially, we only fetch the rotation properties, and we so far
      blacklist all rotations except ones that ends up with the same
      dimensions as with no rotations. This is because non-180° rotations
      doesn't work yet due to incorrect buffer modifiers. To make it possible
      to use non-180° rotations, changes necessary include among other things
      finding compatible modifiers using atomic modesetting. Until then,
      simply blacklist the ones we know doesn't work.
    • Jonas Ådahl's avatar
      kms: Add CRTC representation · 15a2ccd2
      Jonas Ådahl authored
      Add MetaKmsCrtc to represent a CRTC on the associated device. Change
      MetaCrtcKms to use the ones discovered by the KMS abstraction. It still
      reads the resources handed over by MetaGpuKms, but eventually it will
      use only MetaKmsCrtc.
      MetaKmsCrtc is a type of object that is usable both from an impl task
      and from outside. All the API exposed via the non-private header is
      expected to be accessible from outside of the meta-kms namespace.
    • Jonas Ådahl's avatar
      backends/native: Add basic KMS abstraction building blocks · fef5753a
      Jonas Ådahl authored
      The intention with KMS abstraction is to hide away accessing the drm
      functions behind an API that allows us to have different kind of KMS
      implementations, including legacy non-atomic and atomic. The intention
      is also that the code interacting with the drm device should be able to
      be run in a different thread than the main thread. This means that we
      need to make sure that all drm*() API usage must only occur from within
      tasks that eventually can be run in the dedicated thread.
      The idea here is that MetaKms provides a outward facing API other places
      of mutter can use (e.g. MetaGpuKms and friends), while MetaKmsImpl is
      an internal implementation that only gets interacted with via "tasks"
      posted via the MetaKms object. These tasks will in the future
      potentially be run on the dedicated KMS thread. Initially, we don't
      create any new threads.
      Likewise, MetaKmsDevice is a outward facing representation of a KMS
      device, while MetaKmsImplDevice is the corresponding implementation,
      which only runs from within the MetaKmsImpl tasks.
      This commit only moves opening and closing the device to this new API,
      while leaking the fd outside of the impl enclosure, effectively making
      the isolation for drm*() calls pointless. This, however, is necessary to
      allow gradual porting of drm interaction, and eventually the file
      descriptor in MetaGpuKms will be removed. For now, it's harmless, since
      everything still run in the main thread.
    • Jonas Ådahl's avatar
    • Jonas Ådahl's avatar
      backend: Move GPU ownership from the monitor manager to the backend · 5c500ad4
      Jonas Ådahl authored
      Lets work towards making MetaMonitorManager about managing monitors, and
      not about managing GPUs. This changes other units to keep a pointer to
      the backend instead of a monitor manager, in case their ownership
      changed, or their main usage of the monitor manager was to look up GPUs.