linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Sven Luther <luther@dpt-info.u-strasbg.fr>
Cc: James Simmons <jsimmons@infradead.org>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Linux-fbdev-devel] [PATCH] FBDev: vga16fb port
Date: 04 Dec 2002 22:27:21 +0500	[thread overview]
Message-ID: <1039020239.1093.61.camel@localhost.localdomain> (raw)
In-Reply-To: <20021204102820.GA1841@iliana>

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
registers (crtc[25], attr[21], seq[5], gfx[9], misc[1]). Usage is pretty
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.
> 
> > 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
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.

> > 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).

Tony

  reply	other threads:[~2002-12-04 17:27 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-28  7:24 [PATCH] FBDev: vga16fb port Antonino Daplas
2002-12-02 20:31 ` [Linux-fbdev-devel] " James Simmons
2002-12-03 12:22   ` Antonino Daplas
2002-12-03 15:47     ` Alan Cox
2002-12-03 20:50       ` Antonino Daplas
2002-12-03 22:01         ` James Simmons
2002-12-03 22:02       ` James Simmons
2002-12-04  3:19         ` Tomas Szepe
2002-12-04  7:32     ` Sven Luther
2002-12-04 12:08       ` Antonino Daplas
2002-12-04 10:28         ` Sven Luther
2002-12-04 17:27           ` Antonino Daplas [this message]
2002-12-04 16:47             ` Sven Luther
2002-12-05  1:04               ` Antonino Daplas
2002-12-05 17:35                 ` James Simmons
2002-12-05 18:03                   ` Sven Luther
2002-12-05 20:37                     ` James Simmons
2002-12-05 20:44                       ` Sven Luther
2002-12-06  0:50                         ` James Simmons
2002-12-06  1:36                         ` Antonino Daplas
2002-12-03 20:49   ` Antonino Daplas
2002-12-04 23:44     ` James Simmons
  -- strict thread matches above, loose matches on Subject: below --
2002-12-04 10:38 Petr Vandrovec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1039020239.1093.61.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=jsimmons@infradead.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luther@dpt-info.u-strasbg.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).