25 Jul, 2008

1 commit

  • mdacon incorrectly detects MDA hardware on systems without such graphics card.

    One may load this module by chance, for example when doing some systematical
    module-testing, and if there is no Monochrome Display Adapter attached ,
    module init renders vc1-16 completely unusable.

    I and others have run into this more than once. see [Bug 224522 - modprobe
    mdacon freezes machine -> https://bugzilla.novell.com/show_bug.cgi?id=224522 ]
    for example

    Apparently proper MDA detection seems to be broken for a long time - seems to
    be related to those #ifdef TEST_MDA_B statements added by Edward Betts.

    this commit back in 2002 made things even worse :
    http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=c72757b49c88914433244757fb4967fc63546685

    It changed default vc allocation from 13-16 to 1-16 for no apparent reason
    (!?) , and with that (and without X), mdacon grabs the vc you`re currently
    sitting on and locks you out.

    this is from Kconfig :
    >config MDA_CONSOLE
    > depends on !M68K && !PARISC && ISA
    > tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
    > ---help---
    > Say Y here if you have an old MDA or monochrome Hercules graphics
    > adapter in your system acting as a second head ( = video card). You
    > will then be able to use two monitors with your Linux system. Do not
    > say Y here if your MDA card is the primary card in your system; the
    > normal VGA driver will handle it.

    As we can see mdacon is just meant as an additional driver for dual-head
    setup, and since kernel 2.4.36 still defaults to vc13-16 , setting the default
    back to that value again shouldn`t do any harm.

    Hereby i'm reverting that change, setting default back to to vc13-16 again.

    Besides the fact that mdacon may be rarely or never be used these days and
    could perhaps put to trash anyway (pre-dinosaur hardware!), indeed this is not
    a real solution, but at least it removes the unfortunate side-effect of
    messing up the vc you`re working on.

    Signed-off-by: Roland Kletzing
    Cc: James Simmons
    Cc: "Antonino A. Daplas"
    Cc: Tim Schmielau
    Cc: Jan Engelhardt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Roland Kletzing
     

29 Apr, 2008

1 commit

  • A command that causes a line feed while a background color is active,
    such as

    perl -e 'print "x" x 60, "\e[44m", "x" x 40, "\e[0m\n"'
    and
    perl -e 'print "x" x 40, "\e[44m\n", "x" x 40, "\e[0m\n"'

    causes the line that was started as a result of the line feed to be completely
    filled with the currently active background color instead of the default
    color.

    When scrolling, part of the current screen is memcpy'd/memmove'd to the new
    region, and the new line(s) that will appear as a result are cleared using
    memset. However, the lines are cleared with vc->vc_video_erase_char, causing
    them to be colored with the currently active background color. This is
    different from X11 terminal emulators which always paint the new lines with
    the default background color (e.g. `xterm -bg black`).

    The clear operation (\e[1J and \e[2J) also use vc_video_erase_char, so a new
    vc->vc_scrl_erase_char is introduced with contains the erase character used
    for scrolling, which is built from vc->vc_def_color instead of vc->vc_color.

    Signed-off-by: Jan Engelhardt
    Cc: "Antonino A. Daplas"
    Cc: "H. Peter Anvin"
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Engelhardt
     

09 May, 2007

1 commit


15 Feb, 2007

1 commit

  • After Al Viro (finally) succeeded in removing the sched.h #include in module.h
    recently, it makes sense again to remove other superfluous sched.h includes.
    There are quite a lot of files which include it but don't actually need
    anything defined in there. Presumably these includes were once needed for
    macros that used to live in sched.h, but moved to other header files in the
    course of cleaning it up.

    To ease the pain, this time I did not fiddle with any header files and only
    removed #includes from .c-files, which tend to cause less trouble.

    Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
    arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
    allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
    configs in arch/arm/configs on arm. I also checked that no new warnings were
    introduced by the patch (actually, some warnings are removed that were emitted
    by unnecessarily included header files).

    Signed-off-by: Tim Schmielau
    Acked-by: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

01 Aug, 2006

1 commit

  • WARNING: drivers/video/console/mdacon.o - Section mismatch: reference to .init.text: from .text between 'mdacon_startup' (at offset 0x123) and 'mdacon_init'
    WARNING: drivers/video/console/mdacon.o - Section mismatch: reference to .init.text: from .text between 'mdacon_startup' (at offset 0x18b) and 'mdacon_init'

    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederik Deweerdt
     

11 Jul, 2006

1 commit

  • MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
    function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
    allows all of the framebuffer and VT console drivers to remove their
    dependency on tty.h.

    [akpm@osdl.org: fix alpha build]
    Signed-off-by: Jon Smirl
    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jon Smirl
     

27 Jun, 2006

1 commit


23 Jun, 2006

1 commit

  • VGA_MAP_MEM translates to ioremap() on some architectures. It makes sense
    to do this to vga_vram_base, because we're going to access memory between
    vga_vram_base and vga_vram_end.

    But it doesn't really make sense to map starting at vga_vram_end, because
    we aren't going to access memory starting there. On ia64, which always has
    to be different, ioremapping vga_vram_end gives you something completely
    incompatible with ioremapped vga_vram_start, so vga_vram_size ends up being
    nonsense.

    As a bonus, we often know the size up front, so we can use ioremap()
    correctly, rather than giving it a zero size.

    Signed-off-by: Bjorn Helgaas
    Cc: "Antonino A. Daplas"
    Cc: "Luck, Tony"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Bjorn Helgaas
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds