Re: Help with Aki Laukkanen's vesafbd project?

["Kendall Bennett" <KendallB@scitechsoft.com>]

Antonino Daplas <adaplas@pol.net> wrote:

> > > I'm more inclined to generalize this as a vm86 daemon.  What I'm
> > > thinking is to create a character device /dev/vm86.  
> > 
> > Right, that is actually not a bad idea, especially as a way for making 
> > vm86 services available to Linux kernel modules. However one of the 
> > offshoots of the vesafbd daemon is also the ability to handle full mode 
> > setting and blitting from the userland daemon without needing the vm86() 
> > BIOS support (ie: using XFree86 modules or allowing other vendor supplied 
> > modules to support this).
> 
> I think that's not a problem, except perhaps for efficiency.  For
> instance, if the kernel module sent a request for int 0x10 with AX
> = 0x4f02 (Set VBE mode), the user daemon can choose to either: 
> 
> a. parse the request so it is compatible with XFree86 or some non-VBE
> modules for video mode changing

Yes, that is true, provided everything that can be done has an interface 
via the regular VBE standard.

> Similarly for blits, we can use the VBE/AF standard.

Actually no, because the VBE/AF standard is a loadable driver module 
interface, and the only ratified standard of VBE/AF 1.0 was only an 
assembler interface. VBE/AF 2.0 which had a C calling interface is dead 
and was never ratified by VESA. Instead we took what was good about 
VBE/AF 2.0, killed what was bad and created SciTech Nucleus which has now 
morphed into what is SciTech SNAP today.

So if you wanted an acceleration interface in this daemon, it could not 
be done via a BIOS style interface since there is no standard for this.

> This should make the kernel->user interface as simple and as
> generic as possible, and we just let the user daemon do whatever it
> wants perhaps with some suggestions from the kernel (such as "use
> the BIOS exclusively" or "use the BIOS only as a last resort"). 

Being a daemon IMHO the suggestions would be better coming from the user 
when the daemon starts up ;-)

> > > This way, the interface can be useful for other subsystems (APM, IDE,
> > > etc).  Plus, the interface will be very simple (the request structure
> > > will just contain x86's register set, the bus, device, function number,
> > > and perhaps a few flags) and it need not know if this is graphics,
> > > block, power, etc.  
> > 
> > I like the idea, but the downside is that some people on the Linux kernel 
> > list feel that the availability of a generic BIOS interface would allow 
> > hardware vendors to be 'lazy' and rely on these services, making their 
> > code less portable to non-x86 platforms. Hence the generic vm86d project 
> > might be a bit of a hard sell for those folks ;-)
> 
> Hmm, I hope not.  Using the BIOS is just too inefficient.

Inefficient, but it would work. Personally I don't see it as a big issue, 
but that is what some folks said on the kernel lists.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~



-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en