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
next prev parent reply other threads:[~2002-12-05 1:04 UTC|newest]
Thread overview: 24+ 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
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.