1. 26 Nov, 2020 2 commits
    • Olivier Fourdan's avatar
      modesetting: Fix build with DebugPresent() enabled · 3ce05a44
      Olivier Fourdan authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      By default, the macro DebugPresent() is a no-op but it can be enabled
      at build time for debugging purpose.
      
      However, doing so prevents the code to build because one debug statement
      tries to make use of a non-existent variable:
      
        present.c: In function ‘ms_present_queue_vblank’:
        present.c:147:18: error: ‘vbl’ undeclared (first use in this function)
          147 |                  vbl.request.sequence));
              |                  ^~~
        present.c:49:32: note: in definition of macro ‘DebugPresent’
          49 | #define DebugPresent(x) ErrorF x
             |                                ^
      
      Fix the build with DebugPresent() by removing the vbl variable from the
      debug message.
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      3ce05a44
    • Erik Kurzinger's avatar
      GLX: fix context render type queries · 95b79aa9
      Erik Kurzinger authored and Adam Jackson's avatar Adam Jackson committed
      Querying the GLX_RENDER_TYPE of a GLX context via glXQueryContext will
      currently return the render type of the context's FB config, which is
      a bitmask of GLX_RGBA_BIT / GLX_COLOR_INDEX_BIT / ... values. However,
      this query should really return the render type that was specified
      when creating the context, which is one of GLX_RGBA_TYPE /
      GLX_COLOR_INDEX_TYPE / .... To enable this, save the render type when
      creating a new context (defaulting to GLX_RGBA_TYPE if unspecified),
      and then include this value in the context attributes sent to clients.
      95b79aa9
  2. 25 Nov, 2020 13 commits
  3. 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
  4. 23 Nov, 2020 1 commit
  5. 19 Nov, 2020 1 commit
  6. 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
  7. 17 Nov, 2020 7 commits
  8. 12 Nov, 2020 1 commit
  9. 10 Nov, 2020 3 commits
  10. 09 Nov, 2020 4 commits
  11. 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
  12. 30 Oct, 2020 1 commit
  13. 29 Oct, 2020 1 commit