Why VESA and DPMS are available only for i386?
Carlos A. M. dos Santos
unixmania at gmail.com
Tue Sep 16 01:05:46 UTC 2008
On Mon, Sep 15, 2008 at 3:39 PM, Jung-uk Kim <jkim at freebsd.org> wrote:
> 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 [...]
Depends on vm86 too.
> [...] 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."
Wrong license.
> Also, Linux people actually developed vm86 calls for amd64:
>
> http://v86-64.sourceforge.net/
It is a Linux kernel patch, doubtfully applicable to FreeBSD without a
lot of hassle. I'm also concerned about the license terms.
> Jung-uk Kim
>
--
cd /usr/ports/sysutils/life
make clean
More information about the freebsd-current
mailing list