From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 16:51:30 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D39D1065672 for ; Mon, 15 Sep 2008 16:51:30 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id A60508FC1E for ; Mon, 15 Sep 2008 16:51:29 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id m8FGWiU2047738; Mon, 15 Sep 2008 12:32:44 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 15 Sep 2008 12:32:34 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> In-Reply-To: <200809150922.m8F9MaHg090579@haluter.fromme.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809151232.36756.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.92/8248/Mon Sep 15 11:28:54 2008 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: "Carlos A. M. dos Santos" , Xin LI , Oliver Fromme Subject: Re: Why VESA and DPMS are available only for i386? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2008 16:51:30 -0000 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