Why VESA and DPMS are available only for i386?

[Carlos A. M. dos Santos]

On Mon, Sep 15, 2008 at 6:22 AM, Oliver Fromme <olli at fromme.com> wrote:
>
> Carlos A. M. dos Santos wrote:
>  > Xin LI wrote:
>  > > Carlos A. M. dos Santos wrote:
>  > > > Several PRs were closed based on the argument that FreeBSD/amd64
>  > > > cannot call to the VESA BIOS. XFree86 solved this problem by means of
>  > > > the INT10 module. I believe that it would be possible to do the same
>  > > > on the FreeBSD kernel.
>  > > >
>  > > > Is there any ongoing effort to enable the VESA kernel moule on
>  > > > non-i386 platform? Is there any particular difficulty for doing this,
>  > > > besides depending on VM86?
>  > >
>  > > According to VESA's VBE 3.0 standard, there is a "Protected Mode Entry
>  > > Point" [optionally] provided by BIOS, which OS or application is
>  > > supposed to copy to a place where it is writable.  The code there would
>  > > be written in 16-bit protected mode.  Therefore I think it's do-able...
>  > >
>  > > http://www.vesa.org/public/VBE/vbe3.pdf
>  >
>  > I'm reading the specification and digging at the code of the X server
>  > and the X VESA driver. Look promising.
>
> Don't hold your breath.  Peter explained that this is more
> involved than it seems at first glance:
>
> http://lists.freebsd.org/pipermail/freebsd-amd64/2005-October/006376.html
>
> Here's a quote:
>
>  |  [FreeBSD's VESA code] is trying to use bios calls to change the
>  |  modes.  This is something a 64 bit kernel cannot do.  To make
>  |  this work, one would have to trampoline out of 64 bit mode and
>  |  into 32 bit mode, then do the vm86 or bios32() calls.  This is
>  |  more work than it might appear at first because you have to deal
>  |  with interrupts.  One would have to write a 32 bit mini-kernel
>  |  that can accept interrupts and traps, trampoline to 64 bit mode,
>  |  handle them, then return, switching back to 32 bit mode.  All
>  |  with page tables etc.  And of course you have to do extra data
>  |  copying and have a way to describe it to the API.
>
> By the way, It doesn't matter whether you use the VESA
> BIOS' real-mode functions or the protected-mode functions
> (which exist since VBE 2.0, not only 3.0).  From the view
> of an amd64 kernel it doesn't make a difference.

Yeah, I came to the same conclusion when I saw, in pg. 24 of VBE 3.0
spac, that "protected mode entry point will put the CPU in 16-bit
protected mode". Using this would require two trampolines (64->32 and
32-16) but the second one jumps out of the pool. :-(

> Another way would be to write a 32bit x86 instruction
> emulator (similar to what programs like qemu or bochs do),
> so you can execute the VESA functions within an emulated
> virtual machine that programs the VGA hardware registers.
> This isn't exactly trivial either.  Note that there are
> already such emulators, but I'm not aware of a BSD-licensed
> one that could be included in the FreeBSD kernel without
> problems.

This is done by the X server, by means of libint10. The x86 emulator
is x86emu, which was donated by SciTech Software, Inc. and is
available under a BSD-friendly license. This is what I had in mind
when I sent the first message.

> There's a third way, and I think this is the easiest one.
> This is what the Linux VESA framebuffer driver does.
> Let the boot loader (which executes in 32bit mode) switch
> to the desired video mode, enable a linear frame buffer
> (which is supported since VBE 2.0) and pass the address
> of the frame buffer to the 64bit kernel.  Then the kernel
> would not need to call any VESA functions at all, thus
> eliminating all of the above problems.  The drawback is
> that you can't change the console video mode anymore once
> the kernel is booted, i.e. you have to reboot if you want
> a different mode.

This can also lead to a situation where the kernel can not restore the
video controller to a known mode if the X server crashes or when the
user attempts to switch from X to the "text mode" console. For
instance, Linux has this problem when using the nVIDIA binary driver.

-- 
cd /usr/ports/sysutils/life
make clean