1. 02 8月, 2005 2 次提交
    • A
      [PATCH] tridentfb: Fix scrolling artifacts during disk IO · 8d894c47
      Antonino A. Daplas 提交于
      Reported by: Jochen Hein (Bugzilla Bug 4312)
      
      When there is disk I/O happening, the framebuffer has a little snow on
      the screen.  Once I/O has finished, no garbage remains on screen.
      
      This bug was explained by: Knut Petersen
      
      Most important is CRTC register 2f, signal quality is also improved for
      higher vclk values by changing set_vclk() according to the X drivers and
      cyblafb.c
      
      The fix is to set the performance register (0x2f) with a more stable
      value.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8d894c47
    • A
      [PATCH] tridentfb: Fix scrolling artifacts if acceleration is enabled · 8dad46cf
      Antonino A. Daplas 提交于
      Reported by: Jochen Hein (Bugzilla Bug 4386)
      
      booting leaves the end of long lines in the last line on screen when
      scrolling.  When X is running, scrolling puts garbage on the screen
      (looks like X data) Console switch fixes the screen.  Behaviour seems to
      be identical with noaccel and without on the video=tridentfb parameter
      in lilo.conf.
      
      This bug was explained by: Knut_Petersen
      
      Acceleration is broken for all BLADE 3D chips for all versions of kernel
      2.6 except for 32bit modes.  Most important reason is that the u32 col
      parameter of the graphics engine needs the color value replicated to all
      u8 of the u32 (8bit modes) and to both u16 of the u32.
      
      Fix color value passed to graphics engine, verified by the reporter.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8dad46cf
  2. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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