From owner-freebsd-current@FreeBSD.ORG Tue Sep 16 01:40:17 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 D01521065672; Tue, 16 Sep 2008 01:40:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: "Carlos A. M. dos Santos" Date: Mon, 15 Sep 2008 21:39:57 -0400 User-Agent: KMail/1.6.2 References: <200809150922.m8F9MaHg090579@haluter.fromme.com> <200809151439.44049.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: <200809152139.58765.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: Tue, 16 Sep 2008 01:40:17 -0000 On Monday 15 September 2008 09:05 pm, Carlos A. M. dos Santos wrote: > On Mon, Sep 15, 2008 at 3:39 PM, Jung-uk Kim 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 > > > > 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. No, I am not saying we can reuse any of these. I was merely saying we could do something similar, conceptually. :-) Jung-uk Kim