1. 24 Nov, 2020 1 commit
    • Jon Turney's avatar
      hw/xwin: Fix building with -fno-common · bb7aab6a
      Jon Turney authored
      Provide an actual definition of noDriExtension where used, rather than a
      tentative definition in a header, to fix compilation with -fno-common
      (the default with gcc 10).
      bb7aab6a
  2. 23 Nov, 2020 1 commit
  3. 19 Nov, 2020 1 commit
  4. 18 Nov, 2020 4 commits
    • Alan Coopersmith's avatar
      int10: wrap entire V_ADDR_R* macros in parens for safer expansion · e5386011
      Alan Coopersmith authored
      
      
      Resolves warnings from Oracle Parfait static analyser:
      
      Error: Misleading macro
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '|' operator has higher precedence than ternary '?:' operator inside macro body at line 431
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 431
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 431
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 442
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 442
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '|' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 441
         Misleading macro [misleading-macro]:
            misleading evaluation of ternary '?:' operator in expansion of macro V_ADDR_RB due to missing parentheses
              at line 392 of hw/xfree86/int10/generic.c.
              '<<' operator has higher precedence than ternary '?:' operator inside macro body at line 443
              low precedence ternary '?:' operator is hidden by expansion of macro V_ADDR_RB at line 443
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      e5386011
    • Alan Coopersmith's avatar
      xkb: always set *mask_rtrn in XkbVirtualModsToReal · a6574033
      Alan Coopersmith authored
      
      
      Resolves warning from Oracle Parfait static analyser:
      
      Error: Uninitialised memory
         Uninitialised memory variable [uninitialised-mem-var] (CWE 457):
            Possible access to uninitialised memory referenced by variable 'mask'
              at line 721 of xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'.
              Path in callee avoiding write at line 720
                mask allocated at line 718
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      a6574033
    • Alan Coopersmith's avatar
      dmx: example code should set a good example · 034e7926
      Alan Coopersmith authored
      
      
      Resolves warning from Oracle Parfait static analyser:
      
      Error: Unchecked result
         Unchecked result [unchecked-result-call-X]:
            Unchecked return value from call to XOpenDisplay. Value display must be ch
      ecked to ensure this function was successful.
              at line 73 of hw/dmx/examples/xbell.c in function 'main'.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      034e7926
    • Alan Coopersmith's avatar
      AddInputDevice: only need to check once if we failed to calloc dev · d00594eb
      Alan Coopersmith authored
      Resolves warning from Oracle Parfait static analyser:
      
      Warning: Impossible or redundant condition
         Impossible or redundant condition [impossible-redundant-condition]:
            Condition 'dev != NULL' of branch is determined by previous branch
              at line 270 of dix/devices.c in function 'AddInputDevice'.
                Condition 'dev != NULL' from this branch implies following branch is always true at line 262
      
      Fixes: commit 493ad833
      
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      d00594eb
  5. 17 Nov, 2020 7 commits
  6. 12 Nov, 2020 1 commit
  7. 10 Nov, 2020 3 commits
  8. 09 Nov, 2020 4 commits
  9. 04 Nov, 2020 1 commit
    • Alex Goins's avatar
      glamor: Update pixmap's devKind when making it exportable · 7a7e55c5
      Alex Goins authored and Aaron Plattner's avatar Aaron Plattner committed
      When making a pixmap exportable, glamor will currently create a temporary
      exported pixmap backed by a GBM bo, with the devKind updated to the stride of
      the bo. However, when the backing of the exported pixmap is swapped into the
      original, the devKind of the original is not updated.
      
      Some GBM bos may get implicitly padded, in which case the devKind of the pixmap
      will not match the stride of the backing bo. For example, an 800x600 pixmap will
      have a devKind of 3200, but the bo's stride will be 3328. This can cause
      corruption with PRIME, when the sink uses the wrong stride to display the shared
      pixmap.
      
      This commit changes glamor_make_pixmap_exportable() to update the devKind of the
      original pixmap after it swaps exported pixmap's backing into it, keeping
      everything consistent.
      
      Fixes issue #1018
      
      .
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      7a7e55c5
  10. 30 Oct, 2020 1 commit
  11. 29 Oct, 2020 4 commits
  12. 30 Sep, 2020 1 commit
  13. 28 Sep, 2020 2 commits
  14. 26 Sep, 2020 1 commit
  15. 25 Sep, 2020 2 commits
    • Kishore409's avatar
      modesetting: keep going if a modeset fails on EnterVT · efb3abdd
      Kishore409 authored and Martin Roukala's avatar Martin Roukala committed
      
      
      There was a time when setting a mode on a CRTC would not depend on the
      associated connector's state. If a mode had been set successfully once,
      it would mean it would work later on.
      
      This changed with the introduction of new connectors type that now
      require a link training sequence (DP, HDMI 2.0), and that means that
      some events may have happened while the X server was not master that
      would then prevent the mode from successfully be restored to its
      previous state.
      
      This patch relaxes the requirement that all modes should be restored on
      EnterVT, or the entire X-Server would go down by allowing modesets to
      fail (with some warnings). If a modeset fails, the CRTC will be
      disabled, and a RandR event will be sent for the desktop environment to
      fix the situation as well as possible.
      
      Additional patches might be needed to make sure that the user would
      never be left with all screens black in some scenarios.
      
      v2 (Martin Peres):
       - whitespace fixes
       - remove the uevent handling (it is done in a previous patch)
       - improve the commit message
       - reduce the size of the patch by not changing lines needlessly
       - return FALSE if one modeset fails in ignore mode
       - add comments/todos to explain why we do things
       - disable the CRTCs that failed the modeset
      Signed-off-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Closes: #1010
      efb3abdd
    • Martin Roukala's avatar
      modesetting: check the kms state on EnterVT · 293cf660
      Martin Roukala authored
      
      
      Normally, we would receive a uevent coming from Linux's DRM subsystem,
      which would trigger the check for disappearing/appearing resources.
      However, this event is not received when X is not master (another VT
      is selected), and so the userspace / desktop environment would not be
      notified about the changes that happened while X wasn't master.
      
      To fix the issue, this patch forces a refresh on EnterVT by splitting
      the kms-checking code from the uevent handling into its own (exported)
      function called drmmode_update_kms_state. This function is then called
      from both the uevent-handling function, and on EnterVT right before
      restoring the modes.
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      293cf660
  16. 24 Sep, 2020 2 commits
  17. 22 Sep, 2020 3 commits
  18. 21 Sep, 2020 1 commit