Re: Why VESA and DPMS are available only for i386?

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.

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.

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.

Best regards
   Oliver

-- 
Oliver Fromme, Bunsenstr. 13, 81735 Muenchen, Germany

``We are all but compressed light'' (Albert Einstein)