From owner-freebsd-current@FreeBSD.ORG Mon Sep 15 17:15:37 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E72E106564A for ; Mon, 15 Sep 2008 17:15:37 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.179]) by mx1.freebsd.org (Postfix) with ESMTP id D961B8FC12 for ; Mon, 15 Sep 2008 17:15:36 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by el-out-1112.google.com with SMTP id v27so887478ele.13 for ; Mon, 15 Sep 2008 10:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=IpjIXPhy5VYrTZnhWlchnTYi3eEcTjJFBPlPQ7aaATA=; b=aRbR/S6VW175lhgf+PDfEaR5CadVo8RWcODyeF9IsSEqkax+5p7w+AeyCFFJhn9Fco F1Tef5JWb6mJoPi7ftRZPETEWivqA5wGb83Zo9cTPyUkZg34CBHnmdDbvkH2SePPSOJK TCcHWMSb7yr8VcTqsvspHtj7KWx4W6ktf21NI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BpdCTiyItaZkQpxmh3WYboBgbpWt5gYeDXHRpUcR+ur/uP5pBHA6wozhVb3IsftNV7 2j3BKG+w3Ips75jwY5Ia6HQ7brpyWm6GUpdaWqnKDHwgu61YNRr0tvrjdnjMJ3J/mSqc SkZirA6pvDGzAyUdoDocZTpFG9+lVMWO7uXIk= Received: by 10.103.179.17 with SMTP id g17mr1263689mup.31.1221498934577; Mon, 15 Sep 2008 10:15:34 -0700 (PDT) Received: by 10.103.231.14 with HTTP; Mon, 15 Sep 2008 10:15:34 -0700 (PDT) Message-ID: Date: Mon, 15 Sep 2008 14:15:34 -0300 From: "Carlos A. M. dos Santos" To: "Oliver Fromme" In-Reply-To: <200809150922.m8F9MaHg090579@haluter.fromme.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200809150922.m8F9MaHg090579@haluter.fromme.com> Cc: Xin LI , FreeBSD Current 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 17:15:37 -0000 On Mon, Sep 15, 2008 at 6: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/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