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: 05 Dec 2002 06:04:52 +0500	[thread overview]
Message-ID: <1039050178.1075.82.camel@localhost.localdomain> (raw)
In-Reply-To: <20021204164746.GA4261@iliana>

On Wed, 2002-12-04 at 21:47, Sven Luther wrote:
> > > 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 ?

Not exactly.  Different hardware programs those registers differently.
Ie, vga will probably program the crtc regs for 640x400@60.  Your
hardware can probably do better than that. So the code cannot be
shared.  However, saving and restoring the standard VGA regs can be
common.

> 
> > 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.
> 
[...]
> 
> Err, it is seq[5], called VGAControlRegister, so it is beyond the
> standard seq registers (seq[0] to seq[5]), right ?

I meant seq[0] to seq[4] are standard VGA regs.  So seq[5] is extended. 
It's VGAControlRegister in your hardware, it's not used in mine.

> 
[...]
> > > 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.

If X is running  in native mode then it has to save the register state. 
Otherwise you cannot switch to a console.  If X is running on top of
fbdev, then state restore/saves are done using fb_set_var and
fb_get_var.  The registers are not touched, that's the purpose of fbdev.

If you are running vgacon, fbdev, and native X, then yes, fbdev and X
has to do a save of their initial state.

> 
> Does this also apply to vesafb ?
Not too sure about this. vesa requires real-mode initialization.  Either
you do this at boot time, or fake a real-mode environment like what X
does.

> 
> > 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, ...
> 
[...]

Tony

  reply	other threads:[~2002-12-05  1:04 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
2002-12-04 16:47             ` Sven Luther
2002-12-05  1:04               ` Antonino Daplas [this message]
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=1039050178.1075.82.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).