Date: Mon, 15 Sep 2008 14:15:34 -0300 From: "Carlos A. M. dos Santos" <unixmania@gmail.com> To: "Oliver Fromme" <olli@fromme.com> Cc: Xin LI <delphij@delphij.net>, FreeBSD Current <current@freebsd.org> Subject: Re: Why VESA and DPMS are available only for i386? Message-ID: <e71790db0809151015g9b91cfeodddac069d0ebdf2a@mail.gmail.com> In-Reply-To: <200809150922.m8F9MaHg090579@haluter.fromme.com> References: <e71790db0809142159q54ed6f03u710a86b199e3f064@mail.gmail.com> <200809150922.m8F9MaHg090579@haluter.fromme.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 15, 2008 at 6:22 AM, Oliver Fromme <olli@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e71790db0809151015g9b91cfeodddac069d0ebdf2a>