#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