1. 28 Oct, 2009 1 commit
  2. 28 Sep, 2009 1 commit
  3. 17 Jul, 2009 2 commits
  4. 23 Jun, 2009 1 commit
  5. 22 May, 2009 1 commit
  6. 15 May, 2009 1 commit
  7. 22 Apr, 2009 1 commit
  8. 01 Apr, 2009 1 commit
  9. 14 Feb, 2009 1 commit
  10. 13 Feb, 2009 1 commit
    • Adam Jackson's avatar
      EDID: Hack for 1366x768 in standard timing descriptors · 20ac3140
      Adam Jackson authored
      All you get for standard timing descriptors is horizontal size in
      multiples of 8 pixels (which means you can't say 1366) and height in
      terms of aspect ratio (which means you can't say 768).  You'd like to
      just fuzzy-match this by walking the DMT list for sufficiently close
      modes, but you can't because DMT is useless and only defines a 1360x768
      mode, because it's _also_ specified in terms of character cells despite
      providing pixel exact timings.  Neither can you use CVT or GTF to
      generate the timings, because they _also_ believe that modes have to be
      a multiple of 8 pixels.
      
      You'd also hope you could find a timing definition for this in CEA, but
      you can't because CEA only defines transmission formats that actually
      exist.  So there's 480p, 720p, and 1080p, but no 768p.  And why would
      there be, after all, the encoded signal is never 768p so obviously no
      one would ever make a display in that format.
      
      So instead, make a CVT mode since that's likely to be handled well by
      just about everything, smash the horizontal active down by 2, and shift
      the sync pulse by 1.  Underscanning the hard way.
      
      Pass the suicide.
      20ac3140
  11. 03 Dec, 2008 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Rework symbol visibility for easier maintenance · 49f77fff
      Paulo Cesar Pereira de Andrade authored
        Save in a few special cases, _X_EXPORT should not be used in C source
      files. Instead, it should be used in headers, and the proper C source
      include that header. Some special cases are symbols that need to be
      shared between modules, but not expected to be used by external drivers,
      and symbols that are accessible via LoaderSymbol/dlopen.
      
        This patch also adds conditionally some new sdk header files, depending
      on extensions enabled. These files were added to match pattern for
      other extensions/modules, that is, have the headers "deciding" symbol
      visibility in the sdk. These headers are:
      o Xext/panoramiXsrv.h, Xext/panoramiX.h
      o fbpict.h (unconditionally)
      o vidmodeproc.h
      o mioverlay.h (unconditionally, used only by xaa)
      o xfixes.h (unconditionally, symbols required by dri2)
      
        LoaderSymbol and similar functions now don't have different prototypes,
      in loaderProcs.h and xf86Module.h, so that both headers can be included,
      without the need of defining IN_LOADER.
      
        xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
      not exported (and with a comment about it).
      49f77fff
  12. 28 Nov, 2008 1 commit
    • Paulo Cesar Pereira de Andrade's avatar
      Make visible symbols required by xorg modules. · 31285d06
      Paulo Cesar Pereira de Andrade authored
        This patch exports all symbols required by the compilable
      (in a x86 linux computer) xorg/driver/* modules.
        Still missing symbols worth mentioning are:
      
      sunleo
      	miFindMaxBand no longer available
      
      intel	(uxa/uxa-accel.c)
      	fbShmPutImage no longer available (and should have been static)
      
      mga
      	MGAGetClientPointer (should come from matrox's libhal)
      
        This is not a definitive "visibility" patch, as all it does is to
      export missing symbols, but the modules that current don't compile,
      may require more symbols once fixed, and third party drivers should
      also require more symbols exported.
        A "definitive" patch should export symbols defined in the sdk.
      31285d06
  13. 25 Nov, 2008 1 commit
    • Alan Coopersmith's avatar
      Fix const-mismatch warnings for DisplayModePtr's · d5f9a131
      Alan Coopersmith authored
      Includes fixes for:
      "xf86Config.c", line 2434: warning: argument #1 is incompatible with prototype:
      	prototype: pointer to struct _DisplayModeRec: "xf86.h", line 351
      	argument : pointer to const struct _DisplayModeRec
      
      "xf86EdidModes.c", line 312: warning: argument #1 is incompatible with prototype:
      	prototype: pointer to struct _DisplayModeRec: "../../../hw/xfree86/common/xf86.h", line 351
      	argument : pointer to const struct _DisplayModeRec
      
      "xf86EdidModes.c", line 438: warning: assignment type mismatch:
      	pointer to struct _DisplayModeRec "=" pointer to const struct _DisplayModeRec
      
      "xf86Modes.c", line 701: warning: assignment type mismatch:
      	pointer to struct _DisplayModeRec "=" pointer to const struct _DisplayModeRec
      d5f9a131
  14. 22 Jul, 2008 1 commit
  15. 21 Jul, 2008 4 commits
  16. 06 May, 2008 1 commit
  17. 09 Apr, 2008 1 commit
  18. 03 Apr, 2008 1 commit
  19. 02 Apr, 2008 1 commit
  20. 27 Mar, 2008 1 commit
  21. 06 Mar, 2008 1 commit
  22. 03 Mar, 2008 1 commit
  23. 29 Feb, 2008 4 commits
  24. 28 Feb, 2008 2 commits
  25. 23 Jan, 2008 1 commit
  26. 28 Dec, 2007 2 commits
  27. 05 Dec, 2007 1 commit
  28. 30 Nov, 2007 1 commit
  29. 18 Oct, 2007 1 commit
  30. 11 Oct, 2007 1 commit
    • Eric Anholt's avatar
      Bug #10304,12784,11603: Add quirks for several physical size issues. · fc092334
      Eric Anholt authored
      A lot of EDID writers apparently end up stuffing centimeters (like the
      maximum image size field) into the detailed timings, instead of millimeters.
      Some of them only get it wrong in one direction.  Also, add a quirk to let
      us mark the largest 75hz mode as preferred, which will often be used for
      EDID 1.0 CRTs.
      fc092334
  31. 22 Aug, 2007 1 commit