From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-) Date: Wed, 28 Apr 2004 09:53:28 +1000 Sender: linux-fbdev-devel-admin@lists.sourceforge.net Message-ID: <1083110007.20091.5.camel@gaston> References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1BIcTv-0006yO-2D for linux-fbdev-devel@lists.sourceforge.net; Tue, 27 Apr 2004 16:59:19 -0700 Received: from gate.crashing.org ([63.228.1.57] ident=root) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1BIcTu-0006Wi-So for linux-fbdev-devel@lists.sourceforge.net; Tue, 27 Apr 2004 16:59:19 -0700 In-Reply-To: Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: James Simmons Cc: John Zielinski , David Eger , Geert Uytterhoeven , "Antonino A. Daplas" , eger-dated-1082943669.d79d33@theboonies.us, Linux Fbdev development list > No. Look the logic should go from the upper VT layer to the lower driver > to accomplish something. Not the reverse. > > struct vc_data -> native console driver structure --> fbdev But the upper VT layer has no clue about what a graphic mode can be and we know well enough that we _need_ to be able to enforce graphics mode or want to play with them by manipulating var structures, without losing the console. Your logic is only ever valid once every single fbdev is capable of doing proper mode management & validation. And even then, there isn't a 1:1 relationchip between a mode and an fbcon size. > Not. > > fbdev --> native console driver --> struct vc_data. > > This was the way it uses to be. If this is the case then I suggest we > write our own vt.c and vt_ioctl.c for the fbcon layer. We shouldn't even > use struct vc_data then. In fact each fbdev driver should be independent > console drivers. That is how 2.4.X was. Each driver was nearly its own > console driver. We need to go one way or the other. I agree we need to go away and I'm not proposing adding anything to fb_info nor whatever in this regard. It has to be all self-contained in the console subsystem, that is fbcon. And we already have a data structure holding per-console fbcon-specific data, it's called struct display. Ben. ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click