[lkml]   [2000]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[ANNOUNCE] vesafb full VBE 2.0 support
    Patch to vesafb adds support for communicating with a user-space
    daemon. This user-space daemon uses the LRMI library by Josh Vanderhoof
    (need his e-mail) to call real-mode VBE 2.0 functions to set the mode,
    pan the display and perform other framebuffer functions. Thanks to
    Alan Cox for the idea and mailing the LRMI library.

    This is a very preliminary version and released because it works for
    me. Your mileage may vary. The communication between kernel/user-space is
    achieved via a special character device file (/dev/vesafb).

    ~$ file /dev/vesafb
    /dev/vesafb: character special (10/180)

    When vesafbd successfully opens the vesafb device, the `dummy' functions
    in the vesafb driver are overrided with the ones capable of communicating
    with the daemon. Issued FB ioctls are then added to a request/reply
    queue which is processed by the device read/write functions. A queue is
    needed because console switching is done from an interrupt context.

    In practice this seems to work quite well. Even panning (for example in
    X) is completely smooth on my Pentium/133. By default the patch writes a
    lot of debug info but this may be omitted by commenting out the DEBUG
    define in the code. The patch itself is against 2.3.x (I doubt there has
    been any changes during that time) but needs only small changes to work
    with 2.2.x.

    Download from:

    I've also setting up a web page at:


    * VBE 2.0/3.0 PMI support
    * modularisation
    * palette modes: can not change palette right now
    * wrap daemon support in CONFIG_VESAFB_VESAFBD for those who need it?
    * generic clean up
    * mix of text and vesafb virtual consoles might work with the SAVESTATE/
    RESTORESTATE VBE functions.
    * documentation

    * SVGAlib support
    * XFree 4 modularized driver support
    * might need changes in the /dev/vesafb interface because of above
    * rename appropriate?
    * clean up code and automake/configure stuff
    * black-list non-working BIOSes (PMI/3.0 and/or PMI/2.0 does not work,
    real mode interface does not work - more fine grained?)
    * derive the acceleration fields from the information which VBE provides
    * Red Hat/Debian initscript support and packages.
    * documentation


    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.027 / U:7.260 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site