1. 25 Apr, 2007 1 commit
  2. 24 Apr, 2007 8 commits
  3. 23 Apr, 2007 4 commits
  4. 22 Apr, 2007 1 commit
  5. 21 Apr, 2007 7 commits
  6. 20 Apr, 2007 6 commits
  7. 19 Apr, 2007 4 commits
  8. 18 Apr, 2007 4 commits
  9. 16 Apr, 2007 5 commits
    • Keith Packard's avatar
      Allow outputs to be explicitly enabled in config, overriding detect. · fc162c6c
      Keith Packard authored
      Option "Enable" "True" will force the server to enable an output at startup
      time, even if the output is not connected. This also causes the default
      modes to be added for this output, allowing even sync ranges to be used to
      pick out standard modes.
      (cherry picked from commit a3d73ba2)
      fc162c6c
    • Keith Packard's avatar
      Use default screen monitor for one of the outputs. · c41e3bd7
      Keith Packard authored
      By default, use the screen monitor section for output 0, however, a driver
      can change which output gets the screen monitor by calling
      xf86OutputUseScreenMonitor.
      (cherry picked from commit f4a8e54c)
      c41e3bd7
    • Keith Packard's avatar
      Using wrong log level in extension to built-in message · 97a2c257
      Keith Packard authored
      was: typo in built-in module log message
      (cherry picked from commit 00cfd1f7)
      97a2c257
    • Brian's avatar
      remove sources deleted in Mesa · deda7791
      Brian authored
      deda7791
    • Thomas Hellstrom's avatar
      Changes for single-entity multi-screen DRI. · 02d42f34
      Thomas Hellstrom authored
      The entity (device) has a locking SAREA and a master file descriptor
      that optionally isn't closed between server generation.
      
      The locking SAREA contains the device hardware lock.
      Each DRI screen creates an new SAREA containing the drawable lock,
      drawable-and private info, the drawable SAREA.
      
      The first screen optionally shares its drawable SAREA with the
      device SAREA.
      
      Default is to close the master descriptor between server generations,
      and to share the drawable SAREA of the first screen with the device locking
      SAREA. Thus we should (hopefully) have full backwards compatibility.
      
      Mesa changes to support single-device multiple screens are pending.
      02d42f34