#include <hallo.h> * Raul Miller [Wed, Oct 23 2002, 05:59:42PM]: > > That would be a good start. > > Ok. Next question: who poses the questions? [I'll do it if no one > else does: sometime tomorrow. If you prefer your own style of asking Wait, I found the answer from Gerd from our last conversation! See attachment. As stated, nothing will break if vesafb is just available in the kernel. If a user enables it, sHe should know whether the video card supports it (most do). In contrary, when the user switches from existing, vesafb-enabled configuration to a Xu's kernel, he only gets a _black screen_. No warnings, no hints. Gruss/Regards, Eduard. -- Failure is not an option. It comes bundled with your Microsoft product.
From kraxel@debian.org Wed Jan 09 18:43:40 2002 Return-path: <kraxel@debian.org> Envelope-to: inet@zombie Received: from localhost ([127.0.0.1]) by zombie with esmtp (Exim 3.33 #1 (Debian)) id 16OMlH-00012K-03 for <inet@zombie>; Wed, 09 Jan 2002 18:43:40 +0100 Received: from localhost [127.0.0.1] by localhost with POP3 (fetchmail-5.9.6) for inet@zombie (single-drop); Wed, 09 Jan 2002 18:43:39 +0100 (CET) Received: from master.debian.org (master.debian.org [216.234.231.5]) by mail.inka.de with esmtp id 16OMhp-00072K-00; Wed, 9 Jan 2002 18:40:05 +0100 Received: from gnu.in-berlin.de [192.109.42.4] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 16OMho-000422-00; Wed, 09 Jan 2002 11:40:04 -0600 Received: from hirsch.in-berlin.de (root@hirsch.plusline.in-berlin.de [213.83.10.6]) by gnu.in-berlin.de (8.12.1/8.12.1) with ESMTP id g09He27e001826 for <blade@debian.org>; Wed, 9 Jan 2002 18:40:02 +0100 (CET) (envelope-from kraxel@bytesex.org) X-Envelope-From: kraxel@bytesex.org X-Envelope-To: <blade@debian.org> Received: from hirsch.in-berlin.de (uucp@localhost [127.0.0.1]) by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with ESMTP id g09He2PP019835 for <blade@debian.org>; Wed, 9 Jan 2002 18:40:02 +0100 Received: (from uucp@localhost) by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with UUCP id g09He2IN019833 for blade@debian.org; Wed, 9 Jan 2002 18:40:02 +0100 Received: from bytesex.masq.in-berlin.de (localhost [127.0.0.1]) by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id g09GT8bK009936 for <blade@debian.org>; Wed, 9 Jan 2002 17:29:08 +0100 Received: (from kraxel@localhost) by bytesex.masq.in-berlin.de (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id g09GT8mE009935 for blade@debian.org; Wed, 9 Jan 2002 17:29:08 +0100 Date: Wed, 9 Jan 2002 17:29:08 +0100 From: Gerd Knorr <kraxel@debian.org> To: Eduard Bloch <blade@debian.org> Subject: Re: VESA fb in Debian - please give a hint Message-ID: <20020109172908.B9884@bytesex.org> References: <20020108191726.GA9694@zombie.inka.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020108191726.GA9694@zombie.inka.de> User-Agent: Mutt/1.3.20i Status: RO Content-Length: 992 Lines: 28 > Please answer to these question and allow to Cc' your answer to the BTS: > > - is the VESA framebuffer dangerous in any way if it is builtin in the > all-people kernel? No. It's not used by default, just saying 'Y' to vesafb doesn't activate it at boot time. fbcon+vesafb comes into play if you pass a vesa graphics mode as vga=xx argument to the kernel. > - is there is a simple way to make it modularize the driver? No. vesafb depends on the VGA BIOS activating the graphics mode (which is done in real mode startup code). Thus it works on nearly all graphics cards on earth, but it also has a few drawbacks: Limited to flickering 60Hz standard vesa modes, no mode switching at runtime, it's very slow, ... > If no, is a replacement in development? No. Some people tried to play tricks (use vm86 to call the BIOS) to overcome the limitation mentioned above, but that isn't trivial. Gerd -- #define ENOCLUE 125 /* userland programmer induced race condition */
Attachment:
pgpQrr1yLmQD9.pgp
Description: PGP signature