1. 27 Aug, 2006 1 commit
  2. 21 May, 2006 1 commit
    • Paul A. Clarke's avatar
      [PATCH] matroxfb: fix DVI setup to be more compatible · 6d39bedc
      Paul A. Clarke authored
      There has been a longstanding problem with the Matrox G450 and perhaps
      other similar cards, with modes "above" 1280x1024-60 on ppc/ppc64 boxes
      running Linux.  Higher resolutions and/or higher refresh rates resulted in
      a very noticably "jittery" display, and sometimes no display, depending on
      the physical monitor.  This patch fixes that problem on the systems I have
      easy access to...
      
      I've tested with SLES9SP3 (2.6.5+ kernel) and 2.6.16-rc6 custom kernels on
      an IBM eServer p5 520 w/G450 (a.k.a GXT135P on IBM's ppc64 systems), and a
      colleague of mine (Ian Romanick) tested it successfully on an Apple ppc32
      box (w/GXT135P).  I also tested it on IA32 box I have with a GXT135P to
      verify that it didn't obviously break anything.  In my testing, I covered
      single-card, single and dual-head setups using both HD15 and DVI-D signals,
      on both the IA32 and ppc64 boxes.  While everything appeared fine on both
      boxes, I did encounter one problem: I can't get any signal on the DVI-D
      output on the ppc64 box.  However, this is also the case without my patch.
      
      I just noticed that screen-blanking only occurs on the primary display as
      well.
      Signed-off-by: default avatarPaul A. Clarke <pc@us.ibm.com>
      Signed-off-by: default avatarIan Romanick <idr@us.ibm.com>
      Signed-off-by: default avatarPetr Vandrovec <petr@vandrovec.name>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6d39bedc
  3. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4