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

    > On Mon, 24 Jan 2000, Kendall Bennett 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?
    > I'm not quite sure what is the level of acceleration you mean? Are
    > you talking about text acceleration for virtual consoles? Obviously
    > this would be restricted to bigger blits only because of the
    > overhead.

    Yes, I am talking about text framebuffer console acceleration and
    mode sets. Graphics mode consoles can benefit tremendously from
    hardware accelerated blitting (for scrolling) and hardware
    accelerated text rendering for drawing the fonts.

    > Currently there are atleast three sys calls per framebuffer
    > operation: a read(2) for the request, write(2) for reply and
    > synchronization and one or multiple vm86(2). Executing the real
    > mode code happens in a kind of mini-emulator if I understood the
    > LRMI code correctly. This I suppose is not a particularly light
    > operation.

    A call to vm86 simply goes into the kernel, and the code is then run
    at ring 3 in a vm86 task (ie: the code runs natively as real mode
    code, and is not emulated). The only complication is some I/O port
    writes cannot be unvirtualised, so we have to virtualise them in user
    land to go to the hardware directly. That code could also be done
    inside the kernel if there was a performance overhead for this, but
    our testing indicated this was not necessary (once I worked the bugs
    out of LRMI for Josh so that it actually worked properly, quite a
    while ago now ;-).

    > However this poses no problem with the type of operations (set mode
    > etc.) which the daemon currently implements. However I can drive
    > the vesafbd process upto 20 percent in top when pushing mouse
    > wildly around on a virtual screen in X (on P133).

    I am not thinking of this for X11 support; native XFree86 drivers
    should be used for that running in user land. I am thinking of
    framebuffer console support that can utilise XFree86 4.0 loadable
    modules to implement the mode set and blitting functions. Why re-
    write code when it could be re-used (even at the binary level!).

    > Acceleration for user-space application I think is best kept where
    > it is today.

    I totally agree.

    > Btw. I assume you are talking about supporting the VBE/AF
    > specification (which I don't have - seen only a passing mention in
    > the VBE 3.0 standard)?

    No, I was thinking of utilising XFree86 4.0 loadable chipset driver
    modules to implement the daemon.

    > Are there currently any cards which have a proper implementation of
    > those extensions?

    Nope. VBE/AF is dead.

    > I'm asking this for the possible multi-head support in vesafb too.
    > Are these documents (I'd be interested in DDC aswell) available
    > free from anywhere? I guess not or VESA wouldn't be asking $550 in
    > total for the both of them.

    Don't pay VESA a cent for the specs. I invented VBE/AF (both version
    1.0 which is a standard, and 2.0 which never passed), wrote the
    specifications, sample code and initial implementations. As much as
    we tried and tried, they would never release the VBE/AF
    specifications freely so that people could actually *use* it, but
    instead tried charging ridiculous fees for it. Hence VESA essentially
    destroyed VBE/AF, as they only sold less than 10 copies over a period
    of two years!

    Then they canned the VESA Software Standards Committee due to lack of
    interest. No wonder no-one was interested when no-one was using the
    damn specs!

    > Completely another point is whether supporting VBE 3.0 PMI should
    > be done in user-land or kernel-space? I haven't asked before but
    > what is every body's opinion in getting vesafb changes in the
    > distribution kernel if cleaned up/completed as planned (Alan)? In
    > this case would you accept calling PMI functions from kernel-space
    > or should it be done from user-space?

    Forget the VBE 3.0 PMI interface functions, at least for now.
    Unfortunately a number of well known graphics cards (NVIDIA boards
    from Diamond) shipped with a broken VBE 3.0 PMI interface. NVIDIA
    fixed their implementation ages ago, but Diamond refused to update
    their BIOS code and ship the fix, so using VBE 3.0 on any Diamond
    boards will likely result in a hard crash.

    Also the VBE 3.0 PMI interface is an optional part of the spec
    (something I fought hard to get changed, but the vendors wanted it
    optional), and hence most VBE 3.0 BIOS'es I have seen do not
    implement this interface at all.

    > Another issue which occurred to me was extending vesafbd to be
    > more a generic "support calling real-mode BIOS/whatever functions"
    > from kernel like facility. Would there be use for it elsewhere in
    > the kernel?

    I can't comment on this definitively, but off the top of my head I
    can't think of anything that would need real mode BIOS access except
    the graphics card support.

    > > Or better yet, have the system boot up initially in hardware text
    > > mode (assuming VGA text mode is available), and then switch into
    > > graphics mode when the user land deamon initialises? Then *all* the
    > When I've modularised the vesafb driver, this will be possible.
    > The current mode of operation is to set a graphics mode at boot
    > time before the kernel goes in protected mode. When the device file
    > is opened, the `dummy' functions in vesafb are simply replaced by
    > functions which can request vesafbd to do the job on behalf of
    > them.

    Right. So we could boot up in text mode and then change to a graphics
    mode console when the daemon loads (kinda like the SVGA text mode
    facilities are used to change resolutions etc after the system has

    > > BTW, if the developer of this code is interested, we have tons of
    > > source code showing how to properly program the VESA VBE BIOS that we
    > > have developed over the years (shipped in tons of commercial apps and
    > > games). I am more than willing to re-license code portions under GPL
    > > for kernel use if desired (since I wrote all the code I can do that
    > Of course I'd appreciate any information concerning VBE BIOS
    > programming. For example I'd imagine you had a database of buggy
    > bioses which would be extremely useful. DDC/AF and other code for
    > which programming information is unreachable could be useful for
    > fbdev in general (in case of DDC).

    I will email you copies of the code that you can use, under the GPL
    license. Feel free to cut and paste what stuff you need, but make
    sure you retain my copyright in your code somewhere.

    You should be able to use the DDC BIOS functions easily enough from
    user land to read the EDID from the monitor. Red Hat already does
    this (initially using code I sent them, which they re-wrote somewhat)
    in their latest 6.1 install program to determine the best refresh
    rate to use.


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