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

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

Jung-uk Kim

> 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