vm86 in kernel [was: vesafb...]

[Kendall Bennett]

Aki M Laukkanen <amlaukka en cc.helsinki.fi> 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 
booted).

> > 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.

Regards,

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


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