1. 25 7月, 2008 21 次提交
  2. 13 5月, 2008 2 次提交
  3. 28 4月, 2008 2 次提交
  4. 11 3月, 2008 2 次提交
  5. 05 3月, 2008 1 次提交
  6. 17 10月, 2007 1 次提交
  7. 18 7月, 2007 1 次提交
  8. 09 12月, 2006 1 次提交
  9. 01 7月, 2006 1 次提交
  10. 26 6月, 2006 1 次提交
    • R
      [PATCH] trident fb section fixes · 474ab45a
      Randy Dunlap 提交于
      Priority: not critical.
      Change 3 functions from __init to __devinit.
      Could be an init/probe problem in theory, but not observed, so not
      high priority IMO.
      
      Fix section mismatch warnings:
      WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1aad) and 'trident_pci_remove'
      WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1b22) and 'trident_pci_remove'
      WARNING: drivers/video/tridentfb.o - Section mismatch: reference to .init.text: from .text between 'trident_pci_probe' (at offset 0x1b31) and 'trident_pci_remove'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Cc: "Antonino A. Daplas" <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      474ab45a
  11. 07 11月, 2005 1 次提交
    • A
      [PATCH] fbcon/fbdev: Move softcursor out of fbdev to fbcon · c465e05a
      Antonino A. Daplas 提交于
      According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
      drivers that do not support hardware cursors is redundant.  The soft_cursor
      function is usable by all drivers because it is just a wrapper around
      fb_imageblit.  And because soft_cursor is an fbcon-specific hook, the file is
      moved to the console directory.
      
      Thus, drivers that do not support hardware cursors can leave the fb_cursor
      field blank.  For drivers that do, they can fill up this field with their own
      version.
      
      The end result is a smaller code size.  And if the framebuffer console is not
      loaded, module/kernel size is also reduced because the soft_cursor module will
      also not be loaded.
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c465e05a
  12. 10 9月, 2005 1 次提交
    • K
      [PATCH] framebuffer: new driver for cyberblade/i1 graphics core · 9fa68eae
      Knut Petersen 提交于
      This is a framebuffer driver for the Cyberblade/i1 graphics core.
      
      Currently tridenfb claims to support the cyberblade/i1 graphics core.  This
      is of very limited truth.  Even vesafb is faster and provides more working
      modes and a much better quality of the video signal.  There is a great
      number of bugs in tridentfb ...  but most often it is impossible to decide
      if these bugs are real bugs or if fixing them for the cyberblade/i1 core
      would break support for one of the other supported chips.
      
      Tridentfb seems to be unmaintained,and documentation for most of the
      supported chips is not available.  So "fixing" cyberblade/i1 support inside
      of tridentfb was not an option, it would have caused numerous
      if(CYBERBLADEi1) else ...  cases and would have rendered the code to be
      almost unmaintainable.
      
      A first version of this driver was published on 2005-07-31.  A fix for a
      bug reported by Jochen Hein was integrated as well as some changes
      requested by Antonino A.  Daplas.
      
      A message has been added to tridentfb to inform current users of tridentfb
      to switch to cyblafb if the cyberblade/i1 graphics core is detected.
      
      This patch is one logical change, but because of the included documentation
      it is bigger than 70kb.  Therefore it is not sent to lkml and
      linux-fbdev-devel,
      Signed-off-by: NKnut Petersen <Knut_Petersen@t-online.de>
      Cc: Muli Ben-Yehuda <mulix@mulix.org>
      Acked-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9fa68eae
  13. 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
  14. 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