Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 4 Dec 2002 11:41:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 4 Dec 2002 11:41:25 -0500 Received: from smtp-out-3.wanadoo.fr ([193.252.19.233]:38398 "EHLO mel-rto3.wanadoo.fr") by vger.kernel.org with ESMTP id ; Wed, 4 Dec 2002 11:41:20 -0500 Date: Wed, 4 Dec 2002 17:47:46 +0100 To: Antonino Daplas Cc: Sven Luther , James Simmons , Linux Fbdev development list , Linux Kernel Mailing List Subject: Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port Message-ID: <20021204164746.GA4261@iliana> References: <1038917280.1228.7.camel@localhost.localdomain> <20021204073218.GA1025@iliana> <1039003565.1079.67.camel@localhost.localdomain> <20021204102820.GA1841@iliana> <1039020239.1093.61.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1039020239.1093.61.camel@localhost.localdomain> User-Agent: Mutt/1.4i From: Sven Luther Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4233 Lines: 89 On Wed, Dec 04, 2002 at 10:27:21PM +0500, Antonino Daplas wrote: > On Wed, 2002-12-04 at 15:28, Sven Luther wrote: > > > > > > Most cards with a VGA core needs to disable the VGA output before going > > > to graphics mode. Disabling VGA output is hardware specific, and is > > > usually automatic when you go to graphics mode. > > > > So there is no common zqy of doing this, my docs say something about a > > vga control register zhich is accesses trough the sequencer regs. Does > > vgafb (or textmode or whatever) not call this when giving the hand to > > the fbdev ? > No, when a video card goes to graphics mode, it's up to the driver to > program the registers. vgacon/vga16fb only touches the standard VGA So we will have a repeat of the exact same code snipplet in all the drivers ? I thought the new API was about having all the common code in common and not duplicated in all the drivers. Could we have at least a gen_disable_vga function or something such that we could call ? > registers (crtc[25], attr[21], seq[5], gfx[9], misc[1]). Usage is pretty Well, i need to disable the vga output in seq[5], more exactly bit 3 called "enable VGA display", need to be reset. > much uniform across all hardware. Any registers past those indices are > considered extended registers and usage is hardware specific. In > graphics mode, you will probably use both the standard and the extended > registers, and disabling the VGA mode/enabling graphics mode is most > probably in one of the extended registers. Err, it is seq[5], called VGAControlRegister, so it is beyond the standard seq registers (seq[0] to seq[5]), right ? > > > Because James wrote the fb framework to be very modular, then you must > > > be careful to save/restore the initial video state when loading or > > > unloading. Theoretically, a driver should load, but not go to graphics > > > mode immediately. Only upon a call to xxxfb_set_par() should the driver > > > do so. Before going to graphics mode, that's were you save the initial > > > state. Have a reference count or something to keep track of the number > > > of users, and when this reference count becomes zero, restore the > > > initial state. You should be able to do this by hooking these routines > > > in fb_open() and fb_release(). > > > > Mmm, what about interaction with X ? X also does a save/restore of the > > previous (text) mode, when a X driver is _not_ fbdev aware, it will > > save/restore the things twice, right ? > > > Not twice just the current mode it was in when X launched, although it > always assumes text mode. Same thing for fbdev, it should only restore Well, but fbdev will save its state and X will save it again, so the saving done in the X driver is not all that important, and i could ignore it at first if i already have an fbdev. Does this also apply to vesafb ? > the state when reference count becomes zero. If the framebuffer console > is loaded, the reference count will never be zero unless it is > unloaded. If the framebuffer console is not loaded, the only time you > will save and restore the state is when some fb-based application > attempts to open/close /dev/fbx. Ok, ... > > > The one I submitted (and a revised one I'm going to submit soon) should > > > be able to restore the VGA text/graphics mode. Complement this with > > > your hardware's extended state save and restore routines and you should > > > be able to load/use/unload your driver repeatedly :-). > > > > Ok, i will try. > > This is optional though. You can still adopt the 2.4 method of always > setting the video mode. Just take note that fbdev can be loaded without > fbcon, and if you get into graphics mode without fbcon, you just messed > up your user's console. I think this can be avoided by munging the > configuration file (ie, always depend on fbcon and make your module > unsafe to unload). Anyway, i need to play with it some and experiment before i can do more comments. Friendly, Sven Luther - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/