Why VESA and DPMS are available only for i386?

[Jung-uk Kim]

On Monday 15 September 2008 01:24 pm, Carlos A. M. dos Santos wrote:
> On Mon, Sep 15, 2008 at 1:32 PM, Jung-uk Kim <jkim at freebsd.org> 
wrote:
> > On Monday 15 September 2008 05:22 am, Oliver Fromme 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/00
> >>637 6.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.
> >
> > doscmd(1) had a rudimentary 16-bit CPU emulation:
> >
> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/
> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/doscmd/cpu.c
>
> No change in the last 4 years. Is there anybody responsible for it
> these days?

doscmd(1) was removed from base and moved to ports:

http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/doscmd/

Don't get me wrong, BTW.  It does not work on amd64.  I just brought 
it up because we *may* be able to do a hybrid approach as Linux 
DOSEMU does:

http://en.wikipedia.org/wiki/DOSEMU

"Virtual 8086 mode is not available in x86-64 long mode, so DOSEMU 
includes an 8086 processor emulator for use with 16-bit 
applications."

Also, Linux people actually developed vm86 calls for amd64:

http://v86-64.sourceforge.net/

Jung-uk Kim