lkml.org 
[lkml]   [2003]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: VESA FBconsole driver?
    Helge Hafting <helgehaf@aitel.hist.no> wrote:

    > > Why is it ugly? IMHO it is very much needed, as it would provide a
    > > mechanism for the kernel to be able to properly restore the screen
    > > if a user land program goes astray.
    >
    > First - the bios isn't always able to fix the screen - the program may
    > have programmed the video hardware in odd ways the bios don't know
    > about. Bioses aren't a magic fix.

    Exactly what facts do you base the above statement on? Have you seen this
    in practice?

    I can tell you from my own personal experience that the BIOS on the
    graphics card can nearly always restore the screen no matter what state
    you have put the graphics hardware into. I have done development in DOS
    for years writing the UniVBE and SciTech Display Doctor products, and we
    have always used the BIOS to restore the screen when one of our graphics
    drivers crashed during development.

    > Second, the proper way to do this is for the video driver to fix
    > it up, using more efficient code that runs under linux without
    > special consideration because it was written for that case.

    Great, assuming you *have* a video driver for the card in question! There
    are lots of cards that can run on the VESA fbconsole driver that uses a
    mode set by the real mode boot loader and can never be changed once the
    system is up and running. For those particular devices using the BIOS is
    the *perfect* solution IMHO (if the driver was so easy to write it would
    already exist).

    > > More tricks like what? All we need is the ability to call the BIOS and
    > > have it execute the necessary real mode code, just like we do on ia32
    > > machines in user land.
    >
    > Ability to call the bios in real mode is no simple feat. And the
    > bios may screw up. That doesn't matter for a user program, it just
    > crashes and don't damage anything else. You don't want the kernel
    > to crash - ever. A broken bios is _no_ excuse here.

    We are talking about using the BIOS to do the most basic and simple thing
    that it does - set a display mode. Sure BIOS'es are buggy, but even the
    crappiest BIOS on the planet can properly set the display mode without
    crashing! They have to, or their Windows 9x drivers would never have
    worked.

    Anyway this is a moot point because I do believe that if we implement the
    VESAFBD style daemon that Aki was working on we can avoid the need for
    the vm86() calls to be made from the kernel anyway, and have them run in
    the protected space of a userland daemon. Then if the BIOS does crash
    (unlikely IMHO), it won't crash the kernel.

    > Bioses are generally too limited. They make a lot of stupid
    > assumptions, thinking it is ok to use legacy vga registers and
    > things like that. Consider a machine with two or more video cards.
    > Linux handles that fine, but a bios? Or really two bioses, one for
    > each card?

    What about it? How do you think Linux brings up the secondary graphics
    card for dual head operations? It uses the *BIOS*! I know that because I
    resurrected the x86emu project that is used to warmboot the secondary
    graphics cards. You can in fact do it on x86 Linux without needing the
    BIOS emulator at all, just using the vm86() services and some nify copy
    on write features of the Linux kenerl. As far as legacy I/O port access
    goes, the BIOS will nearly always do that, but if you only run the BIOS
    on one card at a time, this is no problem. The PCI spec allows you to
    selectively enable and disable the I/O port access on any graphics card
    on the bus as you see fit. So you simply disable the primary card, enable
    the secondary card and let the BIOS have at it.

    This does work, because it is how secondary controllers are done on Linux
    today.

    > Imagine a dual processor where one one processor executes one bios
    > and the other processor another bios , each trying to set up one
    > card. Somehow I think this won't work too well.

    No, it wouldn't and you would need to ensure mutually exclusive access to
    the graphics cards. Simple problem really and since XFree86 is not
    threaded is not a problem in the existing code anyway, but if it is that
    is pretty a simple multu-processor programming problem.

    > As for userspace tricks - userspace can do all sorts of nifty
    > things like actually open a file and read it. For example a file
    > with the latest list of bios oddities to work around.

    Definately. I have no argument there.

    Regards,

    ---
    Kendall Bennett
    Chief Executive Officer
    SciTech Software, Inc.
    Phone: (530) 894 8400
    http://www.scitechsoft.com

    ~ SciTech SNAP - The future of device driver technology! ~

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:33    [W:0.028 / U:63.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site