1. 31 Oct, 2005 1 commit
    • Pozsar Balazs's avatar
      [PATCH] fix vgacon blanking · 1a66ddcb
      Pozsar Balazs authored
      
      
      This patch fixes a long-standing vgacon bug: characters with the bright bit
      set were left on the screen and not blacked out.  All I did was that I
      lookuped up some examples on the net about setting the vga palette, and
      added the call missing from the linux kernel, but included in all other
      ones.  It works for me.
      
      You can test this by writing something with the bright set to the
      console, for example:
        echo -e "\e[1;31mhello there\e[0m"
      and then wait for the console to blank itself (by default, after 10 mins
      of inactivity), maybe making it faster using
        setterm -blank 1
      so you only have to wait 1 minute.
      Signed-off-by: default avatarPozsar Balazs <pozsy@uhulinux.hu>
      Cc: James Simmons <jsimmons@infradead.org>
      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>
      1a66ddcb
  2. 17 Oct, 2005 1 commit
    • Samuel Thibault's avatar
      [PATCH] SVGATextMode fix · 0aec4867
      Samuel Thibault authored
      
      
      Fix bug 5441.
      
      I didn't know about messy programs like svgatextmode...  Couldn't this be
      integrated in some linux/drivers/video/console/svgacon.c ?...  So because
      of the existence of the svgatextmode program, the kernel is not supposed to
      touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
      
      Disabling the check in vgacon_resize() might help indeed, but I'm really
      not sure whether it will work for any chipset: in my patch, CRT registers
      are set at each console switch, since stty rows/cols apply to consoles
      separately...
      
      The attached solution is to keep the test, but if it fails, we assume that
      the caller knows what it does (i.e.  it is svgatextmode) and then disable
      any further call to vgacon_doresize.  Svgatextmode is usually used to
      _expand_ the display, not to shrink it.  And it is harmless in the case of
      a too big stty rows/cols: the display will just be cropped.  I tested it on
      my laptop, and it works fine with svgatextmode.
      
      A better solution would be that svgatextmode explicitely tells the kernel
      not to care about video timing, but for this an interface needs be defined
      and svgatextmode be patched.
      Signed-off-by: default avatarSamuel Thibault <samuel.thibault@ens-lyon.org>
      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>
      0aec4867
  3. 15 Sep, 2005 1 commit
    • Antonino A. Daplas's avatar
      [PATCH] vgacon: Fix sanity checking in vgacon_resize · 6d36ba62
      Antonino A. Daplas authored
      
      
      Reported by: walt <wa1ter@myrealbox.com>
      
      "I routinely switch the console font during bootup to
      8x8 so I can get 50 lines per screen.  Until 09 Sept,
      just changing to the small font automatically gave me
      all 50 lines -- but now I'm only getting 25 lines even
      with the small font.  The bottom half of the screen
      displays the text that already scrolled off the top."
      
      This bug is due to an erroneous check in the recently added hook,
      vgacon_resize(). It checks the new height against the original number of
      rows of the console. Because the original number of rows depends on both
      the scanline and the font height, check it instead against the
      scanline/fontheight.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      6d36ba62
  4. 09 Sep, 2005 1 commit
  5. 22 Jun, 2005 1 commit
    • James Simmons's avatar
      [PATCH] VGA to fbcon fix. · f18cd8f7
      James Simmons authored
      
      
      Currently when going from vgacon to fbcon the VT screenbuffer are often
      different sizes.  In the case when they are different sizes a new VT
      screenbuffer is allocated and the contents are copied into the new buffer.
      
      Currently the amount copied from VGA text memory to the new screenbuf is
      the size of the framebuffer console.  If the framebuffer console new VT
      screen buffer is greater than the VGA text memory size then we get some of
      the VGA BIOS contents as well.
      
      This patch will only allow you to copy up to the size of VGA text memory
      now.  The rest is filled with erase characters.
      
      Initial patch by Jordan Crouse <jordan.crouse@amd.com>
      Signed-off-by: default avatarJames Simmons <jsimmons@www.infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f18cd8f7
  6. 01 May, 2005 1 commit
    • Bill Nottingham's avatar
      [PATCH] vgacon: set vc_hi_font_mask correctly · a40920b4
      Bill Nottingham authored
      
      
      When allocating a new VC with vgacon_init(), the font is shared across all
      the VGA consoles.  However, the font mask was always set to the default
      value of zero in visual_init(), even if we were using 512 character fonts
      at the time.
      
      Moreover, code in vgacon.c:vga_do_font_op() didn't reset the mask if the
      console driver thinks it's already in 512 character mode.  This means that
      to *fix* it, you'd actually have to take the console out of 512 character
      mode and then set it back.
      
      The attached sets vc_hi_font_mask in vgacon_init() for any new consoles
      opened if the vgacon driver is already in 512 character mode, solving this.
      
      This bug goes back to 2.4.18 at least, probably earlier.
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a40920b4
  7. 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