1. 26 Mar, 2013 1 commit
  2. 18 Mar, 2013 1 commit
    • Tomasz Lis's avatar
      Full support of sRGB capable fbconfigs. · cf89aa53
      Tomasz Lis authored
      Changes to correctly initialize the sRGB capability attribute and
      transfer it between XServer and the client. Modifications include
      extension string, transferring visual config attribs and fbconfig
      attribs. Also, attribute is initialized in the modules which do not
      really use it (xquartz and xwin).
      This version advertises both ARB and EXT strings, and initializes
      the capability to default value of FALSE. It has corrected required
      GLX version and does not influence swrast. The sRGB capable attribute
      is attached only to those configs which do have this capability.
      Both ARB and EXT versions share the same GLX extension enabling bit.
      Signed-off-by: default avatarTomasz Lis <tomasz.lis@intel.com>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Signed-off-by: Keith Packard's avatarKeith Packard <keithp@keithp.com>
      cf89aa53
  3. 06 Mar, 2013 2 commits
    • Peter Hutterer's avatar
      xephyr: fix "set but not used warnings" · eadda231
      Peter Hutterer authored
      ephyrvideo.c: In function 'ephyrPutVideo':
      ephyrvideo.c:1009:42: warning: variable 'drw_h' set but not used
      ephyrvideo.c:1009:31: warning: variable 'drw_w' set but not used
      ephyrvideo.c:1009:20: warning: variable 'drw_y' set but not used
      ephyrvideo.c:1009:9: warning: variable 'drw_x' set but not used
      ephyrvideo.c: In function 'ephyrGetVideo':
      ephyrvideo.c:1058:42: warning: variable 'drw_h' set but not used
      ephyrvideo.c:1058:31: warning: variable 'drw_w' set but not used
      ephyrvideo.c:1058:20: warning: variable 'drw_y' set but not used
      ephyrvideo.c:1058:9: warning: variable 'drw_x' set but not used
      ephyrvideo.c: In function 'ephyrPutStill':
      ephyrvideo.c:1107:42: warning: variable 'drw_h' set but not used
      ephyrvideo.c:1107:31: warning: variable 'drw_w' set but not used
      ephyrvideo.c:1107:20: warning: variable 'drw_y' set but not used
      ephyrvideo.c:1107:9: warning: variable 'drw_x' set but not used
      ephyrvideo.c: In function 'ephyrGetStill':
      ephyrvideo.c:1156:42: warning: variable 'drw_h' set but not used
      ephyrvideo.c:1156:31: warning: variable 'drw_w' set but not used
      ephyrvideo.c:1156:20: warning: variable 'drw_y' set but not used
      ephyrvideo.c:1156:9: warning: variable 'drw_x' set but not used
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarRobert Morell <rmorell@nvidia.com>
      eadda231
    • Peter Hutterer's avatar
      kdrive: fix "set but not used" warnings · 4149ee8e
      Peter Hutterer authored
      kinput.c: In function 'KdEnqueueKeyboardEvent':
      kinput.c:1845:16: warning: variable 'ctrl' set but not used
      kinput.c:1844:17: warning: variable 'keyc' set but not used
      
      kinput.c: In function 'KdEnqueuePointerEvent':
      kinput.c:1887:12: warning: variable 'ms' set but not used
      
      kxv.c: In function 'KdXVDisable':
      kxv.c:1181:19: warning: variable 'ScreenPriv' set but not used
      
      mouse.c: In function 'ps2SkipInit':
      mouse.c:444:9: warning: variable 'skipping' set but not used
      mouse.c: In function 'ps2Init':
      mouse.c:473:10: warning: variable 'waiting' set but not used
      mouse.c:472:9: warning: variable 'skipping' set but not used
      
      fbdev.c: In function 'fbdevRandRSetConfig':
      fbdev.c:468:19: warning: variable 'newheight' set but not used
      fbdev.c:468:9: warning: variable 'newwidth' set but not used
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarRobert Morell <rmorell@nvidia.com>
      4149ee8e
  4. 05 Mar, 2013 1 commit
  5. 04 Mar, 2013 1 commit
  6. 01 Mar, 2013 3 commits
  7. 18 Feb, 2013 1 commit
  8. 15 Feb, 2013 2 commits
  9. 14 Feb, 2013 1 commit
  10. 12 Feb, 2013 1 commit
  11. 11 Feb, 2013 2 commits
  12. 08 Feb, 2013 3 commits
  13. 06 Feb, 2013 6 commits
    • Alan Coopersmith's avatar
      Avoid memory leak in ddc resort() if find_header() fails · 73974dd7
      Alan Coopersmith authored
      Call find_header first, returning on failure before calling malloc.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      73974dd7
    • Alan Coopersmith's avatar
      xf86XvMCScreenInit: Avoid leak if dixRegisterPrivateKey fails · b1129a1f
      Alan Coopersmith authored
      Found by parfait 1.1 memory analyser:
         Memory leak of pointer 'pAdapt' allocated with malloc((88 * num_adaptors))
              at line 162 of hw/xfree86/common/xf86xvmc.c in function 'xf86XvMCScreenInit'.
                'pAdapt' allocated at line 158 with malloc((88 * num_adaptors)).
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      b1129a1f
    • Alan Coopersmith's avatar
      Avoid memory leak on realloc failure in localRegisterFreeBoxCallback · 563db909
      Alan Coopersmith authored
      Also avoids leaving invalid pointers in structures if realloc had to
      move them elsewhere to make them larger.
      
      Found by parfait 1.1 code analyzer:
         Memory leak of pointer 'newCallbacks' allocated with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1)))
              at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
                'newCallbacks' allocated at line 320 with realloc(((char*)offman->FreeBoxesUpdateCallback), (8 * (offman->NumCallbacks + 1))).
                newCallbacks leaks when newCallbacks != NULL at line 327.
         Memory leak of pointer 'newPrivates' allocated with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1)))
              at line 328 of hw/xfree86/common/xf86fbman.c in function 'localRegisterFreeBoxCallback'.
                'newPrivates' allocated at line 324 with realloc(((char*)offman->devPrivates), (8 * (offman->NumCallbacks + 1))).
                newPrivates leaks when newCallbacks == NULL at line 327.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      563db909
    • Alan Coopersmith's avatar
      Avoid NULL pointer dereference in xf86TokenToOptinfo if token not found · 08f75d3a
      Alan Coopersmith authored
      Reported by parfait 1.1 code analyzer:
      
      Error: Null pointer dereference (CWE 476)
         Read from null pointer 'p'
              at line 746 of hw/xfree86/common/xf86Option.c in function 'xf86TokenToOptName'.
                Function 'xf86TokenToOptinfo' may return constant 'NULL' at line 721, called at line 745.
                Null pointer introduced at line 721 in function 'xf86TokenToOptinfo'.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      08f75d3a
    • Alan Coopersmith's avatar
      Make xf86ValidateModes actually copy clock range list to screen pointer · c1c01e35
      Alan Coopersmith authored
      Our in-house parfait 1.1 code analysis tool complained that every exit
      path from xf86ValidateModes() in hw/xfree86/common/xf86Mode.c leaks the
      storeClockRanges allocation made at line 1501 with XNFalloc.
      
      Investigating, it seems that this code to copy the clock range list to
      the clockRanges list in the screen pointer is just plain insane, and
      according to git, has been since we first imported it from XFree86.
      
      We start at line 1495 by walking the linked list from scrp->clockRanges
      until we find the end.  But that was just a diversion, since we've found
      the end and immediately forgotten it, and thus at 1499 we know that
      storeClockRanges is NULL, but that's not a problem since we're going to
      immediately overwrite that value as the first thing in the loop.
      
      So we move on through this loop at 1499, which takes us through the
      linked list from the clockRanges variable, and for every entry in
      that list allocates a new structure and copies cp to it.  If we've
      not filled in the screen's clockRanges pointer yet, we set it to
      the first storeClockRanges we copied from cp.   Otherwise, as best
      I can tell, we just drop it into memory and let it leak away, as
      parfait warned.
      
      And then we hit the loop action, which if we haven't hit the end of
      the cp list, advances cp to the next item in the list, and then just
      for the fun of it, also sets storeClockRanges to the ->next pointer it
      has just copied from cp as well, even though it's going to overwrite
      it as the very first instruction in the loop body.
      
      v2: rewritten using nt_list_* macros from Xorg's list.h header
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      c1c01e35
    • Alan Coopersmith's avatar
      Free keymap on error in Xephyr's hostx_load_keymap · 89badba0
      Alan Coopersmith authored
      Found by parfait 1.1 code analyser:
         Memory leak of pointer 'keymap' allocated with XGetKeyboardMapping(HostX.dpy, min_keycode, ((max_keycode - min_keycode) + 1), &host_width)
              at line 861 of hw/kdrive/ephyr/hostx.c in function 'hostx_load_keymap'.
                'keymap' allocated at line 845 with XGetKeyboardMapping(HostX.dpy, min_keycode, ((max_keycode - min_keycode) + 1), &host_width).
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      89badba0
  14. 16 Jan, 2013 7 commits
  15. 11 Jan, 2013 5 commits
  16. 10 Jan, 2013 3 commits