Re: Extending vesafb for modes switching ?

["Antonino A. Daplas" <adaplas@hotpop.com>]

On Wed, 2004-02-04 at 01:54, James Simmons wrote:
> 
> > Ok, this may be a silly question. I am not a kernel/fbdev hacker, so I 
> > may ignore some relevant issues. But after many researches, I can't see 
> > why it would be impossible for the vesafb driver to handle modes switching.
> 
> The vesafb driver only supports VESA 2.0 standard so we can cover as many 
> cards as possible. My experience with vesa 3.0 is alot of cards lack 
> support for it.
>  
> > According to my understanding of this stuff, vesafb mode setting is 
> > possible only during real mode, via a boot argument,  set by bios 
> > interrupts, which prevent from changing it later (if I said something 
> > wrong, please correct me.) But what about the xfree86 driver ? It seems 
> > to do its job via the VBE bios of the card. What would prevent vesafb 
> > from doing the same ? I know vesafb only supports VBE 2.0, not 3.0. I 
> > couldn't find the VBE 2.0 documentation, but in VBE 3.0 one, protected 
> > mode is supported.
> 
> This has been discussed before. That would require writing code that would 
> execute the BIOS on the card. This would be really nasty and has always 
> been rejected.
> 

Not really.  The current vesafb driver already executes BIOS code
(pan_display and setcolreg).  

The difficulty lies in the code interface provided by the VIDEO BIOS. 
It will have 3:

a. int 10 - useful only in real mode, all functions supported

b. protected mode interface - code enters BIOS while in protected mode, 
CPU goes to 16-bit mode and back again to protected mode before
exiting.  In VBE 3.0, all functions have a protected mode interface.

c. simple 32-bit interface - Practically similar to b, but the CPU never
leaves protected mode. Only a few functions are supported (set color
registers, set start address, etc) even in VBE 3.0.  The most important
function (set video mode) does not have this interface.

While in kernel space, the CPU cannot go to 16-bit mode.  This is the
reason interface "a" and "b" cannot be used by vesafb. In user space, it
can go to real mode.  This means that only userspace apps (such as
XFree86) can take advantage of the functionality (and brokenness of
course) of the BIOS.

There are a few patches in the wild to extend the functionality of
vesafb, all of them need to go to userspace to execute code.  One as
pointed out by Jak, uses LRMI (Linux Real Mode Interface) which is a
user space library.

Tony





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn