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
>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
From: James Simmons <hidden> Date: 2004-02-04 12:22:58
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
From: Antonino A. Daplas <hidden> Date: 2004-02-05 00:18:15
On Wed, 2004-02-04 at 01:54, James Simmons wrote:
quoted
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.
quoted
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