#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 [EMAIL PROTECTED] Wed Jan 09 18:43:40 2002
Return-path: <[EMAIL PROTECTED]>
Envelope-to: [EMAIL PROTECTED]
Received: from localhost ([127.0.0.1])
by zombie with esmtp (Exim 3.33 #1 (Debian))
id 16OMlH-00012K-03
for <[EMAIL PROTECTED]>; Wed, 09 Jan 2002 18:43:40 +0100
Received: from localhost [127.0.0.1]
by localhost with POP3 (fetchmail-5.9.6)
for [EMAIL PROTECTED] (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 ([EMAIL PROTECTED] [213.83.10.6])
by gnu.in-berlin.de (8.12.1/8.12.1) with ESMTP id g09He27e001826
for <[EMAIL PROTECTED]>; Wed, 9 Jan 2002 18:40:02 +0100 (CET)
(envelope-from [EMAIL PROTECTED])
X-Envelope-From: [EMAIL PROTECTED]
X-Envelope-To: <[EMAIL PROTECTED]>
Received: from hirsch.in-berlin.de ([EMAIL PROTECTED] [127.0.0.1])
by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with ESMTP id
g09He2PP019835
for <[EMAIL PROTECTED]>; Wed, 9 Jan 2002 18:40:02 +0100
Received: (from [EMAIL PROTECTED])
by hirsch.in-berlin.de (8.12.1/8.12.1/Debian -2) with UUCP id
g09He2IN019833
for [EMAIL PROTECTED]; 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 <[EMAIL PROTECTED]>; Wed, 9 Jan 2002 17:29:08 +0100
Received: (from [EMAIL PROTECTED])
by bytesex.masq.in-berlin.de (8.12.0.Beta7/8.12.0.Beta7/Debian
8.12.0.Beta7-1) id g09GT8mE009935
for [EMAIL PROTECTED]; Wed, 9 Jan 2002 17:29:08 +0100
Date: Wed, 9 Jan 2002 17:29:08 +0100
From: Gerd Knorr <[EMAIL PROTECTED]>
To: Eduard Bloch <[EMAIL PROTECTED]>
Subject: Re: VESA fb in Debian - please give a hint
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
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 */
pgpy8Z7bfpKXJ.pgp
Description: PGP signature
