[lkml]   [2000]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: vm86 in kernel [was: vesafb...]
    Alan Cox <> wrote:

    > > So now that this has been brought up, why can't a user land daemon
    > > type thing be used to implement accelerated fbdev type functionality?
    > For a limited subset it probably can. Except that the vesa
    > acceleration I've seen is pretty piss poor.

    I wasn't talking about VESA acceleration, but having the a user land
    binary that can do everything for fbdev, including mode sets, palette
    programming, acceleration (for text modes, scrolling etc) and
    anything else fbdev does. This would not be implementing using VESA
    services, but instead be implemented via user land daemon chipset
    drivers that go native to the hardware.

    The obvious question is 'why', when you can already do chipset
    specific drivers in the kernel. The answer to that is twofold:

    1. You can more easily replace the drivers or update them without
    having to modify your kernel at all (and it is more protected
    since the fbdev driver can't cause a kernel oops).

    2. The source for the drivers does not need to be under GPL.

    The second issue is very important, because with XFree86 4.0's new
    modular chipset driver architecture, it may well be possible to build
    this user land daemon such that it can use standard XFree86 4.0
    chipset driver. It is simply not possible to do this in the kernel,
    because XFree86's license is not GPL compatible (and never will be).

    This would provide a mechanism to completely avoid duplication of
    work, and more importantly the XFree86 drivers would not have to
    fight with the framebuffer console drivers since there would really
    only be one driver running the graphics card in the system (ie:
    save/restore state becomes a *lot* easier).

    > For consoles Vesa 1.2 is also a problem due to the banking and the
    > fact we may want to change bank during an IRQ. A vesa 1.2 bios X
    > server would be a great hack, but probably not terribly productive.

    Sure, but I wasn't thinking of a VESA fbdev driver, but a fully
    accelerated chipset specific driver.

    > > description to get the card into graphics mode (or even the BIOS
    > > could be used for that), and all the complex stuff (acceleration etc)
    > > can be handled by the user land daemon.
    > I'm under the impression Egbert Eich is doing exactly this for
    > XFree 4.0 to bios initialise some cards.

    Yes, both Egbert and I have been working on this for some time. The
    stuff that Egbert has done was based on code I did, but he re-
    implemented it because our license (MPL) was not comaptible with the
    XFree86 license. We are also both working on the x86emu library
    (which I re-vamped and brought back to life!) so that the BIOS can be
    used to initialise secondary controllers as well as supporting int10
    functions on non x86 CPU platforms.

    Most of the work I do is all generic and OS neutral, and Egbert works
    on the XFree86/Linux integration.


    | SciTech Software - Building Truly Plug'n'Play Software! |
    | Kendall Bennett | Email: |
    | Director of Engineering | Phone: (530) 894 8400 |
    | SciTech Software, Inc. | Fax : (530) 894 9069 |
    | 505 Wall Street | ftp : |
    | Chico, CA 95928, USA | www : |

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:56    [W:0.022 / U:83.576 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site