vm86 in kernel [was: vesafb...]

[Kendall Bennett]

Alan Cox <alan en lxorguk.ukuu.org.uk> 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.

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/