From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 18:40:07 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id CE8A1106567B; Mon, 15 Sep 2008 18:40:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Carlos A. M. dos Santos" Date: Mon, 15 Sep 2008 14:39:42 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151232.36756.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200809151439.44049.jkim@FreeBSD.org> Cc: Xin LI , freebsd-current@freebsd.org, 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 18:40:07 -0000 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 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