Extending vesafb for modes switching ?

Extending vesafb for modes switching ?

[Gaël Deest]

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.

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.

I would see this as a great improvement, because of the really little 
number of cards actually supported by vesafb.

Regards,

Gaël D.


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

Re: Extending vesafb for modes switching ?

[Gaël Deest]

 >supported by vesafb.

By fbdev of course.
Sorry.


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

Re: Extending vesafb for modes switching ?

[James Simmons]

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





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

Re: Extending vesafb for modes switching ?

[Antonino A. Daplas]

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

Re: Extending vesafb for modes switching ?

[Jak]

There already seems to be such a patch : I have not tried it, but have come 
across it. The following is extracted from the README

 DRIVER FRAMEBUFFER FOR VESA GRAPHIC CARDS
                                Version 1.0
                       (C) 2003 Raster Software Vigo


This piece of code wants to be a Framebuffer driver for Linux boxes, able to
work with all VESA 2.0-compliant graphic card. The difference between this
driver and the one supplied with the kernel is that this driver allows to
change in-the-fly the resolution and color depth, and even to have each
console in a different graphic mode.

This driver is for the 2.4.x kernel series.


DISCLAIMER

This driver is distributed "as is", without warranty of any kind, under the
terms of the GPL license, version 2 or later. You can find it in the file
COPYING.
CONTACTING WITH THE AUTHOR

Sergio Costas Rodriguez
mailto:raster@rastersoft.com
http://www.rastersoft.com


OTHER SOFTWARE PACKAGES USED IN THIS PROJECT:

LRMI library
http://sourceforge.net/projects/lrmi




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